-----Urspr�ngliche Nachricht-----
>Von: Rickard �berg [mailto:[EMAIL PROTECTED]]
>Gesendet: Dienstag, 19. Dezember 2000 09:15
>An: jBoss Developer
>Betreff: Re: [jBoss-Dev] Complex J2EE Deployment was RE: Proposed
>refactoring...
>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. I really like this idea.
So we would have a generic deployer package containing:
* an abstract MetaData class with a basic implementation of parentship and
classloader association
* a DeployerMBean interface that provides for url-based access/manipulation
to/of the MetaData
* the ApplicationDeployer aka SystemDeployer which implements the "logical"
application management and delegates deployment to the proper module
deployers.
>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 ;-)
Best,
CGJ
