[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-3119: ------------------------------ Fix Version/s: 2.1.0.BETA2 (was: 2.1.0.GA) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-3119: ------------------------------ Fix Version/s: 2.1.1.CR1 (was: The future) Assignee: Marek Novotny (was: Jay Balunas) Marek, could you look at this, and the issue it incorporates, and write up a section for the docs? Ping me or Jay if you need more info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Shane Bryzak updated JBSEAM-3119: --------------------------------- Fix Version/s: 2.1.2.CR1 (was: 2.1.1.CR2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Erik James Freed commented on JBSEAM-3119: ------------------------------------------ I tried 2.1.1GA and deploying multiple WAR files still doesn't work after trying what seem like the obvious things. Did I miss the example of how to do this that has appeared in this release or is this not yet fixed? If it hasn't been fixed, I vote to have it scheduled at a higher priority -- it seems to be a significant flaw in a basic requirement for J2EE conformance. For what it is worth it made seam non functional for my current consulting client as it did for a previous client as well. I suspect there are many J2EE multiple WAR use cases out there since that level of modularity for applications is one of the nice features. To the proposed premiere J2EE application layer not be able to do this at all is unfortunate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Martin Gainty commented on JBSEAM-3119: --------------------------------------- port conflicts with arjuna transaction manager apparently jboss-jta.properties entries of <property name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort" value="11000"/> <!-- The maximum number of ports to try starting from the value specified by the property com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort. Any non-numeric or value less than 1 will defautl to 1. --> <property name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdMaxPorts" value="1000"/> are totally ignored..and produce this message in server.log com.arjuna.ats.arjuna.exceptions.FatalError: [com.arjuna.ats.arjuna.recovery.TransactionStatusManager_9] - Could not get unique port. at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.start(TransactionStatusManager.java:185) using arjuna's build.xml Im trying to compile arjuna now but running around in circles trying to get HP classbuilder task running <taskdef name="classpath-builder" classname="com.hp.mw.buildsystem.ant.ClasspathBuilder" classpathref="com.arjuna.buildsystem.classpath"/> there seems to be a hard dependency to JDK 1.4 or JDK 1.5 which needs to be updated to 1.6 asap thanks, martin- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Gonzalez Adrian commented on JBSEAM-3119: ----------------------------------------- I agree completely with Frank Cornelis, we have 60Mb application for 1 ear with 2 war modules, and 90 Mb for 3 war modules. We're waiting very eagerly for this feature here (but... I wouldn't know how to provide a patch for it ;((( ) ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas commented on JBSEAM-3119: ---------------------------------------- Oops, I meant to attach the patch to JBSEAM-2523. Sorry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas updated JBSEAM-3119: ----------------------------------- Attachment: admin-dvdstore.diff This is the app I used to figure out where the problem is. It is a patch against the dvd store example that adds an admin war. The admin war uses a different authenticator that only allows the manager to log in and view a list of users. I am not sure if this will be useful to anyone. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir commented on JBSEAM-3119: ----------------------------------- Shane/Stuart, Lifecycle should *not* have a dependence on the servlet context. The second parameter should be abstracted. Also, I'm not sure that altering this API in a micro release is acceptable - you should keep the old method and delegate to this one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas updated JBSEAM-3119: ----------------------------------- Attachment: multi-war-wip.diff I have attached a work in progress patch that attempts to resolve all the problems that stem from the use of the Lifecycle.application static. It involves some reasonably invasive changes, as every bit of code that calls these lifecycle methods now needs a reference to the application that they belong to. There is still testing and some cleaning up to do, but I though I would post it here to get some feedback first to see if people agree with the approach I have taken. Due to the API changes this is probably not going to be suitable for the 2.1 branch. I did not do anything with the spring integration, it is still broken with respect to multiple war seam apps, I am not sure if this will even be possible to integrate multi war seam projects with spring properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir commented on JBSEAM-3119: ----------------------------------- Shane, can you make sure to back out the previous changes... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas commented on JBSEAM-3119: ---------------------------------------- The majority or multi war related issues are because 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 there 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. To fix these issues I propose we introduce an application name context param in web.xml, and change LifeCycle and ServletLifecycle to hold a Map<application name, application/servlet context>. If the context param is not included then the application name is simply null. Lifecycle methods such as Lifecycle.beginCall will become Lifecycle.beginCall(String), and we can still keep the current api by changing the current beginCall method to delegate to beginCall(null), so single war apps will not notice any change. Inside the framework we need to store a reference to the appropriate application name when doing anything that accesses lifecycle methods. If a user includes two wars in an ear with the same application name (or no application name) an exception is thrown. For spring integration we can do things like <seam:instance name="someComponent" application="mySecondWarName" /> Does anyone have any comments/objections/reasons why this won't work? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas commented on JBSEAM-3119: ---------------------------------------- It should work fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas updated JBSEAM-3119: ----------------------------------- Attachment: multi-war-appname1.diff I have created a patch based on the application name approach I mentioned earlier (multi-war-appname1.diff). Each war in a multi-war seam app should specify a unique application name in the context param 'org.jboss.seam.applicationName'. Lifecycle.application now stores a static HashMap<String,Map<String,Object>> ServletLifecycle.servletContext is now a HashMap<String,ServletContext> All methods that used these statics now take the application name parameter. The original methods have been kept as delegates to newMethod(null) . This means single war apps will not be affected by the api change. The application name is placed into the Application Context under the key 'org.jboss.seam.applicationName'. The lifecycle class contains a convenience method Lifecycle.getApplicationName() that retrieves it. I would appreciate it if a core seam dev could have a look at it and give me some feedback. I have been thinking about this for a while and I think that the application name approach is the only one that makes sense. Without this there is no way for external users of seam components (such as spring) to specify which application they are actually interested in. Still to do: Message driven beans do not work properly, they will always run in the context of the application with a null name. I think the best we can do where is add an annotation to specify the application context that we want the bean to be invoked in. In practice I don't think this is a big issue. Spring integration does not work properly in a multi-war app. It is only possible to inject components from the application with a null name. This should be fairly easy to fix by adding an applicationName parameter to the seam:instance namespace handler, but I do not really know enough about spring. Documentation - I am prepared to do this if the patch is accepted Writing Tests Lots of testing - This is a fairly invasive patch, and it would be good if people with multi war projects could take it for a spin and see if there are any problems Creating an example application -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Frank Cornelis commented on JBSEAM-3119: ---------------------------------------- context-path for application name definitely would make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Norman Richards reassigned JBSEAM-3119: --------------------------------------- Assignee: Norman Richards (was: Shane Bryzak) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir commented on JBSEAM-3119: ----------------------------------- Trust me, no hidden agenda, you can put your tin-foil hat away ;-) Just everyone is very busy with EE6 at the moment :-( BTW You can *certainly* run >1 Seam war in JBoss AS at any one time! This issue is about >1 war in *one ear*. So, no panic! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-3119: ------------------------------ Fix Version/s: 3.0.0.BETA1 (was: 2.2.1.CR1) I'm deferring this to Seam 3/JSR-299 as that correctly scopes beans to the relevant JEE module. Anything in the Seam2 core is essentially a workaround for the architecture's design not supporting this. Due to the timeframe associated with 2.2.0, we can't make such a risky change without extensive community testing. Smaller/less intrusive patches I will make sure get in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Antoine Sabot-Durand commented on JBSEAM-3119: ---------------------------------------------- Pete, I'm joining Jan in his request. One of our apps is stuck in Seam 2.0 (with which it was possible to make the multiple War in Ear work with a few trcks) and we have to re-engineer one of our apps in march to upgrade it in Seam 2.1. I'm starting a very big project for a bank where I planned to use Seam in a JEE environment, but if I don't have any visibility on the resolution of this issue (BTW it's not a "feature request" as it is stated in this Jira ticket but a real Bug) I'll have to make another recommendation. I won't panic but I'm very puzzled by the low priority you gave to this issue. You guys at JBoss are doing a great job for making JEE standard better they use to be, so I don't understand why this big incompatibility of Seam with JEE is considered to be minor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Antoine Sabot-Durand commented on JBSEAM-3119: ---------------------------------------------- Thanks Pete for these detail. Concerning the multiple war in ear with Seam 2.0, there were only one issue concerning properties files and messages component. The first message component used in a war was taking precedence on all the others. With this known we were able to gather all the properties file in one place and declare the messages component in EJB package. Everythng else was fine for us. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Dan Allen commented on JBSEAM-3119: ----------------------------------- I have added an FAQ about this problem that references this issue report. http://seamframework.org/Documentation/CanIHaveMultipleSeamWARModulesInAS... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Reind D commented on JBSEAM-3119: --------------------------------- Thanks Stuart. This bug is one year old (with related bugs even older), and it has one of the highest vote counts, yet the fix is targeted for a release that we can expect in 2010? Pretty disappointing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-3119: ------------------------------ Fix Version/s: 2.2.1.CR1 (was: 3.0.0.BETA1) Assignee: Pete Muir (was: Norman Richards) Thanks Stuart, looks good, I will apply tonight. Frank, Stuart doesn't work for JBoss :-) He's just helping us all out. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-3119: ------------------------------ Comment: was deleted -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir commented on JBSEAM-3119: ----------------------------------- I've applied Stuarts patch - please try this out and report any problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Norman Richards commented on JBSEAM-3119: ----------------------------------------- I'm having some problems with the changes to ResourceLoader, specifically the calls to ServletLifecycle.getCurrentServletContext(). This call is returning null when the Pages components tries to load WEB-INF/pages.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Stuart Douglas commented on JBSEAM-3119: ---------------------------------------- It looks like a line has gone missing at some point. The line context.setAttribute(SERVLET_CONTEXT_KEY, context); is missine from the commit but is in the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Norman Richards commented on JBSEAM-3119: ----------------------------------------- Thanks. This fix seems to make things work, though I haven't tested too thoroughly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Pete Muir closed JBSEAM-3119. ----------------------------- Fix Version/s: 2.2.0.GA (was: 2.2.1.CR1) Resolution: Done All sub issues, closed, so closing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Reind D commented on JBSEAM-3119: --------------------------------- I tried out Stuart's earlier patch which looked to resolve JBSEAM-3849 (I could have been mistaken), but that I *can* confirm that that bug is still occurring in the latest Seam_2_2 branch. Looking at the new diff, I don't see anything that would resolve it directly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-3119?page=com.atlassian.jira.pl... ] Susanne Jarl commented on JBSEAM-3119: -------------------------------------- This is working fine in Seam 2.2.0.GA except for one thing - the seam graphicImageStore. It is only working in the first loaded war and in the second war I get the following exception when trying to view an image using the s:graphicImage tag: javax.servlet.ServletException: java.lang.IllegalArgumentException: value of context variable is not an instance of the component bound to the context variable: org.jboss.seam.ui.graphicImage.graphicImageStore. If you are using hot deploy, you may have attempted to hot deploy a session or application-scoped component definition while using an old instance in the session. at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:74) at org.jboss.seam.ui.graphicImage.GraphicImageResource.getResource(GraphicImageResource.java:46) at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) ... If I only deploy the second war, so there is only one war in the ear, I get no exception and the images shows up. So I guess this must be a bug. This worked fine in Seam 2.1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira