[jboss-dev-forums] [Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"

[jaikiran pai]

JBoss development,

A new message was posted in the thread "Deployment of on-demand web applications":

http://community.jboss.org/message/523592#523592

Author  : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran

Message:
--------------------------------------------------------------
I like the idea of keeping out (selective/unwanted) applications from initial boot process of the server. As for the implementation details:
 
> mailto:bstansberry at 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.
> 
>  
I was thinking if we could avoid these n number of activator configs (one each for each on-demand app).
 
1) Maybe we could have just a single activator-jboss-beans.xml which has a list of applications that need to activated on demand?
2) Or  maybe, we could designate a specific location within the AS deploy structure hierarchy which would be considered as the deploy folder of on-demand applications? So we could just move applications like admin-console to that location.
 
In either of these 2 approaches, internally we would still create the same set of metadata as we would do with n XXX-activation-jboss-beans.xml. But from a end user point of view, the amount of configuration required/exposed would probably be far less.
> mailto:bstansberry at 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.
> 
An additional point to note is related to ServletContextListeners/startup servlets. I have seen applications which tend to do heavy duty stuff within a ServletContextListener/startup servlets (for example, query a DB and loading time consuming data during the start of the application). So the first access to the on-demand application is going to be real slow. Although, it depends on which approach we take for implementing on-demand - as Bela said, either activating it in the background or activating it on first access. Anyway, this probably isn't an issue at all, because we don't set user applications as on-demand by default (does admin-console have this kind of startup servlet logic?). But i guess this is something to keep in mind.

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/523592#523592