[JBoss JIRA] (WFLY-9449) SingletonPartitionTestCase fails intermittently (on CI)
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9449:
------------------------------------
Summary: SingletonPartitionTestCase fails intermittently (on CI)
Key: WFLY-9449
URL: https://issues.jboss.org/browse/WFLY-9449
Project: WildFly
Issue Type: Bug
Components: Clustering, Test Suite
Affects Versions: 11.0.0.CR1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Stuart noticed the test fails in CI intermittently. This is because it is designed to rely on MERGE3 which does not operate quickly enough.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB
by Juan Martin Runge (JIRA)
[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ]
Juan Martin Runge closed WFLY-9443.
-----------------------------------
Release Notes Text: Packaging error.
Resolution: Rejected
> Random deploy error with @Startup @Singleton EJB
> ------------------------------------------------
>
> Key: WFLY-9443
> URL: https://issues.jboss.org/browse/WFLY-9443
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, EJB
> Affects Versions: 11.0.0.CR1
> Environment: Wildfly 11.0CR1 + Vaadin 8.1.4
> Tested on Debian 9.1 and Windows 10
> Reporter: Juan Martin Runge
> Assignee: Martin Kouba
> Labels: regression
> Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz
>
>
> Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean.
> Attached sample app, project, log with error and log with success.
> If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange.
> Also, this didnt happened with Wildfly 9 (same app deployed perfectly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB
by Juan Martin Runge (JIRA)
[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ]
Juan Martin Runge edited comment on WFLY-9443 at 10/17/17 8:52 AM:
-------------------------------------------------------------------
Hi Martin, you were completely right. Changing {code:java}<type>jar</type>{code} to {code:java}<scope>provided</scope>{code} on {code:java}wftest-vaadin{code} pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kind Regards,
Juan Martin
was (Author: jmrunge):
Hi Martin, you were completely right. Changing {code:java}<type>jar</type>{code} to {code:java}<scope>provided</scope>{code} on {code:java}wftest-vaadin{code} pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
> Random deploy error with @Startup @Singleton EJB
> ------------------------------------------------
>
> Key: WFLY-9443
> URL: https://issues.jboss.org/browse/WFLY-9443
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, EJB
> Affects Versions: 11.0.0.CR1
> Environment: Wildfly 11.0CR1 + Vaadin 8.1.4
> Tested on Debian 9.1 and Windows 10
> Reporter: Juan Martin Runge
> Assignee: Martin Kouba
> Labels: regression
> Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz
>
>
> Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean.
> Attached sample app, project, log with error and log with success.
> If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange.
> Also, this didnt happened with Wildfly 9 (same app deployed perfectly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB
by Juan Martin Runge (JIRA)
[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ]
Juan Martin Runge edited comment on WFLY-9443 at 10/17/17 8:52 AM:
-------------------------------------------------------------------
Hi Martin, you were completely right. Changing {code:java}<type>jar</type>{code} to {code:java}<scope>provided</scope>{code} on {code:java}wftest-vaadin{code} pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
was (Author: jmrunge):
Hi Martin, you were completely right. Changing {code:java}<type>jar</type>{code} to {code:java}<scope>provided</>{code} on {code:java}wftest-vaadin{code} pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
> Random deploy error with @Startup @Singleton EJB
> ------------------------------------------------
>
> Key: WFLY-9443
> URL: https://issues.jboss.org/browse/WFLY-9443
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, EJB
> Affects Versions: 11.0.0.CR1
> Environment: Wildfly 11.0CR1 + Vaadin 8.1.4
> Tested on Debian 9.1 and Windows 10
> Reporter: Juan Martin Runge
> Assignee: Martin Kouba
> Labels: regression
> Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz
>
>
> Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean.
> Attached sample app, project, log with error and log with success.
> If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange.
> Also, this didnt happened with Wildfly 9 (same app deployed perfectly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB
by Juan Martin Runge (JIRA)
[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ]
Juan Martin Runge edited comment on WFLY-9443 at 10/17/17 8:52 AM:
-------------------------------------------------------------------
Hi Martin, you were completely right. Changing {code:java}<type>jar</type>{code} to {code:java}<scope>provided</>{code} on {code:java}wftest-vaadin{code} pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
was (Author: jmrunge):
Hi Martin, you were completely right. Changing ??<type>jar</type>?? to ??<scope>provided</>?? on ??wftest-vaadin?? pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
> Random deploy error with @Startup @Singleton EJB
> ------------------------------------------------
>
> Key: WFLY-9443
> URL: https://issues.jboss.org/browse/WFLY-9443
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, EJB
> Affects Versions: 11.0.0.CR1
> Environment: Wildfly 11.0CR1 + Vaadin 8.1.4
> Tested on Debian 9.1 and Windows 10
> Reporter: Juan Martin Runge
> Assignee: Martin Kouba
> Labels: regression
> Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz
>
>
> Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean.
> Attached sample app, project, log with error and log with success.
> If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange.
> Also, this didnt happened with Wildfly 9 (same app deployed perfectly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB
by Juan Martin Runge (JIRA)
[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ]
Juan Martin Runge commented on WFLY-9443:
-----------------------------------------
Hi Martin, you were completely right. Changing ??<type>jar</type>?? to ??<scope>provided</>?? on ??wftest-vaadin?? pom.xml for the ejb jar dependency did the trick. My pom was autogenerated by netbeans, I never thougth it could be wrong. 10 deployments in a row and no a single fail.
Many thanks! I think we may close this issue now...
Kina Regards,
Juan Martin
> Random deploy error with @Startup @Singleton EJB
> ------------------------------------------------
>
> Key: WFLY-9443
> URL: https://issues.jboss.org/browse/WFLY-9443
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, EJB
> Affects Versions: 11.0.0.CR1
> Environment: Wildfly 11.0CR1 + Vaadin 8.1.4
> Tested on Debian 9.1 and Windows 10
> Reporter: Juan Martin Runge
> Assignee: Martin Kouba
> Labels: regression
> Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz
>
>
> Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean.
> Attached sample app, project, log with error and log with success.
> If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange.
> Also, this didnt happened with Wildfly 9 (same app deployed perfectly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9448) Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-9448?page=com.atlassian.jira.plugin.... ]
kobogian hitis updated WFLY-9448:
---------------------------------
Description:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
After restarting, again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
NOTE: Each node runs with:
`./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` .
`jboss.node.name` and `$localIp` only changes between nodes.
was:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` .
`jboss.node.name` and `$localIp` only changes between nodes.
> Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9448
> URL: https://issues.jboss.org/browse/WFLY-9448
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Reporter: kobogian hitis
> Assignee: Paul Ferraro
>
> On our system, after some time we get this:
> javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
> And then we start getting the following:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> ...
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> continouously on most requests without being able to recover.
> After restarting, again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
> I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
> NOTE: Each node runs with:
> `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` .
> `jboss.node.name` and `$localIp` only changes between nodes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9448) Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-9448?page=com.atlassian.jira.plugin.... ]
kobogian hitis updated WFLY-9448:
---------------------------------
Description:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` .
`jboss.node.name` and `$localIp` only changes between nodes.
was:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` . `jboss.node.name` and `$localIp` only changes between nodes.
> Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9448
> URL: https://issues.jboss.org/browse/WFLY-9448
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Reporter: kobogian hitis
> Assignee: Paul Ferraro
>
> On our system, after some time we get this:
> javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
> And then we start getting the following:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> ...
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> continouously on most requests without being able to recover.
> Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
> I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
> Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` .
> `jboss.node.name` and `$localIp` only changes between nodes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1409:
-------------------------------------
Summary: Update HTTP authentication mechanism API to support re-use of response handlers
Key: ELY-1409
URL: https://issues.jboss.org/browse/ELY-1409
Project: WildFly Elytron
Issue Type: Task
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.2.0.Beta7
At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request.
Making the scopes available should allow for state to be transferred on the request scope.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months