Bugzilla – Bug 4575
Spec should say to use TCCL for artifact loading rather than System CL (SE) or EE CL
Last modified: 2013-01-25 18:46:48 UTC
Sorry for not thinking of this before, as given that the RI is not following the spec here it should have occurred to me already.
In Sec. 7.4 we have:
The batch runtime and the batch artifacts it loads execute in the class loader scope of the their invoker. This means if a typical Java main program starts a job through the JobOperator interface, the batch runtime and the batch artifacts it loads are loaded by the JVM system class loader. If a Java EE application starts a job, the Java EE application class loader hierarchy does the loading.
This sounds like we're saying the current classloader of the invoker of JobOperator.start() should be the starting classloader for artifact loading.
Maybe it's my lack of imagination, but the only way I can see implementing this, and the way I've seen it done in comparable situations, is to start from the thread context class loader (TCCL), not the current classloader of the invoker. That's how the RI is currently implemented in fact (I don't want to sidetrack the discussion but there is a clear bug in the RI right now for artifact loading in an EE environment so don't take the RI as a complete example of what should work !)
Use of the TCCL should also work fine in SE, and in fact the same way as currently stated (since I believe the system CL is set as the TCCL by default, but yet we could use a single set of words to describe both environments).
Besides it being hard for imagine how to implement with the current classloader in EE, using the TCCL leads to more flexibility down the road.... if some piece of code on top of the JSR352 impl wants to use a different starting point for classloading, and they have access to set the TCCL to something else.. then we should use that TCCL value as the starting point.
I know I should be able to dig up some precent but it's late so I'll postpone that for the case anyone disagrees...
I think the spec should be less prescriptive in this section. What's important is to make clear that batch artifacts are loaded according to the class loader hierarchy is effect when JobOperator.start is invoked.
The updated section 7.4 now states only:
"The batch runtime, and the batch artifacts it loads, execute in the class loader scope of the the JobOperator invoker."
I think your wording is unintentionally too prescriptive.
That could easily be read as "the current classloader of the JobOperator invoker".... which is not what you want.
"The batch runtime will use standard techniques for selecting a classloader to load a given batch artifact, starting from a given JobOperator invocation."
That's basically the same as saying it's implementation-specific. Given the section on batch artifact loading (immediately follows) class loader section, I think we can delete the class loader section entirely.