Arquillian
  1. Arquillian
  2. ARQ-337

Create a Context/Scope activation/deactivation abstraction for CDI

    Details

    • Type: Feature Request Feature Request
    • Status: Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Runtime Enricher SPI
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      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

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Aslak Knutsen added a comment -

            <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

            Show
            Aslak Knutsen added a comment - <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
            Hide
            Krzysztof Kowalczyk added a comment -

            I have a small use case, that could be solved by this feature.
            I would like to be able to end existing request scope and move to another in one test (same with other scopes).

            So I could write a test like:

            @Inject ScopedIncrementer inc;
             
            @Test
            public void shallReturnDifferentValueBetweenRequests(){
               int firstRequest = inc.getRequestScopedValue()
               contextController.end(RequestScope.class)
               contextController.start(RequestScope.class/*, mockData ?*/)
               int secondRequest = inc.getRequestScopedValue()
             
               assertTrue(firstRequest < secondRequest)
            }
            

            Show
            Krzysztof Kowalczyk added a comment - I have a small use case, that could be solved by this feature. I would like to be able to end existing request scope and move to another in one test (same with other scopes). So I could write a test like: @Inject ScopedIncrementer inc;   @Test public void shallReturnDifferentValueBetweenRequests(){ int firstRequest = inc.getRequestScopedValue() contextController.end(RequestScope.class) contextController.start(RequestScope.class/*, mockData ?*/) int secondRequest = inc.getRequestScopedValue()   assertTrue(firstRequest < secondRequest) }
            Show
            Bernard Labno added a comment - http://blog.it-crowd.com.pl/2012/04/mock-contexts-for-arquillian.html https://community.jboss.org/message/731060#731060

              People

              • Assignee:
                Paul Bakker
                Reporter:
                Aslak Knutsen
              • Votes:
                4 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Development