on 11-29-2004 6:18 PM
I want to add a jar file to a web application in such a way, that it is only loaded once for the application, not once every time a context is started for this application.
More specifically, one of the classes loads a dll using System.loadLibrary(). This call fails the second time the context of the application is loaded, because it is loaded with a different class loader, hence the static initializer of the class is run again.
For a Tomcat one would simply put the jar file into $CATALINA_HOME/shared/lib, so classes from there are loaded once per tomcat instance. Is there a similar mechanism for WebAS?
I noticed a subdirectory lib/ext in the server directory - is that meant for shared libraries or extensions like Java extensions?
Hi Martin,
you didn't say on what version you are working.
For 6.20, see https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webas/webas620/adm... manual for sap j2ee engine 6.20.pdf - "Configuration of Additional Libraries"
For 6.40, see http://help.sap.com/saphelp_nw04/helpdata/en/16/df813e77d46245e10000000a114084/frameset.htm
Hope it helps
Detlev
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Detlev,
thanks for the links. I am trying to migrate a Web Application (no EJB) to WebAS 6.4. I am experimenting with Developer Workplace, which is 6.4. I have not imported the application into Developer Studio, but am trying to deploy it as a war file, consisting of about a dozend jars. Therefore I will probably have to try the manual configuration options.
Some of these jars contain classes, which load libraries. Each time the context is started, the application is loaded in its own class loader. The first time round, the library is loaded ok, but for every subsequent start the library can't be loaded (the error message says it has been loaded in another classloader), but it can't be used either.
So far, I have found the follwoing workarounds:
1. Restart the server after each deploy. This is slow during development and unacceptable for production.
2. Deploy the jars in question as java extensions, i.e., copy them to the $JAVA_HOME/lib/ext directory. I can do that for jars that are only used by my application. But there is still the problem of common jars like jco.
3. For jco we found the jrfc.jar, which seems to provide the same services as jco, but does not use any dlls. However, I am not sure if that is a valid assumption (I can't test the JCO connection right now).
Thanks again, Martin
User | Count |
---|---|
81 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.