Let's get both approaches working as it remains to be seen if the complexity
of
the recursive/implicit stuff is worth the trouble.
----- Original Message -----
From: "David Maplesden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 10, 2001 2:31 PM
Subject: RE: [JBoss-dev] Mbean package deployment and undeployment
> OK, thats good, I wanted your nod before committing, which I will do some
> time today.
>
> My stuff doesn't break the current startup and I have made a few changes
to
> the startup configuration so that it all works nicely. However I will
need
> you to look over the changes and check I haven't stuffed up any of your
nice
> recursive deploy/undeployment things.
>
> > -----Original Message-----
> > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 11, 2001 9:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
> >
> >
> > 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
> >
>
> _______________________________________________
> 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
