|>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.
|
|Allright. That�s the resolution/reconcilation to the slightly different
|views that
|Toby, Marc and me had developed. To me, the meta-data/classloader
|thing were
|two related, but separate aspects.
nah nah nah... let him come and explain why the externalizable metadata as a
tree representation of XML should deal with CL, frankly he is coming out of
left field with this...
if it is inVM it is useless and it is extraVM it is broken :)
|So we would have a generic deployer package containing:
|
|* an abstract MetaData class with a basic implementation of parentship and
|classloader association
relax Dr Jung, you were closer to a solution 2 days ago (imho) specify the
dependency of classes *somehow* in the XML. Certainly a "System" tag isn't
in our scope. I think he is thinking CL at runtime and at runtime YES, the
System CL is the grand Daddy of all CLs but not on XML !!!!
The class loader association is in memory, whether it is exposed in
"metadata" or through a service is "repackage-itis" and broken if we are to
externalize the refs and look up the CL in the VM.
|* a DeployerMBean interface that provides for url-based access/manipulation
|to/of the MetaData
sure... we sort of have that today. And here do you propose to pass the
hashcode of the CL so that we can manipulate through 8082 the CL associated
? <snore/>
|* the ApplicationDeployer aka SystemDeployer which implements the "logical"
|application management and delegates deployment to the proper module
|deployers.
ahem, yes but as "ApplicationDeployer" ;-)
This is what we are talking about since the beginning, now to see code.
|>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.
|
|Exactly what I had in mind by the "extending the metadata" issue.
|
|Maybe MetaData could also have a static public MetaData
|getCurrentMetaData()
|method that returns the most specific instance that is associated with the
|current context classloader? For particular purposes, such as the existing
|J2EEDeployer/ContainerFactory/EmbeddedTomcat interplay and (much more) our
|meta-data driven ZOAP serialisation, this would ease access through
|inspecting the current thread.
|
|Let me checkin some preliminary code skeletons this afternoon. As
|Marc said,
|we must now get some flesh to the bones ;-)
Yes at this point, we are all waxing poetic with "transitive closure of
system metadata" (including me) however we don't know what we are talking
about.
and no rickard don't go in it and name it "SystemMetaData" and say "see
guys? there it is" cause I will come spank you.
Ok I need to update the website and make a few phone calls today but I will
really try to sit down and flesh it out :)
I suspect a 100 lines and basta :)
marc
|
|Best,
|CGJ
marc
|
|
