I have submitted a patch that should fix the issues in JIRA, but there are still quite a few that have not been reported yet, probably because there are not very many multi-war seam apps in production. Most of these issues can be fixed piecemeal, and the ones that can't are probably obscure enough that people will not run into them (e.g. selecting which app context you want to use when injecting seam components into spring beans). A few of the cases where the wrong application context can be used: - async methods may use the wrong app context - all users of ContextualHttpRequest may run in the wrong app context (remoting and resteasy are the main ones) - Message Driven beans will always run in an arbitary application context (this can't really be fixed, but I don't really like the idea that the context that they run in is undefined, depending on the order that the apps are deployed) - Spring integration (not really fixable) - There may be some problems with the Jbpm SeamUserCodeInterceptor If there are no problems with the last patch I will do up a patch for the ContextualHttpRequest and async method issues later this week. The async method patch will probably be a bit messy, because it will involve passing the application context around inside all the dispatchers. Stuart -----Original Message----- From: Dan Allen [mailto:dan.j.allen@gmail.com] Sent: Sat 13/06/2009 10:21 AM To: Pete Muir Cc: Stuart Douglas; seam-dev(a)lists.jboss.org Subject: Re: [seam-dev] Seam 2.2.0.CR1 release On Fri, Jun 12, 2009 at 6:10 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Stuart, I agree, this is long overdue. > > I took a look at your patch, there seems to be a number of problems > (System.out.println, changing of SPIs with no changes made to the JBoss5 int > project at least), and it is essentially a workaround for a mistake in the > underlying architecture, as a result I would prefer to defer this to 299, > which does correctly scope all components to the relevant JEE module. Hmm, I was thinking this was going to get into 2.2 as well...or at least 2.2.1. I know that solving problems like this one is much easier and cleaner w/ 299 given that we have a chance to start over, but I worry that there are enough folks that really need this capability w/o refactoring the rest of their code. Even with 299 in place, if there is any Seam 2 code, users are still going to have the same issue (assuming that this problem is baggage that Seam 2 brings with it). Stuart, would you be willing to work through this piecemeal? That will make success much more likely. And this really would be huge for Seam 2 if we could get it fixed. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.