[[SPAM]] - Re: [seam-dev] Multiple WAR in EAR - Email found in subject

[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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/seam-dev
> 
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete
>