views:

1479

answers:

2

Will adding a MANIFEST.MF file with Class-Path attribute to META-INF directory inside EAR influence the order of loading of JARs located in APP-INF/lib under WebLogic 8.1?

A: 

I thought the class loader read JARs as they're required by your application.

I have two questions for you:

  1. Why are you still using WebLogic 8.1? It's off support now, and the current version is 10.x. You're two versions behind. Is this a legacy app that hasn't migrated yet? You'll get a big boost by upgrading, because you'll be using JDK 5 or 6 with the -server option. I'd recommend it.
  2. Why should you care about the order of loading? It should be immaterial to your app how the container loads and manages the beans.

UPDATE:

That sounds different, almost as if you were having conflicts with server JARs. There's that prefer-web-inf-classes setting for that situation. Is that what you mean?

duffymo
1. It's not me, it's my client who is using that ;). And I told them almost the same thing as you :)<br/>2. Because I need to provide a patch to some old library without changing that. One of the usual tricks there is to put your jar before the original jar in the same class loader.
Superfilin
@superfilin regarding point 2), this is indeed how patches (CR) are traditionally applied.
Pascal Thivent
+1  A: 

I don't believe you can control the APP-INF/lib order via ClassPath attribute of MANIFEST.MF.

I've done this a couple different ways, depending on the client.

  1. Add the patch jar to the system classpath for WLS. If you examine domain/bin/setDomainEnv.sh (or .cmd) there should pre, post, patch classpath environment variables. You could try to add your patch jar to the classpath here. This makes it available for all apps, which might not be what your client wants.
  2. Patch somejar.jar & name it somejar-patched.jar. Replace the jar in APP-INF/lib with the "-patched" version.
Wayne Young
I think I'll stick with the second way as I also haven't found anything that can control the order of APP-INF/lib. As to the first way it will have problems for me as the old library jar is located only inside the EAR and putting some of its patched classes to the system classpath will make them appear in a different class loader and they will not see the dependent classes from the JAR that is inside EAR. Basically, it will most likely fail with ClassNotFoundException or NoClassDefFoundException.
Superfilin
Yeah, that can be a problem. Remember, if a java developer dies and goes to hell they have to debug classloader issues for all eternity.
Wayne Young