Whatever happened to "Simple is the word..." ;-)
David
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 11, 2001 9:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
>
>
> Ok, my thinking is coming into focus. Here's what I'd like to
> implement:
>
> We distinguish between explicitly and implicitly (ie due to recursive
> deployment) deployed packages.
>
> deploying a package will recursively (implicitly) deploy all
> packages it
> depends on (as determined by looking at the classpath
> elements) that aren't
> already deployed. (this happens now)
>
> undeploying a package will undeploy (suspend) all packages
> that depend on
> it (works now) and will undeploy all implicitly deployed packages it
> depends on that aren't used by other deployed packages. Undeploying a
> package A will never undeploy a package B it depends on if B has been
> explicitly deployed.
>
> undeploying and redeploying a package will undeploy and redeploy all
> packages that depend on it. (works now)
>
> If B depends on A, both are deployed, then A is undeployed
> (undeploying and
> suspending B), trying to undeploy B will remove the
> suspension dependency,
> so that when A is redeployed, B will not be redeployed.
>
> To redeploy a package, you must explicitly undeploy it and
> redeploy it.
> This changes current behavior where updating a package redeploys it.
>
>
> Any more rules I need?
>
>
> Thanks
> david jencks
>
> On 2001.09.10 16:41:54 -0400 Scott M Stark wrote:
> >
> > > 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?
> right now, not at all: this is a problem.
>
> 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
