[
https://issues.apache.org/jira/browse/DELTASPIKE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316215#comment-15316215
]
Romain Manni-Bucau commented on DELTASPIKE-1129:
------------------------------------------------
point is there is no guarantee such assumption will work. I really think
session is associated to the request - SE or not - by design so I think current
behavior is the good one.
> check portability of context-control
> ------------------------------------
>
> Key: DELTASPIKE-1129
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1129
> Project: DeltaSpike
> Issue Type: Task
> Components: CdiControl
> Affects Versions: 1.6.0
> Environment: owb/tomee7
> Reporter: Gerhard Petracek
> Assignee: Mark Struberg
>
> ContextControl#stopContext(RequestScoped.class) also stops the
> session-context (at least in case of the current snapshot of tomee7) which
> requires the following workaround:
> {code}
> contextControl.stopContext(RequestScoped.class);
> contextControl.startContext(RequestScoped.class);
> contextControl.startContext(SessionScoped.class);
> {code}
> however, such a workaround is not portable.
> without the workaround:
> WebBeans context with scope type annotation @SessionScoped does not exist
> within current thread
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest.testNewRequests(ContainerCtrlTckTest.java:321)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> see e.g.
> https://builds.apache.org/job/DeltaSpike_TomEE_7.0.0-M3/org.apache.deltaspike.cdictrl$deltaspike-cdictrl-openejb/166/testReport/junit/org.apache.deltaspike.cdise.tck/ContainerCtrlTckTest/testNewRequests/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
