Hi!
"Jung , Dr. Christoph" wrote:
> J2EEDeployer(EAR)-->EJBJarDeployer(JAR)
> -->WARDeployer(WAR)
>
>
> OO-popes, opinions, please?
As in earlier posts, perhaps add a SystemDeployer on top of
J2EEDeployer. To break it down even further.
> the *deploy(String) are IMHO necessary to interact with the JMX interface
> from
> remote clients.
Not really. It is only necessary if you have a plain HTML
*autogenerated* interface. With a HTML interface that is not
auto-generated it's no problem to convert to URL object before invoke.
Also, with Java GUI client it is no problem. Once the 8082 HTML
interface is deprecated there would be no real reason to keep the string
based methods (IMHO).
> >What is the purpose of the classloader-related methods? Is this an
> >alternative to using the context classloader? I'm not averse to making
> >the classloader stuff more explicit, but why have both?
>
> This would be indeed the IMHO nicer alternative to setting the context
> classloader ... deploy(URL) would hence no more use the context classloader,
> but rather operate like in J2EEDeployer where a completely new classloader
> is constructed.
As in earlier posts, I propose that the metadata object is sent around
instead, and that the CL is a part of that metadata. You would have a
much more powerful way to do things that way.
> But yes, let�s stick for the moment with this "an application can have
> exactly one parent application and this relation is anti-symmetric"
> agreement. Should be extensible afterwards, anyway ...
Good!
> After reading the spec, I also could imagine why and
> how to combine automatic redeployment with ejb-ref annotations.
>
> What I could tear out of Rickards mail and what IMHO will be of good use is
> that we a) have an automatic redeployment feature for "logical" applications
> as you coined it and b) allow ejb-refs to work throughout those logical
> applications.
Yes those are key. And I think both almost rely on the ability to send
the metadata around so that two leaves in the deployment tree can see
each other (just sending the classloader would not give us that).
> what about the following (which is quite similar, but more like I would
> implement it):
>
> 2) if this EAR is currently deployed, undeploy it first (which results in a
> tree of children applications "chld" teared down recursively).
>
> 3a) if the EAR has a parent that�s already deployed, construct a new
> classloader "cl" with the parents one as parent.
>
> 3b) if the EAR has an undeployed parent, construct a new classloader "cl"
> that has a its parent the resulting classloader of deploying the parent EAR.
But if the parent is not deployed you can't deploy the child, since you
don't have the URL to the parent.
All of this would be simpler if the SystemDeployer is introduced, which
has knowledge of the system as a whole.
Then you would do:
1) Deploy System - This will cause the entire thing to be started. This
is the init/start phase
2) Whenever you want to update *a part* of the System, you call
SystemDeployer.redeploy(appname). The SD knows what URL the appname
refers to, and determines the dependency chain (with respect to other
applications), and correctly undeploy and deploy the applications (=the
desired one plus all dependent apps) in the right order (which is
trivial since we have all the info we need).
This would have the following benefits:
* Minimal changes to J2EEDeployer. SystemDeployer only needs "deploy"
and "undeploy" methods to do its work!
* Clear chain of responsibility. J2EEDeployer doesn't do more than what
it's supposed to do (=deploy applications).
..etc..
Sounds ok?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
