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
