[
http://jira.jboss.com/jira/browse/JBAS-4762?page=all ]
Brian Stansberry updated JBAS-4762:
-----------------------------------
Affects: [Compatibility/Configuration, Release Notes]
Resolved by adding a "WebAppClusteringDependencyDeployer" to
war-deployers-beans.xml. Deployer injects the necessary dependencies into
JBossWebMetaData.
Deployer is enabled in both the 'default' and 'all' configs. The absence
of the clustering cache in the 'default' config will prevent webapps marked
<distributable/> from deploying successfully.
Note that this introduces a behavior change from AS 4.x, which would allow
<distributable/> webapps to deploy in 'default', after logging a WARN saying
clustering services are not available. Users wanting the old behavior in
'default' can simply comment out this deployer.
I chose to leave this deployer in place in 'default' because IMHO deploying a
<distributable/> webapp in an environment that doesn't support the semantic is
an error condition. The user should need to do something (i.e. comment out
WebAppClusteringDependencyDeployer) to signal that they want the deployment to succeed.
Make distributable webapps depend on the clustering cache
---------------------------------------------------------
Key: JBAS-4762
URL:
http://jira.jboss.com/jira/browse/JBAS-4762
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Web (Tomcat) service, Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta4
In 4.x, in the all config the JBossWeb service itself depends on the
jboss.cache:service=TomcatClusteringCache mbean. In AS 5 this is not viable, as the
relevant bean is the TomcatDeployer, which can't/shouldn't depend on a deploy
folder service like the cache. In any case, it's really the <distributable/>
webapps that depend on the cache, not the deployer.
The TomcatDeployer should be adding a dependency on the cache to deployments where
WebMetaData.getDistributable() is true (probably in superclass
AbstractWarDeployer.deployWebModule()).
A problem with this dependency-based approach is it breaks the current
"feature" whereby apps marked <distributable/> can be deployed in the
default config. When this is done, the 4.x deployment code detects the absence of the
cache and falls back on using the standard non-distributable session manager. That
won't work if we introduce a deployment dependency.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira