mailto:bstansberry@jboss.com wrote:   h4. Usage   First, I create a common/deploy folder. Next, I move each war in server/default/deploy to common/deploy, replacing it with an XXX-activator-jboss-beans.xml file. The wars are admin-console.war, jmx-console.war, jbossws-console.war, invoker.war and ROOT.war.   A typical XXX-activator-jboss-beans.xml looks like this:   <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:bean-deployer:2.0">     <bean name="AdminConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">             <property name="profileService"><inject bean="ProfileService"/></property>       <property name="profileFactory"><inject bean="ProfileFactory"/></property>       <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>       <property name="contextName">admin-console</property>       <!-- Build a profile from the contents of this single URI -->       <property name="singleURI">${jboss.home.url}common${/}deploy${/}admin-console.war</property>    </bean>     </deployment>   The MC bean exposes some other properties in case you want to do something more sophisticated:   <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:bean-deployer:2.0">     <bean name="JmxConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">             <property name="profileService"><inject bean="ProfileService"/></property>       <property name="profileFactory"><inject bean="ProfileFactory"/></property>       <property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>       <property name="profileDomain">default</property>       <property name="profileServer">default</property>       <property name="profileName">jmx-console</property>       <property name="serviceName">jboss.web</property>       <property name="hostName">localhost</property>       <property name="contextName">jmx-console</property>       <!-- Build a profile from the contents of these URIs -->       <property name="URIList">          <list elementClass="java.net.URI">             <value>${jboss.home.url}common${/}deploy${/}jmx-console.war</value>          </list>       </property>    </bean>     </deployment>   The example above doesn't actually do anything sophisticated; it shows the properties with their default values.  

mailto:bstansberry@jboss.com wrote:   h4. Issues   I see a few issues with the above:   1. Need for XXX-activator-jboss-beans.xml. It would be slick to somehow configure the war such that some deployer extracts relevant metadata, detects an "on-demand configuration, wires things up with JBoss Web, and then stops the deployment before anything expensive starts, with deployment continuing when the app is requested. Nice, yes, but much harder. For now I think we should stick to the KISS principle. The "profile activation" approach used here has been in use in the AS for well over a year. 2. Integration with mod_cluster. This is a problem, as mod_cluster will know nothing about the "on-demand" context until the war is actually deployed. So, the load balancer will not know to route requests to the server. This needs fixing, perhaps with a hook into mod_cluster to allow the MC bean to tell it about the on-demand context. I don't think this is a critical problem until AS 6.0.0.CR1 though. We already configure mod_cluster to ignore all the standard apps we deploy; users have to configure ModClusterService to expose them via the load balancer. IMHO until CR1 it's OK to force users who want to expose a standard app to move it back into the deploy/ dir. 3. Virtual host aliases and multiple contexts associated with the same application. The attached prototype doesn't deal with this, but that shouldn't be anything technically difficult to implement.