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

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