I am using Weblogic Server 12.1.1 and copied some JARs to my domain's lib folder. One of the JARs is a org.apache.commons.io jar. Now I have the problem that Weblogic itself comes with a different version of commons-io in its system classpath and so I get NoSuchMethodErrors. Is there any way to configure Weblogic to prefer the libs from domain over those from Weblogic system?
The Filtering Classloader works only on those JARs provided with the application (WEB-INF/lib).
Use one of follwing options in weblogic.xml descriptor:
prefer-application-packages
prefer-web-inf-classes
Details are described here.
For completeness, i must say that putting commons-io into the domain/lib folder is a bad solution. The problem you describe is a good reason not to put widely used libraries into this folder. The problem might be circumvented by an even worse idea: moving that library higher up in the classloader hierarchy. If you insist on excluding commons-io from your application deliverables, you might install commons-io as an endorsed lib in the jdk. (see here) This would nail down your version of commons-io for every application including weblogic itself. Of course, this would be a problem if you need to contact weblogic support.
If you need to put JARs into the domain /lib, I think you have to edit the setDomainEnv.cmd and modify PRE_CLASSPATH variable.
Example:
set PRE_CLASSPATH=C:\myinstallation\Middleware\wlserver_12.1\domains\mydomain\lib\myjar.jar
But, if is possible to put JARs in WEB-INF/lib or APP-INF/lib, then use #Blekit solution, it's cleaner.
Related
I'm currently in the process of creating a web service to be deployed onto an existing Jetty 9 server. I decided to use maven to handle the dependency management for this application and it is creating a bit of a problem. When I try to start the app, it is failing due to library conflicts. I figured out that the source of the problem is that the classpath is including both my maven dependencies and the jars in $JETTY_HOME/lib/ext/. I can't simply rename or delete lib/ext since there are existing applications on the server that depend on those libraries.
Is there a way to configure jetty to include or exclude lib/ext from the classpath on a per-application basis? If not, is there some other way I can work around this problem?
TL;DR - I don't think there is a simple answer.
According to the documentation, the jars in the lib/ext directory are added to the classpath by the "ext" module. So, you could in theory disable the "ext" module. But that will remove the jars from the classpath for all of the web services in the container. So that won't work ... except for testing purposes.
So that leaves you with a couple of more drastic solutions:
Set up a separate Jetty server to run the new webapp. (For example, using Docker containers.)
Analyze the other webapps to determine which of them use the JARs in the lib/ext directory, and rebuild their WARs so that (at least) the conflicting dependencies are in the WARs that need them rather than in lib/ext.
This is probably what you should do.
Go on a Jetty code hacking spree and modify the way that Jetty builds the "server" classpath. Anything is possible, if you are prepared to put in enough coding effort. But you will be creating "technical dept" for yourself by (in effect) creating a private fork of Jetty. So this is a really bad idea.
Setup
I have a maven project which creates a war file, I then deploy the war file to a glassfish server (3.1).
My Manifest is default one with just the basic info, but I've also tried maven-war-plugin to add classpath to the Manifest. From my understanding of that plugin it should only help me determine libs outside my web-inf/lib scope.
Problem
In my war file I have two dependencies which both contain the same class but two different version of that class, so I need to specify my Glassfish Archive class loader to load them in a certain order. Now I'm completely lost as how to do this, which leads me to my questions.
Questions
Is it possible to use the Manifest file to force Glassfish to use a specific classpath?
How does Glassfish determine in which order it loads the jar files in WEB-INF/lib?
Is it possible to tell Glassfish how to specify the classpath in some other way?
If not, is it possible to affect the order Glassfish loads the jar files in WEB-INF/lib?
(I don't have privileges to comment in SO, hence the answer)
The following link describes one way of managing the order of class loading.However, as others have rightly pointed out, what you are trying to achieve is not good at all.
https://www.java.net/node/704037
We have a legacy system that was just ported to AppEngine. So now we need to use Objectify4, however the legacy application we have is not yet "mavenized" so we add jars manually. What are all the jarts needed to be placed in WEB-INF/lib folder so Objectify jars and its depenedencies will work.
The current AppEngine version we set in the classpath is 1.7.2
You can download the builds from the Maven repo here:
https://objectify-appengine.googlecode.com/svn/maven/com/googlecode/objectify/objectify/
That being said, there doesn't appear to be any guarantee with these files so use at your own discretion.
Depending on when how soon you plan to deploy your product, it may make more sense to build your service using v3 as opposed to v4 for now.
Quoting from Objectify documentation:
Add objectify-N.N.N.jar to your project's WEB-INF/lib directory. There are no other jar dependencies.
Edit: The jars are located in the Maven Repository, by browsing the source. For example, here you can find the objectify-4.0a4.jar.
Hope this helps!
I am having four different project, and i am using Weblogic to deploy my projects. There are several libraries ( jar files ) which are common for all projects. Currently each of my project are having lib directory and have almost same set of libraries. Now, is it possible to have this lib directory outside WAR files and access them.
Resist the temptation of putting the jar files in the "shared" folder of your container. It is better to keep the jar files where they are now. It may sound a good idea to use a shared folder now, but in the future you may need to deploy an application that requires a shared library, but a different version.
That being said, I have no experience with WebLogic. In Tomcat there is a shared folder with libraries common for all deployed applications. It is not a good idea to use this. If WebLogic can be configured to use a shared folder per a set of applications (and not for all deployed applications) you could go for it.
Do you want to do this ? Unless you're stuck for deployment space, I would (perhaps) advise against it.
Why ? At the moment you have 4 solutions running off these libs. If you have to upgrade one of the libs (say, if you discover a bug, or if you require a new feature), then you're going to have to test compatibility and functionality for all 4 solutions. If each solution has its own set of libs, then they're sandboxed and you don't have to move all 4 in step.
Note that all this hinges on how easy it is to regression-test your solutions. You may find it easy, in which case using the same set of libs is feasible.
Don't do that.
The whole idea of WAR files is that they are self-contained units. This makes deployment so much easier.
In addition to the possible version conflicts that others have pointed out, putting jar files in /shared can have very nested consequences for class visibility. They will be on a separate classloader, and be unable to see the classes in the WAR file. If you use libraries that rely on Class.forName() to work (and there are plenty), this could get very painful.
If you really, really cannot afford the extra disk space and memory look at OSGi or Spring DM. They have solved this problem, but at the price of increased complexity.
Put all the shared jar files under common\lib folder of weblogic. common\lib is accessible by all the deployed apps.
Well first of all you can put your libs all on the same place and have your build process import the ones needed.
Has for on deploy the new Weblogic 10 has a lib folder in each domain where you can put shared libs. i dont think that is possible before Weblogic 10
You can put the jars in their own ear file and deploy it as a shared library.
You can also put the wars in an ear and add the shared jars to APP-INF/lib. This is a Weblogic extension of J2EE, so it won't work on other servers.
I'm currently using another approach.
Create a central repository folder and put all common libraries in there.
In each project you can create a reference to all needed libraries. In Subversion it works with externals
Everytime, the local working copy is updated, the externals are updated to, so you just need to commit to the central folder and it's automatically distributed to all projects.
I am creating a web application using Eclipse (3.4), and m2eclipse. I am using the deploy goal but often prefer to use the run goal for the use of the embedded tomcat in the maven tomcat plugin. I added the xalan jar to the endorsed dir as I had problems with the xalan that is in the rt.jar.
It works fine on deployment, but I can't find a way to define the endorsed dir in the embedded tomcat as well.
The best for me is to have any solution in the project level (POM.xml) so that any other developer can enjoy running the application on an embedded tomcat.
Any idea?
Thanks,
Ronen.
This is not really a solution per se, but I would avoid using the endorsed dir, and make my own jar with the xalan version you want, with the package rewritten. This is employed by many open source projects because of the clash with the shipped xalan. There is a tool for jar rewriting, but I have forgotten its name and my google-foo seems to be lacking...