Menu
▾
▴
#107 ServiceDeployer changes [+ RARDeployer]
IMPORTANT NOTE: do a build.sh clean or remove
core-service.xml from deploy/lib after you receive
these changes!
Changes to ServiceDeployer:
Added local directory copy functionality. Include one
or more <local-directory path="path"/> elements in your
jboss-service.xml file and the contents of path in your
sar will be copied verbatim into the db directory. If
the contents are already there they will not be
overwritten, and nothing is removed on undeploy.
Added undeploy functionality to depends tag. If a
package P has a depends tag indicating it requires
mbean x, not only will deployment of the package's
mbeans wait for x, if x is undeployed (from a package
undeployment), the mbeans from P will be undeployed.
Separated classpath and mbean functionality from sar
deployment. Previously deploying a sar S1 with a sar
S2 in the jboss-service.xml classpath element caused
recursive deployment of S2, including its mbeans. Now,
this scenario will only add S2 to the system classpath:
to get the mbeans for S2, you have to explicitly deploy
S2. You can do this before or after S2 has been added
to the classpath. This change makes the effects of
deployment and undeployment considerably easier to predict.
Suspension now works like this: if sar S1 has package
J1 in its classpath, undeploying J1 will undeploy S1's
mbeans, leaving S1's classes in the classpath.
Redeploying J1 will redeploy the mbeans from S1.
Again, this localizes the effects of redeployment.
In addition, the RARDeployer now adds the rar classes
to the system classloader rather than a rar-specific
classloader. This means you don't need an extra copy
of the InteractionSpec etc classes or interfaces in the
system classpath in order to use them.
The DeployerMBeanSupport now will not undeploy a
deployed package if you try to [re]deploy it. You have
to undeploy it explicitly, then deploy it again. I
plan to modify the autodeployer shortly to explicitly
undeploy and deploy when it detects a timestamp change.