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
>