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