prefer-web-inf-classes has to be specified for the classes specified in Web-INF to take precendence over classes present in application library of weblogic server. I have a special case where I need the class loader to use one specific jar from WEB-INF folder. Is there any way of doing this?
To prefer all packages which are in your WEB-INF/lib over those which are bundled with your WebLogic lib set <prefer-web-inf-classes> to true in your weblogic.xml or application-weblogic.xml.
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
For more detail see Using a Filtering Classloader, weblogic.xml Deployment Descriptor Elements and WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool .
If you are not sure if the right class is loaded you can use the Classloader Analysis Tool for WebLogic.
You may want to look at Filtering Classloaders?
This allows to specify on a package-by-package level just which classloader to use.
You want to be very careful with this, though. Are you sure you already are in CLassloader Hell, so you must resort to this kind of stuff, and there's really no alternative?
Did you consider putting the JAR into the APP-INF/lib folder of your EAR? Or move "all but the one you need in WEB-INF/lib" out to APP-INF/lib?
If you are using Weblogic 10.3.4+ version. You can use prefer-application-packages to control class level preference loading. Take a look at this video for more details.
Related
I'm embedding jetty in my application, the structure of the folder tree is:
|--lib
|--WebRoot
|---WEB-INF
|---lib
what I wonder is---where should I put the struts2 libs(e.g. struts2-core-2.2.3.1.jar, xwork-core-2.2.3.1.jar), and what about the servlet related api(e.g. servlet-api-2.5-6.1.11.jar, jasper-compiler-5.5.15.jar api)?
should I place jars in the top lib folder or in the lib folder inside WEB-INF?
This is really entirely up to how you want to structure your app, if you are embedding you don't have to follow a traditional webapp approach where you have a war file (exploded or not) and its convention of libraries under WEB-INF as in your example with a web.xml, you can skip the idea of a webapp deployer entirely and just build out the handler change yourself and register the servlets in java code, take a look at some of the embedded examples we have:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/example-jetty-embedded/src/main/java/org/eclipse/jetty/embedded/ManyServletContexts.java
There are other examples in there as well, if you are embedding then unless you need to deploy wars you don't have to muck with that aspect of things. If you do need to deploy wars then you put things where the would be in any normal usage of a servlet container, things for just that war in the WEB-INF/lib and things in the system classloader back in your main primary classpath.
In websphere 6.1, using RAD, what is the easiest way to check the class path from the server admin console? I can not seem to find the proper navigation.
Which classpath are you after? There are a number of classpath (which are related in a hierarchy) that come into play during the runtime.
The easiest way to see the required information for a given module or Java EE application is by using the classloadviewer. This would show you the complete picture of what elements are in the classpath of this application and which JARS, classes are loaded by the class loaders.
Refer to this link for some information:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Futrb_classload_viewer.html
This is for Struts 1.x (I'm using 1.3.10).
I've noticed that Struts is unable to pick up resource bundles in the ApplicationResources.properties file if it is not placed somewhere in the default classpath (e.g., com.abc.SomePackage).
For instance, if I put the ApplicationResources.properties file in a custom folder /WEB-INF/strutsResources and configure the struts-config.xml thus:
<message-resources parameter="/WEB-INF/strutsResources/ApplicationResources"/>
I've read that the resources need to be on the classpath so I've also tried adding the /WEB-INF/strutsResources folder to the classpath. It still does not pick up the resource keys.
I've double-checked that the strutsResources folder is actually deployed to the server (I'm using Glassfish v3), so the file is there, it's just not being parsed.
P.S.
If you're wondering why I'm trying to do this, I just wanted to organize my code a little better ("better," IMO). Since the ApplicationResources.properties file is not really a class, I wanted to place it in a resources folder by itself.
I've checked that placing the ApplicationResources file in a package in the src directory works just fine.
Ultimately, the answer is yes. You can play some interesting games by configuring a custom className and/or factory and get messages however you want (including from a database) and so on. This allows you to customize whatever you want*.
I agree the resources aren't a class, but putting them on the classpath is a common practice, and allows resources to be loaded as a resource, e.g., from inside a jar. I'm sympathetic, but I'd leave it as-is.
*Like reversing all the text; a fun prank to play on your co-workers and QA department.
Its best leave it on the classpath.
It's stadard practise to include properties files on the classpath, especially if you're planning on packaging it up in your WAR/EAR. You're keeping it under WEB-INF so you gain no benefit from moving it off the classpath, and you'll just confuse other developers who have to work on the project and you've had to put a hack in to make this work.
If you want to keep your files external to your deployable WAR/EAR then that's a valid reason for not using the classpath. Typically this will require some configuration as part of your deployment to specify where the file is to reside.
For example specify the location using
a JVM argument (e.g. -Dprops.file=/config/myapp.properites)
lookup from a JNDI resource
use a PropertiesFactoryBean if you're using the Spring framework (I
use Spring's ApplicationContext with Struts 1 MVC)
read properties from a database writing your own
ApplicationPropertiesDAO class that initialises itself durnig your
applications bootstrap process (e.g. Spring application contact,
Servlet in web.xml, Listener in web.xml, etc)
I have been working on this problem for one whole day but in vain without any effective solution.
I have an ear file packaged with an ejb and a handful of jar files (including hibernate and the other dependent jar files).The ejb is stateless and enabled as a web service.
The ear file has been packaged using maven and has the below structure
ear->projectrelatedejb.jar
->hibernate.jar
->otherdependent. jar
->META-INF/application.xml
->META-INF/manifest.mf
The application.xml and manifest file are automatically generated by maven when I do a package.
When I deploy this ear file on glassfish it gets deployed with the ejb methods being accessible using web services. However when accessing the application (using soapui),
the ejb methods that perform some database functionality using hibernate throw java.lang.NoClassDefFoundError for the hibernate api during runtime.
It is obvious from the error that the hibernate jars are not on the classpath during runtime but since the jars are within the ear Glassfish should have
added it to the application classpath.
I tried various options like adding the classpath entries to the manifest.mf during the package (by using the element addClasspath with the maven-ear-plugin) which didn't do any good.Also with Glassfish we cannot add the dependent jars as modules to the application.xml unless the jars are application client jars
(Glassfish wouldn't deploy the ear file if the application.xml has the dependent jars declared as modules).
I also tried placing the jars in the lib directory within the ear (which isn't actually required) and with the manifest Class-Path header referencing the jars in the lib directory which also didn't fix the problem.
The quick and dirty fix which I can do to get this working is to place the hibernate and the other the dependent jars in Glassfish's lib directory.However,this is a bad practice
and I am somewhat reluctant to do it.
I would really appreciate if someone can provide me with a working solution to this problem.I have gone through the net looking for this problem
but couldn't find any solution.
Wondering if its a bug with glassfish or does glassfish need something special to reference the jars in an ear.
Thanks in advance.
I found a similar problem which is discussed here: http://www.tricoder.net/blog/?p=59.
Simply put, try putting the libraries in EAR/lib directory and according to JEE5 spec, glassfish will add them to class path automatically.
I used Server Library option to deploy application JARs and it worked for me.
Right click on your EAR-> Properties -> Libraries-> Add Library -> Create -> give name and change type in Library Type to Server Libraries then add JARs that should be deployed and confirm.
I work with NetBeans 7.0.1 and GlassFish server 3.1
When you say you added classpath entries to manifest.mf, which manifest.mf do you refer to? The one in ear-root/META-INF/manifest.mf ? Try adding a META-INF/MANIFEST.MF to your ejb module with Class-Path entries!
I'm happily using the Maven bundle-plugin to create OSGi manifest headers for my modules. However, when there are configuration files that pull in classes which aren't referenced directly in the code, the plugin can't tell which packages it's going to need.
One example is a bundle with domain models that constitute a Persistence Unit for JPA. The driver class is part of the PU configuration and either set in an XML file or at runtime when the EntityManager is instantiated. I have to manually add an Import-Package header for the driver class that I want to load, or I get CNF errors.
Another example is a Struts war, where the web.xml pulls in the Struts dispatcher that's otherwise not found anywhere in the code and has to be manually added to the headers.
How can I avoid this?
I tried adding the required packages as dependencies with a provided scope, but that didn't help.
In the plug-in section of the bnd configuration you can specify plug-ins to analyze these files and contribute to the import-package header. For spring it looks like this:
<_plugin>aQute.lib.spring.SpringComponent</_plugin>
I am not sure, what descriptors are supported on top of spring. Just take a look at the source (it's in the Apache Felix SVN) and see for yourself. In the worst case you have to write your own plug-in, but at least it is possible! Also peter kriens site about the bnd explains the usage and some internals.
Other then that I am not aware of any simple solution.