Thanks for your replies. You're right - it's essentially a case of front-end stuff being mixed in with the back-end stuff. That's not something I did - I have no idea who decided that would be a good idea, but that's the way it is right now. There's also a number of other strange design features, but that's another story entirely.

I can't change dependencies without approval from my boss. I suspect he'll be ok with it when he finally realises that there's not going to be an easier way. I'd also worry about it causing flow-on effects to other projects, and then having to integrate my changes with the main branch... But that's a problem entirely unrelated to Geronimo, and doesn't need to be discussed on here.

While I'd appreciate a "Single Class-loader per EAR", I think it would be better if I could convince my boss to straighten out the dependencies. Besides, wouldn't that also cause portability problems if people begin relying on it?

Thanks for your help,

- Andrew

On Wed, May 28, 2008 at 6:46 PM, David Jencks <david_jencks@yahoo.com> wrote:

On May 27, 2008, at 7:32 PM, Andrew Thorburn wrote:

Encountered another part of the problem:

I can package the frontend stuff (that would normally be found in WAR/WEB-INF/classes into a JAR, put that in EAR/lib, and everything works. However, my boss doesn't like that.

Why not?  that's basically the only arrangement that will work....

It sounds a bit like the dependencies between the jars you are dealing with are somewhat mixed up.  In my experience when this kind of problem is straightened out everyone finds it much easier to make progress and makes fewer mistakes.



But if I leave the classes in WAR/WEB-INF, then I get a "Class Not Found" exception from one of the libs in EAR/lib, which is trying to load, via reflection, one of the classes in the frontend. I understand why that doesn't work, thanks to your explanation of the classloader.

Obviously, if I move the libs from EAR/lib to EAR/WAR/WEB-INF/lib, then all is good. Except that my MDB can't find the libs anymore. Bugger.

This problem will occur if I duplicate the libs, yes? I'm reasonably sure it did last time.

I'd expect so.



Further, if I set "reverse-classloading" to true, then I'm bound to get all sorts of problems, and if my MDB tries to access a static method (say, getInstance() for a class where that pattern is used), it will, essentially, call a *different* method to the one the classes in the WAR would call, yes? And return a different object. Not cool.

I think that would produce more problems that it would solve.



Can't really go around moving things, as the logging class (that's basically essential) is in the same package as the reflection-using class.

Any ideas here apart from "Don't use Reflection", and "Don't call from libs to main"?

Now, I think the solution I want is to have the libs able to access the frontend (in WEB-INF), while at the same time being access exactly the same libs from my MDB, and I don't think that's possible in Geronimo?

Not at present.  We could add a "single classloader per ear" flag fairly easily but it probably won't get into a release for a month or two.

I'd start by asking why you can't straighten out the dependencies.

thanks
david jencks