Well,
after struggling to get a working jboss startup using only the recursive
dependencies, I am inclined to agree with you that relying solely on them
is not necessarily appropriate. I don't know a good final answer:
--recursive deployment is nice because it lets you aggregate chunks of
deployment at many levels, and only explicitly deploy the top level.
--mbean dependencies are nice because often you don't care where the code
/configuration for the service is, you just need to make sure it's there.
I'd say, if your stuff doesn't break the current startup, or you have a
modified startup that works, and you have (or plan to have) at least some
minimal tests, commit it. I'd like to see it and make the
explicit/implicit deployment/undeployment on top of it. We can work out
the best balance between the actual use of the two schemes by experiment
and discussion.
Thanks
Cant wait!
david jencks
On 2001.09.10 16:47:32 -0400 David Maplesden wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
