Bug 4575 - Spec should say to use TCCL for artifact loading rather than System CL (SE) or EE CL
Spec should say to use TCCL for artifact loading rather than System CL (SE) o...
Status: RESOLVED FIXED
Product: jbatch
Classification: Unclassified
Component: source
1
PC Windows
: P5 enhancement
: ---
Assigned To: cvignola
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-19 04:47 UTC by ScottKurz
Modified: 2013-01-25 18:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2013-01-19 04:47:39 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...
Comment 1 cvignola 2013-01-25 18:13:46 UTC
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."
Comment 2 ScottKurz 2013-01-25 18:20:07 UTC
Chris,

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.

How about:  

"The batch runtime will use standard techniques for selecting a classloader to load a given batch artifact, starting from a given JobOperator invocation."
Comment 3 cvignola 2013-01-25 18:46:48 UTC
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.