[gatein-dev] Tomcat Gatein and WCI behaviour

[Matt Wringe]

On Wed, 2009-10-14 at 11:08 +0200, Julien Viet wrote:
> this is ok

ok, its been committed now.

> thanks for the good work.
> 
> On Oct 14, 2009, at 6:17 AM, Matt Wringe wrote:
> 
> > On Fri, 2009-10-09 at 01:18 +0200, Julien Viet wrote:
> >> It means basically that if we have Generic application or legacy eXo
> >> deployment with either the Generic solution (obvious here) or native
> >> solution it will work the same.
> >>
> >> It is fine for me to use native solution if we can ensure the
> >> compatibility of the native tomcat solution by having an integration
> >> test that deploys a generic and an exo legacy application with the
> >> native tomcat.
> >
> > The wci tests have been updated. We now test the generic and exo  
> > legacy
> > apps being deployed on the native wci implementation (for both Tomcat
> > and JBoss).
> > The wci tests have also been updated to test the exo backwards
> > compatibility support using the generic wci implementation.
> > Tests all passing in hudson.
> >
> > So is it now ok to switch the Tomcat version of Gatein to use wci
> > native?
> >
> >> On Oct 8, 2009, at 5:51 PM, Matt Wringe wrote:
> >>
> >>> On Thu, 2009-10-08 at 16:57 +0200, Julien Viet wrote:
> >>>> Hi Matt,
> >>>>
> >>>> can you tell us what happens if a war file integrated with the non
> >>>> native solution (either as the Generic or eXo legacy) is deployed
> >>>> inside a server that has a native integration ?
> >>>
> >>> The will refer to the generic and eXo legacy servlets/servlet
> >>> listerners
> >>> as just the generic servlet to keep things simple, they do basically
> >>> the
> >>> same thing.
> >>>
> >>> When the generic servlet is initialized it will register itself with
> >>> the
> >>> GenericServletContainerContext.
> >>>
> >>> If the GenericServletContainerContext is registered with a
> >>> ServletContainer, then the webapp will registered with the
> >>> ServletContainer.
> >>>
> >>> If the GenericServletContainerContext is not registered with a
> >>> ServletContainer, then the webapp will be added to a list. Nothing
> >>> will
> >>> happen with that list until/unless the  
> >>> GenericServletContainerContext
> >>> registers with a ServletContainer.
> >>>
> >>> In order for the GenericServletContainerContext to register with a
> >>> ServletContainer, it needs to be added as a listener to the
> >>> integration
> >>> war's web.xml.
> >>>
> >>> When using the native integration, we don't specify the
> >>> GenericServletContainerContext in the web.xml so it never gets
> >>> registered with a ServletContainer.
> >>>
> >>> The native integration uses its own ServletContainerContext which  
> >>> gets
> >>> register with the ServletContainer. This is done by specifying a
> >>> special
> >>> servlet to use in the web.xml of the integration war.
> >>> The native integration monitors all deployed webapps and will  
> >>> register
> >>> them with the ServletContainer It doesn't matter if they use the
> >>> special
> >>> servlets or not.
> >>>
> >>> If one of these webapps happens to have a generic servlet, the  
> >>> servlet
> >>> will still be registered with the GenericServletContainerContext,  
> >>> but
> >>> since the GenericServletContainerContext is not registered with the
> >>> ServletContainer, it is just added to the list and forgotten.
> >>>
> >>>>
> >>>>
> >>>> On Oct 8, 2009, at 4:44 PM, Matt Wringe wrote:
> >>>>
> >>>>> [sorry for the long email]
> >>>>>
> >>>>> The behaviour between the Tomcat and JBoss versions of GateIN is
> >>>>> different in regards to the deployment of portlets.
> >>>>>
> >>>>> The WCI module has two different ways in which portlets can be
> >>>>> deployed:
> >>>>>
> >>>>> - generic deployment: the web.xml of the portlet contains a  
> >>>>> special
> >>>>> servlet or servletlistener which discovers the portlet.
> >>>>> The special servlets add their webapp to a list which wait for a  
> >>>>> wci
> >>>>> generic listener to be run. If the generic listener is not run,  
> >>>>> then
> >>>>> the
> >>>>> list still gets created but nothing happens with it.
> >>>>> This is similar to how the eXo portal would handle portlet
> >>>>> discovery.
> >>>>>
> >>>>> - container specific: the server is setup to intercept wars being
> >>>>> deployed. The portlet itself doesn't need to have anything special
> >>>>> done
> >>>>> to it so that it can be deployed (ie no special servlets/listeners
> >>>>> needed). This setup will find portlets regardless if the special
> >>>>> servlets are added or not.
> >>>>> The special servlet/listeners will still create the list of  
> >>>>> webapps,
> >>>>> but
> >>>>> since the wci generic listener is not deployed nothing will happen
> >>>>> with
> >>>>> that list.
> >>>>> This is similar to how the JBoss portal would handle portlet
> >>>>> discovery
> >>>>> (ie nothing special needed).
> >>>>>
> >>>>> In order to determine which type to use we need to specify it in  
> >>>>> the
> >>>>> web.xml of the integration war. They are mutually exclusive, so if
> >>>>> you
> >>>>> specify both in the integration war then the first one that is
> >>>>> started
> >>>>> will be used.
> >>>>>
> >>>>> In the JBoss version of GateIN we use the container specific
> >>>>> implementation. This means we have (mostly) backwards  
> >>>>> compatibility
> >>>>> with
> >>>>> portlets that would have worked on JBoss Portal or eXo portal.
> >>>>>
> >>>>> In the Tomcat version of Gatein we use the generic implementation.
> >>>>> This
> >>>>> means we have (mostly) backwards compatibility with portlets that
> >>>>> would
> >>>>> have worked on eXo portal.
> >>>>>
> >>>>> The Tomcat version can be switched to use the container specific
> >>>>> implementation by removing the commenting around the servlet in  
> >>>>> its
> >>>>> web.xml (and commenting out the listener).
> >>>>>
> >>>>> I would like to switch the behaviour of the Tomcat version to use
> >>>>> the
> >>>>> container specific wci implementation so that both versions behave
> >>>>> the
> >>>>> same and so that we can get backwards compatibility with JBoss
> >>>>> portal
> >>>>> portlets.
> >>>>>
> >>>>> Is there any objections to switching over to this behaviour?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> gatein-dev mailing list
> >>>>> gatein-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
> >>>>
> >>>
> >>
> >
>