[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2209) Improve ways to transfer state information from a nested conversation to the parent conversation context
by Wolfgang Schwendt (JIRA)
Improve ways to transfer state information from a nested conversation to the parent conversation context
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-2209
URL: http://jira.jboss.com/jira/browse/JBSEAM-2209
Project: JBoss Seam
Issue Type: Bug
Components: Core
Reporter: Wolfgang Schwendt
Priority: Critical
When a nested conversation ends, it is difficult to transfer an ending result back to the parent conversation. The following approach is currently not viable with Seam: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. So once the nested conversation scope gets destroyed at the end of the nested conversation, the saved wrappers for the component from the parent conversation get destroyed as well.
Scenario:
Suppose that we have a component AA in the conversation context with a field reference named 'bb' to an another component Q. At some point of time this reference is moved by the ManagedEntityIdentityInterceptor to a conversation-scoped context variable with the name "AA.bb". Then we start a nested conversation. While the nested conversation is in progress, we can call a method of component AA and successfully access the field bb because at the time of the method invocation, the ManagedEntityIdentityInterceptor can retrieve the saved wrapper for field bb from the parent conversation context and put the contained reference into the component AA.
But then we call a method of component AA which changes the field bb. At the end of this method invocation, the ManagedEntityIdentityInterceptor moves the new value of reference field bb to a wrapper saved in the nested (!) conversation context. Afterwards we end the nested conversation and the parent conversation resumes again. When we then call a method of component AA again, the ManagedEntityIdentityInterceptor retrieves the wrapper for field bb from the conversation context. But this wrapper contains the old value for field bb, not the new value. Note that the wrapper with the new value for field bb got destroyed already at the time when the nested conversation context was destroyed.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118936&start=30
Feature request regarding nested conversations
Tue Sep 18, 2007 00:28 AM
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121852
Nested Conversations (tricky interceptor)
Mon Oct 22, 2007 11:03 AM
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2338) allow seam-gen to manage multiple projects
by Dan Allen (JIRA)
allow seam-gen to manage multiple projects
------------------------------------------
Key: JBSEAM-2338
URL: http://jira.jboss.com/jira/browse/JBSEAM-2338
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 2.0.0.GA
Reporter: Dan Allen
Assigned To: Dan Allen
Fix For: 2.0.1.GA
Currently seam-gen only has the ability to manage one project at a time. This limitation is due to the fact that it sources build.properties from the seam-gen directory to read settings about the managed project. I propose that we make the name of the settings file dynamic so that it is possible for seam-gen to select it based on the name of a property supplied to the command line.
Example:
./seam -Dbuild=projecta explode
./seam explode
The first command would source build-projecta.properties. The second command would fall back to the existing behavior and source build.properties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2082) JMS Topic subscriptions never released
by Scott McNab (JIRA)
JMS Topic subscriptions never released
--------------------------------------
Key: JBSEAM-2082
URL: http://jira.jboss.com/jira/browse/JBSEAM-2082
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 2.0.0.CR2, 2.0.0.CR1, 1.2.1.GA, 1.2.0.GA, 2.0.0.GA
Environment: JBossAS 4.2.0.GA, All platforms.
Reporter: Scott McNab
Assigned To: Shane Bryzak
In the current Seam remoting implementation, there is no mechanism to clean up and release JMS topic subscriptions for clients that may have subscribed to a JMS topic, but who do not explicitly unsubscribe() (e.g. due to a coding error or if the client simply disappears)
Unless a web-client specifically calls Seam.Remoting.unsubscribe(), the RemoteSubscriber object is never released, and the corresponding TopicSession and TopicSubscriber resources will be held open indefinitely. This will cause the JMS provider to store an ever-growing list of undelivered topic messages, which will eventually result in an out of memory crash.
Seam Remoting needs to be able to correctly identify situations whereby a RemoteSubscriber is no longer in use, and release resources accordingly.
One possible solution might be to periodically check all subscriptions in the SubscriptionRegistry and release any which have not had a recent poll request beyond a certain time limit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1619) support for Glassfish in seam-gen
by Dan Allen (JIRA)
support for Glassfish in seam-gen
---------------------------------
Key: JBSEAM-1619
URL: http://jira.jboss.com/jira/browse/JBSEAM-1619
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 2.0.0.BETA1
Environment: Glassfish V2
Reporter: Dan Allen
I believe that adding support for Glassfish will help promote the adoption of Seam. In my mind, Tomcat is not nearly as important because it is not a Java EE-compliant environment and seam-gen is all about creating compliant projects.
Supporting Glassfish is actually quite straightforward. There are a couple of assumptions that are made by seam-gen that render it incompatible with a generic Java EE-compliant application server. Here is what needs to change:
1. The java:/ prefix on the data source causes problems with other servers. This can be easily brought into compliance by adding <use-java-context>false</use-java-context> to the *-ds.xml files and removing the java:/ prefix from the persistence-*.xml files in the seam-gen/resources/META-INF directory
2. Glassfish does not use Hibernate EntityManager as the default JPA provider, and therefore does not have any of its jar files. Of course, we could just make everyone copy necessary hibernate jar files into the glassfish installation directory, but that just isn't going to go over well. I think a better approach is to modify the build.xml file to copy the following three libraries if the property hibernate.needed=true is set:
hibernate-all.jar
thirdparty-all.jar
jboss-archive-browsing.jar (not currently in the seam distribution, but stuck inside the jboss-embedded-all.jar file)
3. Make the hibernate.transaction.manager_lookup_class parameterized, perhaps asking during setup
4. Removing the .war suffix on the exploded archive directory (so that Glassfish can deploy the directory using asadmin deploydir)
That's it! Then you can have Glassfish working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months