views:

1383

answers:

1

I am deploying an EAR in a WebLogic node with many jars defined in the bootstrap (startWeblogicServer.bat) class-path. The problem is that my ear and the bootstrap contain different versions of the same jars, not only that but certain jars contain extracted third party libraries which also differ in version from the WebLogic bootstrap jars causing all kinds of classpath errors.

I know you can set preferred jars in the EAR application xml but, this can be very tedious to resolve with regards to jars which include extracted third party libraries in terms of understanding all the dependencies..

Is there a correct approach that i need to be taking here? Am i thinking about this in the wrong way? Any help would be greatly appreciated!

So far prefer-web-inf-classes has been recommended but wont work because i'm not deploying a WAR, also prefer-application-packages is what we are currently using but still has the issue described above... Anymore advice out there?? Thanks!

+3  A: 

I think you should remove the JARs from the server bootstrap area and let each domain load the JARs from their individual EAR using the domain level class loader.

You already know this is true, because the approach you're taking is giving you problems.

The only justification for doing it your way is to try and save some disk space by not duplicating JARs in multiple domains. I say that disk space is cheap, and getting cheaper all the time. Common JARs mean common dependencies, and you don't want to force every domain on a WebLogic instance to have to upgrade a JAR just because one citizen needs it.

Remove the JARs from the server bootstrap and duplicate the ones you need in each EAR. Make each EAR, each domain independent of the others.

UPDATE:

You need to get your own server.

Or add the <prefer-web-inf-classes> tag to your configuration.

Consult this for details.

duffymo
Thanks for the answer, problem is that I don't control the WebLogic Server, i.e. we are deploying in another groups server and my team has no control over their bootstrap. In-fact I've recommended that approach and they dont want to budge... The term "dependency hell" comets to mind.
Mo
This helps but another issue is that we aren't deploying a war, just an ear... in the ear from what i understand you have to use:<prefer-application-packages>But this forces you to have to list all the package and classes which you want to prefer:<package-name>antlr.*</package-name> (for example)The problem still remains that antlr could have additional dependencies that we dont know about which are identical to those of the weblogic bootstrap.. No problem if we had one or two libs, but we have many. Resolving these dependencies is proving to be a challenge.
Mo
I didn't say it'd be easy. You need to talk to the owners of your WebLogic instance and discuss the difficulties they're causing you. You might engage owners of other apps deployed on your box to see what their experience is like. It helps to make your case if you're all in agreement.
duffymo