For the jbossmq-service.xml example, does reploying jbossmq-service.xml
cause
jboss-service.xml to be undeployed and redeployed?
Likewise, would just undeploying jbossmq-service.xml undeploy
jboss-service.xml?
----- 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
