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 ?

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

On 10/08/2009 05: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 > Julien, Matt says that he has all the scenarios we've talked about working with the container specific impl (existing eXo portlet, existing JBoss Portal portlets), should we just go and proceed ? I don't understand your issues at this point. Thomas. >> >> 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 >>> >> > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

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.

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 >> >

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 >>>> >>> >> >