0

I have a jar file that I want to put in the shared lib of my application server (WebLogic). The jar contains some classes that are implementing interfaces that are located inside of the war deployment. And the deployment has a Spring singleton that initializes the class that is contained in the shared jar.

So what I guess happens is that class is not being able to load because interfaces are not loaded yet (they are in the deployment), and when the classloader tries to load that class it probably gets some compilation error (I don't see it anywhere) and doesn't load it, and when the deployment tries to instantiate something that hasn't been loaded (shared jar) - it errors out.

So the question is what do I do here? How do I configure all this to work? I really don't want to duplicate the jar that contains all the interfaces in the shared folder. (it is required to be one whole .war file).

Thanks.

P.S. unfortunately I don't have any errors/exception while classloading of the domain lib (shared) folder. I have only java.lang.NoClassDefFoundError when I try to instantiate it.

nisenish
  • 99
  • 1
  • 1
  • 7
  • I don't think you have a choice. Move the interfaces to the lib directory. At least try it and see if it works. Why are you ok with the implementations in the shared lib but not the interfaces? – John Watts Jun 26 '12 at 01:00
  • I have tried it, in fact that's how I implemented it originally, but folks at work don't wont to separate the war archive, they say everything should lie within one deliverable. I am trying the .ear now, with APP-INF/lib folder, I will update the feed here if it works. Also regarding the implementations - these are customer implementations, and are optional; this is not our deliverable as a product. – nisenish Jun 26 '12 at 07:34

1 Answers1

1

I don't think you want to use the shared lib directory. It sounds like you want to add a customer's jar to a single war's classpath without requiring them to modify the war or having multiple deliverables. I see two ways. Both require pointing at the local filesystem directly which is ordinarily a bad idea in webapps. I think it is possibly ok here because you are pointing at optional customer-supplied classes. The whole point is that this extensibility mechanism can change from outside the webapp. But it means that the customer must deploy the jar identically on all systems, manually. This can be a hassle in a cluster and it obviously requires direct filesystem access to the appserver.

  1. I don't remember if this works, but you should be able to put a jar in the webapp's WEB-INF/lib that has META-INF/MANIFEST.MF whose classpath points outside the war. This would have to be a known, hardcoded location. It can be a relative path which would be relative to the current working directory. This is often the appserver's home directory or a home directory for your domain.

  2. Construct your own ClassLoader instance. It should probably be a URLClassLoader so you can have your customer provide either a directory or a single jar file. Set this classloader's parents to be the webapp's classloader. It can point at a location determined at runtime. The problem here is using this classloader in all the right places. I don't know any general way to do it so I would recommend the first option.

John Watts
  • 8,717
  • 1
  • 31
  • 35
  • wow, it worked! thanks a lot! it worked with relative URL, but not with absolute, I'm still trying though. – nisenish Jun 26 '12 at 17:34