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
