Re: [gatein-dev] Tomcat Gatein and WCI behaviour

this is ok

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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>> >> >