Thanks for the help - I find that I'm struggling to get my head around this stuff. It's not exactly touched on at University (and I've only got the internet for help).
Anyway, I think it's starting to come together. My current problem is that I'm getting a file not found error, of the form: /home/andrew/geronimo-jetty6-javaee5-2.1.1/repository/com/proaxiom/maps/ MAPS/5.9.0/MAPS-5.9.0.ear/lib/maps_www.jar!/quartz-job.xml Now, the file quartz-job.xml is indeed inside maps_www.jar, and that is, indeed, the path to the JAR file. Which is more likely to be the problem: Something's not using the correct method to extract files from a JAR, or: I've stuck it in the wrong place? If it's the first, there's not much I can do about it, as it's the Quartz code, not code I've got access to. I'll try moving them while I wait for your response, as that seems the solution most likely to work. Thanks, - Andrew On Wed, May 28, 2008 at 11:20 AM, David Jencks <[EMAIL PROTECTED]> wrote: > > On May 27, 2008, at 3:50 PM, Andrew Thorburn wrote: > > Yes, that helps a lot. It's not the answer I wanted, but it does answer the > question :). > > I guess that means I'll have to play around and see what can be done. > > How do separate classloaders work with statics (fields, etc). e.g. If I > have a class A with static field B in the WAR, and again in the EJB jar, > will I have two instances of that field, such that the WAR has one (because > it has it's own separate classloader), and the EJB will have another? If so, > then that's a problem. > > > With normal parent-first classloader delegation, only one copy of the class > will be loaded, the one in the ejb jar. If you turn on inverse-classloading > in the war, then you will get two copies: one in the ejb jar visible to the > ejbs, and one in the war, visible to the web app. IMO it is almost never > appropriate to turn on inverse-classloading. I didn't discuss this detail > in my first reply. > > > > I don't know much about Java Beans or Enterprise Java Beans, so this might > be a bit silly, but: Can I put the MDB in the WAR? Or does it *have to* have > it's own JAR? > > > An mdb has to be in an ejb jar. (or a jar accessible to the ejb apps > classloader, such as in a jar in an ear lib directory). Since the web > app/war has a separate classloader that is a child of the ear classloader, > there's no way you will be able to get the mdb visible to an ejb app if it > is in the war. > > I guess I should mention that I think openejb standalone has a mode in > which you can do something like what you seem to want to do, but it is not > standard javaee. I don't know too much about it. > > hope this helps > david jencks > > > > On Tue, May 27, 2008 at 6:03 PM, David Jencks <[EMAIL PROTECTED]> > wrote: > >> >> On May 26, 2008, at 6:28 PM, Andrew Thorburn wrote: >> >> Ok, it now works. Well, kinda. >>> >>> I think I must have originally also had a lib directory directly inside >>> the EAR, as well as in the WAR, which was what was confusing Geronimo. >>> Removed that, and my bean didn't start. Removed the (small but important) >>> bits of code that relied on that, and everything works. Except it doesn't do >>> logging anymore for my MDB. Works fine everywhere else. >>> >>> Apologies for not having the faintest idea what my problem was, but there >>> we go. I now have a new problem, however: How do I reference the stuff in >>> the WAR from my MDB JAR? I'm sure I saw information on this somewhere, but I >>> closed it because I thought I had a different problem :(. I can't duplicate >>> the JARS, as I'm sure that'll cause a vast multitude of problems. I really >>> just want to be able to reference them easily, so that I don't have to worry >>> about this when coding my application. In fact, it's going to be very >>> necessary to communicate between the WAR and the MDB for it to be of any use >>> at all (AJAX stuff communicating between browser and database via Java app). >>> Basically need the WAR to be processed first, and then have the MDB JAR >>> processed, so that I can then reference all the classes in the WAR. >>> >>> Is this possible? If not, what's the best alternative? Can I chuck my MDB >>> into the WAR? I'd be very surprised if I could do that. And I don't know if >>> that would solve any of my issues anyway... >>> >>> The exact location of the classfiles doesn't matter, just so long as it >>> all works... >>> >>> Feh. This is starting to do my head in. Won't be posting again for nearly >>> 24 hours (I only work part-time). >>> >> >> I'm not sure I've understood clearly what problem you are having. Maybe >> if I explain the classloader structure your app has and what I think you >> need to do it will help. >> >> For an ear based application with no javaee app clients, there is one >> "base" classloader that includes all the ejb jars, all the rars, and all the >> jars in the lib directory. >> >> Then for each war inside the ear, there is a separate classloader that is >> a child of the ear classloader that contains the jars in WEB-INF/lib and the >> classes in WEB-INF/classes. Since this is a child of the ear classloader, >> all the code in the war can see the classes in the ear (ejb, connector, and >> lib). Also, since these war classloaders are children of the ear, nothing >> in an ejb, connector or lib jar can see anything in any war classloader. >> >> I think what you need to do is put any classes that need to be accessible >> to both the ejb app (such as your mdb) and the war(s) in either the ejb jar >> or in a jar in the ear's lib directory. Putting any such class anywhere in >> any war file will definitely prevent it being accessible from the ejb >> application. >> >> Hope this relates to what you are asking about :-) >> david jencks >> >>> >>> >>> Anyway, thanks again, >>> >>> - Andrew >>> >> >> > >
