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 <[EMAIL PROTECTED]> 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 > > >
