I'm less than thrilled with the complexity, however I still think recursive
deployment is a good enough idea to include, and if we have it I want it to
work properly. Can you think of a way to get reasonable results without
these rules? I'd be delighted to see it!
thanks
david jencks
On 2001.09.10 17:15:57 -0400 David Maplesden wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
