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.
>
> 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)
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)
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)
any opinions or other scenarios?
david jencks
>
> ----- Original Message -----
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: "jboss-dev" <[EMAIL PROTECTED]>
> Sent: Monday, September 10, 2001 11:16 AM
> Subject: [JBoss-dev] Mbean package deployment and undeployment
>
>
> > I thought I'd write a note explaining what my recent changes to the
> mbean
> > deployment in rh do.
> >
> > 1. Recursive deployment. The classpath elements in a *service.xml file
> may
> > be used to specify dependencies on jar and zip archives, sar archives
> > (containing a jboss-service.xml file), or *-service.xml files. Each
> listed
> > dependency is loaded before the mbeans in the current *service.xml file
> are
> > created and started. There's a test case for this in jmx. This
> > functionality is actually used in the current jboss:
> jbossmq-service.xml
> is
> > in the deploy/lib directory, and is autodeployed after the core
> > jboss-service.xml. jbossmq-service.xml depends on jbosscx.sar (due to
> the
> > jmsra resource adapter), so jbosscx.sar is recursively deployed.
> >
> > 2. Recursive undeployment based on package dependencies. If C depends
> on
> B
> > which in turn depends on A, as just noted deploying C will deploy A,
> then
> > B, then C. Recursive undeployment means undeploying A will undeploy B
> and
> > C. Redeploying A will redeploy B and C automatically.
> >
> > 3. Undeploying a package actually works. Mbeans specified in the
> package
> > are removed, and the classes from the codebase are removed from the
> > classloader system (if they are not also deployed by another package
> not
> > dependent on the one you are undeploying). There are test for this in
> jmx.
> >
> > (As part of the jbosscx reorganization, all jca related classes are in
> the
> > jbosscx.sar, which contains the mbean configuration for the
> > ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq
> > configuration is now in a jbossmq-service.xml file, which depends on
> the
> > jbosscx.sar ( and causes it to be recursively deployed). The
> configuration
> > for the Hypersonic-based DefaultDS is in hsql-default-service.xml,
> which
> is
> > also autodeployed.)
> >
> > The classpath element in a *service.xml file works like this:
> >
> > attribute codebase
> > -- if missing, specifies the jboss.system.libraryDirectory set on
> startup
> > -- if . specifies the same directory as the current file is in (not
> > tested with http)
> > -- if a url, specifies the url.
> >
> > attribute archives is a comma delimited list of jar, zip, sar, and
> > *service.xml packages the current package depends on.
> >
> > If the archives attribute is missing and the codebase is a file url,
> all
> > jar and zip files in the directory are added.
> >
> > There can now be multiple classpath elements.
> >
> > Known problems:
> > Currently, deploying an already deployed package undeploys and (re)
> deploys
> > it. This can cause churn if you are autodeploying a set of
> interdependent
> > packages. Say C depends on B which depends on A. If the autodeployed
> > picks C to deploy first, when it deploys B C will be undeployed and
> > redeployed, and when it deploys A B and C will be undeployed and
> > redeployed. I can think of 2 solutions:
> >
> > a. deploying an already deployed packaged does nothing. To refresh,
> > undeploy and redeploy. I like this one, but it changes current
> behavior.
> >
> > b. The autodeployer keeps track of a "autodeployment session" and
> recieves
> > notifications of deployed packages. It doesn't try to deploy anything
> it
> > received a deploy notification for in the current session.
> >
> > All comments appreciated.
> >
> > thanks
> > david jencks
> >
> > _______________________________________________
> > 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
