|You're pretty much on target, except the second parameter should be the
|EAR metadata and not a classloader. Then, the classloader is one aspect
|of that metadata. This will allow the ContainerFactory to resolve
|ejb-link's easily: check in "self" and all EJB JAR's that can be reached
|by going to the EAR metadata.
.... hmmmm
the EAR metadata is something "supra-VM", the ClassLoader isn't.
To me this is a VM service ( what I call CL service)... to pass the CL
knowledge is indeed "meta-data" with respect to the application (in fact it
is data that belongs to the container VM when it is associated with the
ear).
|If we add the "system" notion, then the EAR metadata would have a parent
|too, so the ejb-ref's that an ejb-link can resolve to is the transitive
|closure of the entire system.
he he.... rickard....
"I want you to put your hands high up in the air and run around the run
saying 20 times....etc etc"...
ok the "transitive closure" to the entire system is not interesting in
scoping an application.. An application is an application and the system can
have many of these. Why should the assembler worry about the "target
system"... That the parent CL is the "System" CL is another matter entirely,
why this should be seen at the XML layer is beyond me :)
marc
|
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
