"Jung , Dr. Christoph" wrote:
> 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
No, the MetaData is a concrete thing that you can attach arbitrary
facets to (like a classloader). The MetaData is the "trunk" of the tree
sort of.
> * a DeployerMBean interface that provides for url-based access/manipulation
> to/of the MetaData
Not quite with you. Are we talking about the "deploy(URL, metadata)"
method here?
> * the ApplicationDeployer aka SystemDeployer which implements the "logical"
> application management and delegates deployment to the proper module
> deployers.
Yes, that is the key I think.
> >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.
That would be possible. Not sure if it's good though. Maybe.
> Let me checkin some preliminary code skeletons this afternoon. As Marc said,
> we must now get some flesh to the bones ;-)
Ok, but as I said before, this whole thing hinges on the availability of
the new metadata model, since that is the core of it.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
