Multiple WAR in EAR

[Stuart Douglas]

I have done some investigating into multiple war support in seam. When
running a seam app with multiple wars you and up with two seam apps
running side by side, with different application contexts and
components. The Lifecycle and ServletLifecycle classes both maintain a
static reference to the servlet context (abstracted as a map in
LifeCycle). This means that only one of the seam apps will have their
application context stored in these classes. This seam app will work
fine. The seam app that is not referenced has the following problems:

- Cannot load resource bundles due to use of the wrong ServletContext in
ServletLifecycle (or wrong bundles loaded).

- Timers and async methods started in the second app will be run in the
app context of the first

- The wrong identity component will be created by the IdentityFilter.

- The resource servlet for the second app is run the app context of the
first, and will not work

- Wicket integration for the second app will not work

- Spring integration will not work in the second app

- jbpm integration in the second app is broken.

Some of these are easier to fix than others. The servlet and filter
problems are easy to fix as they have direct access to the
ServletContext and can simply pass it through to Lifecycle (abstracted
as a map of course)

The timer and async method issues are a bit harder. They will need to
store a reference to the application scope that they are meant to be run
in, same with the jbpm integration.

I do not know if it will be possible to get full spring support in multi
war apps, but I don't really know enough about spring to be able to say
one way or another.

As far as I can tell these are the only major problems with multi war
apps, if these are resolved it should work fine.

Stuart
_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Pete Muir-2]

Hi Stuart,

Sounds like you have made a lot of progress, thanks!

I think it's best to integrate these into the 2.2 release as some of  
it is quite invasive... If you put any needed patches on the JIRA  
issues, we can apply...

Best,

On 24 Apr 2009, at 00:27, Stuart Douglas wrote:

> I have done some investigating into multiple war support in seam. When
> running a seam app with multiple wars you and up with two seam apps
> running side by side, with different application contexts and
> components. The Lifecycle and ServletLifecycle classes both maintain a
> static reference to the servlet context (abstracted as a map in
> LifeCycle). This means that only one of the seam apps will have their
> application context stored in these classes. This seam app will work
> fine. The seam app that is not referenced has the following problems:
>
> - Cannot load resource bundles due to use of the wrong  
> ServletContext in
> ServletLifecycle (or wrong bundles loaded).
>
> - Timers and async methods started in the second app will be run in  
> the
> app context of the first
>
> - The wrong identity component will be created by the IdentityFilter.
>
> - The resource servlet for the second app is run the app context of  
> the
> first, and will not work
>
> - Wicket integration for the second app will not work
>
> - Spring integration will not work in the second app
>
> - jbpm integration in the second app is broken.
>
> Some of these are easier to fix than others. The servlet and filter
> problems are easy to fix as they have direct access to the
> ServletContext and can simply pass it through to Lifecycle (abstracted
> as a map of course)
>
> The timer and async method issues are a bit harder. They will need to
> store a reference to the application scope that they are meant to be  
> run
> in, same with the jbpm integration.
>
> I do not know if it will be possible to get full spring support in  
> multi
> war apps, but I don't really know enough about spring to be able to  
> say
> one way or another.
>
> As far as I can tell these are the only major problems with multi war
> apps, if these are resolved it should work fine.
>
> Stuart
> _______________________________________________
> seam-dev mailing list
> seam-dev@...
> https://lists.jboss.org/mailman/listinfo/seam-dev

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Stuart Douglas]

I have attached a patch to JBSEAM-3119 (multi-war-appname1.diff). I have
take an approach where every application is assigned a unique name in a
context param (if no name is specified the name is null). Lifecycle and
ServletLifecycle now hold the app/servlet context in a hashmap with the
application name as a key. All the methods that use these statics have
had an extra appName parameter added to them, although the existing
methods have been kept as delegates to newMethod(null), so current
single war apps that make use of the Lifecycle API will not notice any
change.

The patch updated most places that use the Lifecycle API to use use
these new methods, so the calls take place in the correct application.
There are still quite a few things still to do:

- Spring integration only works for the default application (the
application with name null). This should be easy to fix but I do not
know enough about spring so I have left it for now.

- message driven beans will only run in the context of the default
application. As the message might not have even originated from a seam
app all that we can do here is add an annotation that specifies which
application the bean should run in, and run in the default application
if it is missing.

- You currently get a warning about more that one phase listener being
installed, although this does not do anything it should be fixed.

- Create a new chapter in the docs on seams behaviour in multi war
situations.

- Write some tests.

I am prepared to do the work, but before I do any more I need a core dev
to review the patch, so if you do not agree with either the approach or
the implementation I can fix it up before I do any more work.

Stuart


On Wed, 2009-05-06 at 11:34 +0100, Pete Muir wrote:

> Hi Stuart,
>
> Sounds like you have made a lot of progress, thanks!
>
> I think it's best to integrate these into the 2.2 release as some of  
> it is quite invasive... If you put any needed patches on the JIRA  
> issues, we can apply...
>
> Best,
>
> On 24 Apr 2009, at 00:27, Stuart Douglas wrote:
>
> > I have done some investigating into multiple war support in seam. When
> > running a seam app with multiple wars you and up with two seam apps
> > running side by side, with different application contexts and
> > components. The Lifecycle and ServletLifecycle classes both maintain a
> > static reference to the servlet context (abstracted as a map in
> > LifeCycle). This means that only one of the seam apps will have their
> > application context stored in these classes. This seam app will work
> > fine. The seam app that is not referenced has the following problems:
> >
> > - Cannot load resource bundles due to use of the wrong  
> > ServletContext in
> > ServletLifecycle (or wrong bundles loaded).
> >
> > - Timers and async methods started in the second app will be run in  
> > the
> > app context of the first
> >
> > - The wrong identity component will be created by the IdentityFilter.
> >
> > - The resource servlet for the second app is run the app context of  
> > the
> > first, and will not work
> >
> > - Wicket integration for the second app will not work
> >
> > - Spring integration will not work in the second app
> >
> > - jbpm integration in the second app is broken.
> >
> > Some of these are easier to fix than others. The servlet and filter
> > problems are easy to fix as they have direct access to the
> > ServletContext and can simply pass it through to Lifecycle (abstracted
> > as a map of course)
> >
> > The timer and async method issues are a bit harder. They will need to
> > store a reference to the application scope that they are meant to be  
> > run
> > in, same with the jbpm integration.
> >
> > I do not know if it will be possible to get full spring support in  
> > multi
> > war apps, but I don't really know enough about spring to be able to  
> > say
> > one way or another.
> >
> > As far as I can tell these are the only major problems with multi war
> > apps, if these are resolved it should work fine.
> >
> > Stuart
> > _______________________________________________
> > seam-dev mailing list
> > seam-dev@...
> > https://lists.jboss.org/mailman/listinfo/seam-dev
>
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete
>

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Pete Muir-2]

Norman, do you have time to look at this?

On 6 May 2009, at 23:50, Stuart Douglas wrote:

>
> I have attached a patch to JBSEAM-3119 (multi-war-appname1.diff). I  
> have
> take an approach where every application is assigned a unique name  
> in a
> context param (if no name is specified the name is null). Lifecycle  
> and
> ServletLifecycle now hold the app/servlet context in a hashmap with  
> the
> application name as a key. All the methods that use these statics have
> had an extra appName parameter added to them, although the existing
> methods have been kept as delegates to newMethod(null), so current
> single war apps that make use of the Lifecycle API will not notice any
> change.
>
> The patch updated most places that use the Lifecycle API to use use
> these new methods, so the calls take place in the correct application.
> There are still quite a few things still to do:
>
> - Spring integration only works for the default application (the
> application with name null). This should be easy to fix but I do not
> know enough about spring so I have left it for now.
>
> - message driven beans will only run in the context of the default
> application. As the message might not have even originated from a seam
> app all that we can do here is add an annotation that specifies which
> application the bean should run in, and run in the default application
> if it is missing.
>
> - You currently get a warning about more that one phase listener being
> installed, although this does not do anything it should be fixed.
>
> - Create a new chapter in the docs on seams behaviour in multi war
> situations.
>
> - Write some tests.
>
> I am prepared to do the work, but before I do any more I need a core  
> dev
> to review the patch, so if you do not agree with either the approach  
> or
> the implementation I can fix it up before I do any more work.
>
> Stuart
>
>
> On Wed, 2009-05-06 at 11:34 +0100, Pete Muir wrote:
>> Hi Stuart,
>>
>> Sounds like you have made a lot of progress, thanks!
>>
>> I think it's best to integrate these into the 2.2 release as some of
>> it is quite invasive... If you put any needed patches on the JIRA
>> issues, we can apply...
>>
>> Best,
>>
>> On 24 Apr 2009, at 00:27, Stuart Douglas wrote:
>>
>>> I have done some investigating into multiple war support in seam.  
>>> When
>>> running a seam app with multiple wars you and up with two seam apps
>>> running side by side, with different application contexts and
>>> components. The Lifecycle and ServletLifecycle classes both  
>>> maintain a
>>> static reference to the servlet context (abstracted as a map in
>>> LifeCycle). This means that only one of the seam apps will have  
>>> their
>>> application context stored in these classes. This seam app will work
>>> fine. The seam app that is not referenced has the following  
>>> problems:
>>>
>>> - Cannot load resource bundles due to use of the wrong
>>> ServletContext in
>>> ServletLifecycle (or wrong bundles loaded).
>>>
>>> - Timers and async methods started in the second app will be run in
>>> the
>>> app context of the first
>>>
>>> - The wrong identity component will be created by the  
>>> IdentityFilter.
>>>
>>> - The resource servlet for the second app is run the app context of
>>> the
>>> first, and will not work
>>>
>>> - Wicket integration for the second app will not work
>>>
>>> - Spring integration will not work in the second app
>>>
>>> - jbpm integration in the second app is broken.
>>>
>>> Some of these are easier to fix than others. The servlet and filter
>>> problems are easy to fix as they have direct access to the
>>> ServletContext and can simply pass it through to Lifecycle  
>>> (abstracted
>>> as a map of course)
>>>
>>> The timer and async method issues are a bit harder. They will need  
>>> to
>>> store a reference to the application scope that they are meant to be
>>> run
>>> in, same with the jbpm integration.
>>>
>>> I do not know if it will be possible to get full spring support in
>>> multi
>>> war apps, but I don't really know enough about spring to be able to
>>> say
>>> one way or another.
>>>
>>> As far as I can tell these are the only major problems with multi  
>>> war
>>> apps, if these are resolved it should work fine.
>>>
>>> Stuart
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev@...
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>> --
>> Pete Muir
>> http://www.seamframework.org
>> http://in.relation.to/Bloggers/Pete
>>

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev