Arquillian
  1. Arquillian
  2. ARQ-337

Create a Context/Scope activation/deactivation abstraction for CDI

    Details

    • Type: Feature Request Feature Request
    • Status: Open 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

        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: