<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
<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> lol, that sounds extremely hacky, but it might be a way around it
and work glassfish-remote and jboss-remote in a similar way?