[JBoss JIRA] Commented: (JBAS-2861) HttpSession sharing between WAR modules
by Ajay Gupta (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2861?page=comments#action_12349388 ]
Ajay Gupta commented on JBAS-2861:
----------------------------------
I would like to know the plans for delivering this change in terms of time. Could someone post that information here?
> HttpSession sharing between WAR modules
> ---------------------------------------
>
> Key: JBAS-2861
> URL: http://jira.jboss.com/jira/browse/JBAS-2861
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Clustering
> Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.2.0.CR1
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
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
19 years, 7 months
[JBoss JIRA] Created: (JBMESSAGING-702) Dead Lock condition on MessageCallbackHandler when failover is being executed
by Clebert Suconic (JIRA)
Dead Lock condition on MessageCallbackHandler when failover is being executed
-----------------------------------------------------------------------------
Key: JBMESSAGING-702
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-702
Project: JBoss Messaging
Issue Type: Bug
Reporter: Clebert Suconic
Assigned To: Clebert Suconic
If a failover happens when an auto ACK, is returned from MessageCallbackHandler (look at the thread dump) a dead lock might happen:
LocalThreadConsumer-1" prio=1 tid=0x8b9cf568 nid=0x228e in Object.wait() [0x8a66f000..0x8a66feb0]
at java.lang.Object.wait(Native Method)
- waiting on <0x91652838> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:474)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(WriterPreferenceReadWriteLock.java:240)
- locked <0x91652838> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at org.jboss.jms.client.container.ValveAspect.invoke(ValveAspect.java:107)
at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68)
at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.acknowledgeDelivery(ClientSessionDelegate.java)
at org.jboss.jms.client.container.SessionAspect.ackDelivery(SessionAspect.java:453)
at org.jboss.jms.client.container.SessionAspect.handlePostDeliver(SessionAspect.java:283)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect7.invoke(SessionAspect7.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68)
at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.postDeliver(ClientSessionDelegate.java)
at org.jboss.jms.client.remoting.MessageCallbackHandler.receive(MessageCallbackHandler.java:419)
- locked <0x91652338> (a java.lang.Object)
at org.jboss.jms.client.container.ReceiverAspect.handleReceive(ReceiverAspect.java:63)
at org.jboss.aop.advice.org.jboss.jms.client.container.ReceiverAspect25.invoke(ReceiverAspect25.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.receive(ClientConsumerDelegate.java)
at org.jboss.jms.client.JBossMessageConsumer.receive(JBossMessageConsumer.java:86)
at org.jboss.test.messaging.jms.clustering.ValveTest$LocalThreadConsumer.run(ValveTest.java:94)
"Thread-6" daemon prio=1 tid=0x08183840 nid=0x22d2 waiting for monitor entry [0x8aefc000..0x8aefd030]
at org.jboss.jms.client.remoting.MessageCallbackHandler.copyState(MessageCallbackHandler.java:500)
- waiting to lock <0x91652338> (a java.lang.Object)
at org.jboss.jms.client.container.HAAspect.handleFailoverOnConsumer(HAAspect.java:605)
at org.jboss.jms.client.container.HAAspect.performClientSideFailover(HAAspect.java:451)
at org.jboss.jms.client.container.HAAspect.handleConnectionFailure(HAAspect.java:337)
at org.jboss.jms.client.container.ValveAspect.handleConnectionFailure(ValveAspect.java:202)
at org.jboss.jms.client.container.ValveAspect$ConnectionFailureListener.handleConnectionException(ValveAspect.java:241)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:83)
at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:139)
--
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
19 years, 7 months
[JBoss JIRA] Created: (JBPM-778) form generation improvements
by Tom Baeyens (JIRA)
form generation improvements
----------------------------
Key: JBPM-778
URL: http://jira.jboss.com/jira/browse/JBPM-778
Project: JBoss jBPM
Issue Type: Feature Request
Components: Graphical Process Designer
Reporter: Tom Baeyens
Assigned To: Koen Aers
Fix For: jBPM 3.2 alpha 3
Here are some updates for the form generation:
1) Column reordering and renaming
* The first column should be named 'Label' and this should be the currently last column with name 'Mapped name'
* The second column should be named 'Variable name' and this should be the currently first column named 'Name'
The rest of the columns should follow after those.
2) A comment inputfield checkbox should be added. This should result in a textarea input field that corresponds to generating a comment associated with the token and taskInstance.
3) A comments display checkbox should be added. This checkbox indicates wether this taskform should display all the comments that have been made before on this token.
4) For each transition button that will be generated, the user should be able to see the transition name, change the label and make it unavailble (through a checkbox that is checked by default)
--
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
19 years, 7 months
[JBoss JIRA] Closed: (JBPM-583) add jms support for the messaging service
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-583?page=all ]
Tom Baeyens closed JBPM-583.
----------------------------
Fix Version/s: (was: jBPM 3.1.4)
Resolution: Done
i'm not going to backport the enterprise beans to 3.1 branch since this is too hard. mainly because the messages and the timers were merged into jobs in the 3.2 branch. the 3.2 enterprise code is bulid on the unified jobs and a different kind of command pattern. i don't see an easy way to port that yet.
instead we'll focus on getting 3.2 released asap.
> add jms support for the messaging service
> -----------------------------------------
>
> Key: JBPM-583
> URL: http://jira.jboss.com/jira/browse/JBPM-583
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Reporter: Tom Baeyens
> Assigned To: Jim Rigsbee
> Priority: Critical
> Fix For: jBPM 3.2 alpha 3
>
>
> postponed. work is in progress on HEAD. but as long as it is not stable there, it is not ported to 3.1 branch.
--
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
19 years, 7 months
