[[SPAM]] - Re: [seam-dev] Multiple WAR in EAR - Email found in subject
Pete Muir
pmuir at redhat.com
Thu May 7 06:57:00 EDT 2009
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 at lists.jboss.org
>>> 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
More information about the seam-dev
mailing list