I'm seeing some odd stuff that I suspect no one has encountered before, unless they actually enjoy writing resource adapters for a living. :-)
See issue 13111 (
https://glassfish.dev.java.net/issues/show_bug.cgi?id=13111) for some background.
Briefly: I have a resource adapter that, in its start() method, per the JCA contract, kicks off some long-running work via a bootstrapContext.getWorkManager().startWork(work) call. You can read about this call here:
http://download.oracle.com/javaee/6/api/javax/resource/spi/BootstrapContext.html
In short, it's a way to start a new thread under the container's control.
Anyhow, my Work instance does some stuff that involves some just-in-time compilation and resource loading (this is a Drools resource adapter that among other things might have to use the Drools compiler to compile some .drl files). So it uses the context classloader at that point. Since we've barely started deploying the resource adapter, I have to assume this is the deployment classloader. (I was recently taught that Glassfish apparently uses one classloader during deployment and another at runtime; I would love to know why, as this presents all sorts of problems.)
Issue 13096 (
https://glassfish.dev.java.net/issues/show_bug.cgi?id=13096) was causing problems there, but is fixed in the latest nightlies.
So, anyway, the Drools compiler lurches along and finds some things here and there. But it doesn't find certain classes. This makes sense, I think, since the ear hasn't been fully deployed yet (we're still in the Resource Adapter deployment stage, and the Work instance has been kicked off asynchronously so we're running in parallel). So it's possible it hasn't placed all the lib/jar files into the classpath yet.
Anyway, what gives here? :-) I'm following the JCA specification to the letter, but I'm being supplied with a classloader that doesn't have a full classpath yet.
I understand the issues: my resource adapter is a module inside my ear file, and can't be deployed until the ear file itself is deployed, but the ear file can't be deployed until my resource adapter is deployed, since obviously my resource adapter is part of it. Chicken, egg, etc.
But surely the Work instance could be held until all the REST of the deployment completes normally? I mean, isn't the point of the WorkManager that the deployment shouldn't be held up by the work it's going to dispatch?
So what I would propose in conjunction with issue 13111, and freely recognizing that I have a myopic view of the whole thing, is: don't perform the WorkManager work until the ear file has deployed. Unsuccessful Work completion, as far as I can tell from the JCA specification, should not prevent a .rar file from deploying. So why not hold off on dispatching the Work until the whole .ear is deployed? My Work instance does not expect to be dispatched at any given point in time, and so it shouldn't matter when a Work instance is kicked in the butt to do its job.
Thoughts?
Best,
Laird
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=481091