Time for my two cents...
I have just finished incorporating my scheme (the use of the depends
elements) with David J's and it seems to work for the simple examples I have
tested it on. I am a bit unsure whether or not to commit the changes (after
more testing) though because the two schemes don't mesh particularly well in
the source. Some odd behaviour would be possible if deployments attempt to
use both mechanisms at the same time.
In my opinion some of the problems or discussion points that are coming up
in this thread are because the "recursive deployment" model is not always
suitable, when all you want to do is specify a simple dependency. The
naming service (JNDI) is a classic example, where many of the other services
need this service to be started before they will successfully start but it
is easy to deploy on its own.
The recursive deployment mechanism I feel is excellent for deploying and
undeploying applications that are spread across multiple sar's and comprise
multiple mbean services. I don't think it is so effective at specifying
simple dependencies between services, especially the core ones that exist
during the startup process.
David
> -----Original Message-----
> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 11, 2001 8:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
>
>
>
> > On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
> > > For the jbossmq-service.xml example, does reploying
> jbossmq-service.xml
> > > cause
> > > jboss-service.xml to be undeployed and redeployed?
> >
> > No, jboss-service.xml is not listed as a dependency of
> jbossmq-service.xml.
> But JBossMQ requires that a JNDI naming service be present,
> so how is that
> dependency specified? Also in the future I want to make
> better use of the
> JBossSX framework for authentication and authorization in other JBoss
> services
> to avoid the "passwords spread all over the place"
> configuration issue we
> now
> have so this is another future core service dependency.
>
> > >
> > > Likewise, would just undeploying jbossmq-service.xml undeploy
> > > jboss-service.xml?
> >
> > In the current situation, as just noted, no. Hmmm. If it
> was listed, I
> > think it would undeploy, which seems like a bad idea.
> >
> > What would be the desirable behavior in these scenarios?
> >
> > 1. B and C both depend on A. B and C are explicitly
> deployed, causing A to
> > be recursively deployed. B is undeployed. What happens?
> > - A remains deployed, since C is still depending on it.
> (good, I think)
> > - A is undeployed, causing C to be undeployed. (bad, I think)
> >
> A should remain deployed.
>
> > assuming A remains deployed, then undeploy C
> > - A is now undeployed, since nothing depends on it and it was not
> > explicitly deployed. (good, I think)
> > - A remains deployed. (bad, I think)
> >
> Things are not this black and white. Just because I don't
> have any services
> deployed that depend on A does not mean that it should be
> undeployed. The
> naming service is a perfect example. Just because I don't
> have any services
> deployed that depend on the naming service does not mean that
> I don't have
> external clients using the naming service.
>
>
> > 2. B depends on A. A and B are explicitly deployed. B is
> undeployed. No
> > other packages depend on A.
> > - A remaings deployed, since it was explicitly deployed
> (good, I think)
> > - A is undeployed since nothing depends on it.(bad, I think)
> >
> A remains deployed, since it was explicitly deployed. This is
> the naming
> service
> example as it will be explictly deployed and many other
> services will depend
> on it.
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
