I'm trying to deploy two or more independent Play! (1.2.4) based projects to
the same Jetty instance.
According to this post it apparently is possible to extract the
common lib's from each PrjName.war/WEB-INF/lib directory and place
them into a shared lib directory i.e. jetty/lib/ext.
We have a large number of smaller independent projects that we would
like to implement using Play! but all need to be deployed in the same
Jetty instance sharing all the libs to reduce RAM usage. Is my assumption correct that several projects sharing the same lib's will reduce the overall memory footprint?
My attempts putting all the libs in a shared location i.e. jetty/lib/ext worked for a single project but deploying the second project fails
and breaks the first one.
It appears to be an issue with conflicting EhCache instances.
Here is the jetty log:
...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:469)
at org.eclipse.jetty.start.Main.start(Main.java:612)
at org.eclipse.jetty.start.Main.parseCommandLine(Main.java:265)
at org.eclipse.jetty.start.Main.main(Main.java:79)
Caused by: net.sf.ehcache.ObjectExistsException: Cache play already
exists
at net.sf.ehcache.CacheManager.addCache(CacheManager.java:859)
at play.cache.EhCacheImpl.<init>(EhCacheImpl.java:32)
at play.cache.EhCacheImpl.newInstance(EhCacheImpl.java:41)
at play.cache.Cache.init(Cache.java:241)
at play.Play.start(Play.java:511)
... 42 more
Any help is greatly appreciated.
When you use shared jars, Jetty will use the System's Classloader to load classes inside the shared jars. And, since Play EhCacheImpl is (almost) a singleton, the second application to start will influence the first and vice versa. That is the exception you are getting now: Play is trying to instance two caches, in the same classloaders, with the same name. I can think about the following solutions:
Fix Playframework so that it can handle this situation
Use your own cache implementation (not sure if this is the only thing that prevents your both applications to work together)
Use a common setup and replicate jars for each application.
The option 3 sounds better to me, since you don't have to chance the framework and it is also more secure regarding regression bugs. About the memory footprint, you can use visualvm to validate if the memory consumption is significantly different to justify shared jars.
Related
OFBiz by default works as a collections of small webapps each with its own front controller. OFBiz webapps typically depend on a lot of common modules. Typically, modules under specialpurpose or hot-deploy would end up depending on pretty much all of the modules under framework and applications... with the embedded container, all libraries go into the catalina shared library class loader but if ofbiz needs to be deployed in a different container, there is simply no easy way. the only options i believe are
package ofbiz as an EAR with a EAR/lib or EAR/APP-INF/lib so that all webapps have access to a common set of EAR level classpath resources.. typically each modules's config, lib and the all important ofbiz-$module.jar
each webapp packages each of the required jars into its own WEB-INF/lib.. too much duplication and also increases the filesystem footprint in a sense
use the application system classpath in lieu of catalina shared.lib folder - which means the JVM has to be dedicated to ofbiz as its jars would otherwise interfere with other sibling deployments and potentially even with the container itself, typically things such as XML, XSL, STAX apis etc..
given that ofbiz load most of the resources using the filesystem (ofbiz.home + component://) resulution. What the webapp really needs access to in a convential servlet context kind of way is the
controller.xml
classpath resources - across the various ofbiz-$module.jar in shared.lib. typically, each modules's config, lib and the all important ofbiz-$module.jar
imported (component://) webapp resources like other controller.xml for various modules. most importantly the framework/common/webcommon/WEB-INF/controller.xml that provides the boiler plate security implementation like checkLogin and autoLogin....
I was wondering if we could somehow package multiple webapps into a single monolithic webapp using front controller namespacing so that the war maps to a single root content like say / (ROOT on tomcat) and /content, /webtools, /catalog, /ecommerce etc. are mere URL namespaces/subcontexts rather than separate webapps. framework/common/webcommon/WEB-INF/controller.xml could become the root controller for / (ROOT in tomcat) and provide checkLogin, autoLogin etc to all webapps without each controller having to import that controller.xml
This would allow us to simply the deployment model when we would want to move to other containers like say weblogic, jboss et al where we would be better of building a single webapp with all of its dependencies neatly packaged into its WEB-INF/lib such that it could coexist with other deployments in the same container without interfering with their dependencices and their versions...
I believe struts had this kind of modular namespacing where there could be a root level struts.xml (our case controller.xml) and each module would be a folder with its own module/struts.xml or module/struts-module.xml etc...
i personally feel this would be helpful.. i have not thought enough about the downsides. there could be many? i honestly don't know. I have not given enough thought to themes either.. developers clearly would not like to see any change in the way code is laid out or organized.. so with some minor? :) changes in the core MVC code in the framework, we could potentially support this kind of deployment using a simple ant build script that stages candidate webapps into a merged monolithic webapp...
i was hoping to see a debate on the merits of this idea... i would even be willing to invest some time into making this work if i get some direction and inputs..
Have you considered using chef to deploy Ofbiz instead?
I wrote the following cookbook to demonstrate how it could work:
https://github.com/myspotontheweb/chef-ofbiz
This is a difficult part of how Apache OFBiz is architected. Using EAR files works okay, but shared classpath resources in an EAR file are app-server specific, and you have to deploy in a container that supports EAR files which limits choices.
One of the limitations is the flat namespace for requests in the controller.xml files, and what you describe would be the best way to handle that (use a different ControlServlet mount point for each OFBiz component app). Doing so may require some code changes for the URL writing (the #ofbizUrl FTL tag and the underlying code used elsewhere). It would also require a bit of work to write an ant target or something to build the WAR file, pulling in all the webapps from the various components (or just those desired), writing a combined web.xml file, etc, etc.
This is a recognized issue with OFBiz, and isn't a problem for most deployments, but does make it more difficult to scale down or host along with other applications. You can add other webapps through OFBiz components to host them on the embedded servlet container, but I don't imagine that is what you are looking for.
One of the issues with making this and many similar changes in OFBiz is the large code base, large user base, and the somewhat large committer group with diverse opinions on things like this. For these and other reasons a lot of the ideas for improving OFBiz can't be easily realized there, and that is why I started the Moqui Framework project in 2010.
Moqui deploys with a single WAR file, and can have an external or embedded runtime directory to make it easy to deploy on WAR hosting services such as AWS ElasticBeanstalk, as well as dropping in to servlet containers such as Apache Tomcat. The WAR file is also an executable JAR file using an embedded Winstone servlet container for easier development and automated testing. There are details about running and deploying Moqui here:
http://www.moqui.org/framework/docs/RunDeploy.html
BTW, this is one of hundreds of ideas for improvements to OFBiz that made it into Moqui Framework and the separate project with data model and services (Mantle Business Artifacts). There is general information about it here:
http://www.moqui.org/
I'm trying to troubleshoot a GWT-based app I'm writing in Eclipse. It currently uses Spring Framework 3.1.1 and Hibernate 4.1.6 on the back-end side. I'm currently having troubles with the dreaded "javax.validation.ValidationException: Unable to find a default provider" that seems to plague a lot of folks but is caused by different problems. I've tried the various solutions of using different versions of the JSR 303 implementation (e.g. diff. versions of Hibernate Validator) but it doesn't seem to make a difference.
And after debugging, I'm seeing why. Once execution gets to javax.validation.Validation.getValidationProviders():317 (in validation-api-1.0.0.GA), the app (running on an Eclipse internal Jetty server) attempts to read the META-INF/services/javax.validation.spi.ValidationProvider resource from the classpath and comes back empty. I am absolutely certain that the different validator implementations I've put (e.g. hibernate-validator-4.3.0.Final.jar) have that resource and it does contain a value (e.g. org.hibernate.validator.HibernateValidator), but is not appearing to the classloader in question. The way I've included the JAR in the classpath is by adding it to the project's Build Path which seems to add it to the Jetty runtime when I execute the applications.
My question is: Is there a way to view the classpath in Eclipse debug mode visible to a certain classloader? Secondly, does anyone know why the Hibernate Validator's resource is not first and foremost in the classloader that Validation is using?
The webapp classpath is composed by the directory WEB-INF/classes and by all the jars in WEB-INF/lib. If you want a jar to be available at runtime, you must NOT add it to the build path, but to WEB-INF/lib.
Dropping a jar in WebContent/WEB-INF/lib in Eclipse will make it automatically part of the buid path of your webapp, and available at runtime.
I am developing a Java EE 6 bottom-up JAX-WS to expose an EJB3.1 stateless session bean. The web service in a WAR is failing to install on deployment because it references an external jar (or shared library) which one can assume is not loaded yet.
The common suggestion is to include the jars in the /lib folder, which does fix the issue, however the jars need to remain in this external shared library location and NOT in the ear file, because they amount to 30MB.
What are some techniques to get around this issue in a Websphere (WAS v.8) environment or any server environment.
Some suggestions I have found include:
1. define classpath in META-INF file.
2. define the resources in deployment.xml
3. alter class loading order
4. (from ibm) In the case where the jars are part of a Shared Library configured on WebSphere Application Server, then a User Library must be used to configure the project for development before generating the WebService.
However, I have been unsuccessful to find any help online in these areas. Is there another technique or does anyone know anything about accomplishing this? Thanks in advance.
EDIT: If I specify the libraries in the META-INF using class-path, they are loaded before extensions, shared libraries..etc, but they are still loaded after the WAR which is not good. Again, this isn't a runtime issue because the web services are created at deployment on the fly.
I submitted a ticket to IBM. The libraries referenced by the web service are needed during deployment and must be bundled into the Ear in some fashion. I threw them in the web-inf/lib folder. However, if the referenced libraries then depend on additional libraries, these can be placed in the Shared Libraries. Seems odd to me too, but let's all just admit "shared libraries" are a hack anyways.
If you still have issues, just make sure your class loading is set to parent_last.
I have a few separate application projects (EARs) with multiple EJBs that I want to deploy to the same JBoss server. Now, some of the projects may have the same EJBs, but different versions. In similar circumstances, some projects may use different versions of the same "ordinary" classes (i.e. classes loaded within VM, without JNDI lookup).
With OC4J, this seems not to have been a problem, but now with JBoss, I get the impression that everything resides in the same "name space" (or class loader perhaps). Am I correct in this assumption?
Basically, what I want to do (or ensure) are two things:
From a client that does a JNDI-lookup of an EJB, I want to be able to indicate which application it resides in, so that the correct version of the EJB is returned.
From within an EJB, when instantiating a class, I want to ensure that the class is the one deployed with the same application (EAR) as the EJB was.
I think I read that you could configure some "isolation" properties for EJBs, am I guessing correctly in that might would solve my second point?
JBoss's default behaviour is to use a flat classloader. This reduces the footprint, but as you've found, it makes deploying multiple applications troublesome.
Thankfully, the fix is easy. In the ear-deployer.xml file in the deploy directory, make sure the following parameter is set:
<attribute name="Isolated">true</attribute>
This will give each deployed EAR its own classloader space. It will still be able to access stuff from the JBoss lib directory, but the deployed EARs will be invisible to each other.
You're correct that classes from different EAR's reside in the same "space". JBoss uses by default a flat classloader hierarchy, meaning that all classes (except for WAR packaged ones) are loaded by the same classloader. With the introduction of JBoss 5 there's a new standard profile that strictly follows the Java EE rules and thus supports isolated classloading. Older JBoss versions also support this behavior through the callByValue and isolate properties in the deployer configuraion.
If I have an dependency Jar for my application is it better to place it in the war files lib directory or to place it in the global application server (like Tomcat) lib directory? What do I gain by using one approach over another?
Diskspace springs to mind, but we live in a time when diskspace is cheap. Is there a memory usage difference? Can someone with more experience then me list the pros and cons of both options?
Generally speaking, it's much better to have WAR self-contained so you don't have to rely on the container configuration. It makes deployment much easier also. So try to put library in the WAR if you can.
However, I ran into cases when installing libraries to container makes sense. For example,
We have some internal libraries used by every webapp and they are huge. We install them to container so all the webapps use the same version and it saves on memory and diskspace too.
Libraries installed in WEB-INF/lib is not available to container. If you need to reference these in context.xml (like JDBC driver defined in Resources), you have to put them in server/lib.
If you want send log4j logs from all the webapps to the same file, you have to put log4j jar in the server/lib. Otherwise, each webapp uses its own logger.
If you want to use the container's resource management capabilities -- e.g. connecting to a SQL database and providing a JNDI lookup and connection pool for it -- then the container software itself will need access to the libraries and drivers to manage the resources.
Otherwise you probably don't want to install them in the server /lib directory and assume they are there and will work, as different web applications might have subtly different version requirements.
For a in-depth description of the class loader hierarchy implemented by Catalina, you should check Tomcat's Class Loaders HOW-TO. This will help you to understand when to make jars available to the container, to all webapps, to a single webapp only... and where to put them.