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.
Related
I'm doing some clean-ups in a GWT (no maven) project. It has a lot of jars added in WEB-INF/lib. I know the purpose of those jars (for example for REST service - luckily it's documented) so I wanted to put them in appropriate subfolders for nicer look.
After re-adding them to build path (as now they are in subfolders) I tried to run SuperDevMode and got multiple warnings:
Server class 'X' could not be found in the web app, but was found on the system classpath
and some errors like:
Cannot find a default implementation of the HK2 ServiceLocatorGenerator
When I put those jars back in WEB-INF/lib (without subfolders) and re-add to build path everything runs just fine.
My question is: can't/should't I use subfolders in WEB-INF/lib? If so, why?
Server class loader is programmed to look only into WEB-INF/lib, not other folder nor subfolders.
I strongly suggest to get into the maven world, it has a steep learning curve but it will assure to your project a solid foundation to grow on. Another big plus of Maven is that it can automatically pick up the latest security patch of your libraries (Equifax, anyone?).
Extract from the Apache Tomcat 7 Docs:
WebappX — A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
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/
Eclipse's Web Tools Platform (WTP) allows you to configure Tomcat to "Server modules without publishing":
Web content will be served directly from the "WebContent" folder of the Dynamic Web Project. A customized context is used to make the project's dependencies available in the Web application's classloader.
In a 5 step process (just joking, you pick the # of steps), what happens technically and where are the files that Eclipse generates? I did notice that Eclipse generated a org.eclipse.jst.server.tomcat.runtime.70.loader.jar file in the Tomcat lib directory.
The idea is to serve a web application directly from the scattered directory structure of the development workspace, without packaging modules into JARs which then end up in WEB-INF/lib in a WAR.
The main benefits are:
You don't need to build archives.
When you change a resource in your workspace, the change is reflected in the running webapp without redeploying the webapp or restarting the server.
With Servlet 3.0, web resources may also be bundled in library JARs in META-INF/resources, so classes and resources may come from multiple workspace directories.
Tomcat 7.0 supports a VirtualWebappLoader and a VirtualDirContext to configure a web application based on a collection of scattered resource and class directories.
To serve your web app directly from your Eclipse workspace, WTP generates a suitable Tomcat configuration matching your project structure
in $WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/conf/server.xml
For some reason, WTP does not directly use the Tomcat loader and context implementations but has its own WtpDirContext and WtpWebappLoader which are slightly different but similar. (I believe this approach is older than the current solution in Tomcat. There is some special logic for TLD scanning - I'm not sure if this is still required with the latest Tomcat versions.) These helper classes are contained in the org.eclipse.jst.server.tomcat.runtime.70.loader.jar you noticed.
Without Serve modules without publishing, when you change a web resource in META-INF/resources in a library module, this change will not be directly visible in the running application after reloading the current page in the browser.
Hullo - issue is this:
I wrote a servlet in Eclipse which requires mysql-connector-java-5.1.22-bin.jar
To compile I need to add the jar via the project's "Java Build Path"
To deploy I need to add the jar to the project's "Deployment Assembly"
To run the servlet within eclipse I need to add the jar to the servlet's Run Configuration -> Classpath
It's not the end of the world re-re-repeating myself like this, but it does seem odd.
Given that Eclipse gets a lot of other stuff correct I'm guessing / hoping that maybe I'm overlooking some feature to avoid this silliness (I cannot imagine a scenario where you'd benefit from entering this in 3 different spots ... but maybe I'm being uncreative here ...).
Insights appreciated :-)
The only thing you need to do is to drop the jar in WebContent/WEB-INF/lib.
You are developing a Java Web project, so the traditional place to put the required libs (JAR files etc) is under /WEB-INF/lib. And you do it only once.
In Eclipse, when you create Dynamic Web Project the appropriate project structure is generated for you (this is a development structure). In this case you place your JAR files in ProjectName/WebContent/WEB-INF/lib folder. And this folder is *automatically included in the project's build path.
Considering the fact that it is a Java Web project (you said you use servlets) you have to deploy your web app to some Application Server, like GlassFish, JBoss, WebLogic, WebSphere etc, or more simple Web Container like Apache Tomcat. If you do this thru Eclipse, then again your web project is automatically deployed.
NB!
There may be some additional details related to using libraries.
For instance, when it comes to using database drivers (MySql, PostgreSQL, Oracle etc) Tomcat advises the following while configuring JNDI Datasource (quote):
Before you proceed, don't forget to copy the JDBC Driver's jar into
$CATALINA_HOME/lib
In your case (MySQL) see the example here: MySQL DBCP Example
Also see my answer related to Webapp configuration file organization convention.
Hope this will help you.
P.S. Here is a step-by-step example: How do I access MySQL from a web application?
I need to deploy multiple web services on a jax-ws application server, glassfish 3. These web services need to have shared libraries, meaning shared instances of the same class.
I know I could do this by dropping a jar in the "~/glassfish3/glassfish/domains/domain1/lib" directory. But I wonder whether this is possible in a more elegant way: I want to place the shared library jar inside a web service war which I deploy and then access that library from another war I deploy on the same application server.
How can I do this?
I found a solution for Glassfish myself: Basically I just deploy a class (SharedClassLoader) which inherits from URLClassLoader as a shared library jar in the above mentioned directory. Then I use this classloader as a bootstrap: On calling the web service, the classloader hierarchy is extended as follows: A SharedClassLoader for an URL is instantiated if it does not exist yet and it is added as a delegate to the DelegatingClassLoader in the classloader tree. By doing this for every web service with the same SharedClassLoader instance, it acts as a bootstrap to pull in more class loading. The jar that SharedClassLoader refers to can also be deployed with one of the web services, because Glassfish unpacks the containers to $AS_HOME/domains/domain1/applications/APPLICATION_NAME/LIBRARY_NAME.jar.
I hope this helps anyone having the same problem. I solved this problem for my Bachelor Thesis. If anyone needs more information, just ask, I can send you my thesis.