[arquillian-issues] [JBoss JIRA] Commented: (ARQ-337) Create a Context/Scope activation/deactivation abstraction for CDI

[Aslak Knutsen (JIRA)]

    [ https://jira.jboss.org/browse/ARQ-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564987#comment-12564987 ] 

Aslak Knutsen commented on ARQ-337:
-----------------------------------

<aslak> pbakker, we will create a common arq 'ContextController' you can inject, since all of this is non standard between cdi impls and containers.. with a common api exposed by Arq your tests can be portable between impls
 pbakker, if you want to help prototype that your more then welcome.. :)
<pbakker> what else should the contextcontroller be able to do?
 because request and session are part of the test already
<aslak> pbakker, session/req shouldn't be auto in the test case(maybe with some annotations but..). it just works by chance currently
 by chance between embedded vs remote container that is
<pbakker> hehe ok i wasn't aware of that
<aslak> it works basically because the remote test execution currently use HTTP to execute, so when in cdi, you will have req and session there.. but when you move to e.g. ejb protocol for execution then you only have request
 the scopes should be controlled by the test, not 'randoms' in the environment.. ;)
<pbakker> ok than a ContextController makes a lot of sense
 so i guess step one would be to get it working consistently over types of containers
 step 2 to look at other cdi impl
<aslak> pbakker, yea, start with weld-ee weld-se and jboss remote
 probably the easies let CDI manage the ContextController as a bean, and only use CDi to inject it as well
<pbakker> i agree
<aslak> possible we could do something like @Scopes(Request, Session) @Test as a 'around invoke style, but that is a abstraction over the ContextController that would be step 3/4 or so
<pbakker> yeah that would be good
 i guess we just have to write different implementations for each container
 because different way of executing the tests
 if there is a real http request you probably want to run the test in that same request, not in a simulated one
<aslak> i think one for weld based containers should be ok, since weld works the same in all, but need different impl between openweb beans / reisin etc
 resin
<pbakker> but in a remote test it now uses a http request to execute the test right, and not in an embedded container
 (lots of assumptions here, haven't really looked at the code yet...)
<aslak> hmm.. not quite sure. you might be able to reuse the one there, depends a bit on how strict the container is.. weld allow you to stop and start new requests within a reques etc.. as pete commented, don't do that if you want it to work.. hehe
 pbakker, correct
<pbakker> lol, that sounds extremely hacky, but it might be a way around it
 and work glassfish-remote and jboss-remote in a similar way?
<aslak> yes

> Create a Context/Scope activation/deactivation abstraction for CDI 
> -------------------------------------------------------------------
>
>                 Key: ARQ-337
>                 URL: https://jira.jboss.org/browse/ARQ-337
>             Project: Arquillian
>          Issue Type: Feature Request
>            Reporter: Aslak Knutsen
>
> We need to have a stable and reliable api exposed by arquillian over the different container types and CDI impls to control the activation and deactivation of different scopes

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira