Hi, I pushed the changes to the repo here : https://github.com/couniojc/jerseytest-cdi I aligned the naming with what you have in the doc, I think it is clear enough for people to write their own
When the tests are run, they run sequentially and still they fail. I put everything in the same test, it is working. It may not be a multithreading issue but something’s happening with the mocks between tests. JC On Feb 4, 2015, at 3:05 PM, Gerhard Petracek <[email protected]> wrote: > hi jc, > > yes - jersey-test doesn't look that extensible... > > please compare your local changes with [1] and let us know if we can > improve the hints in our documentation. > (please don't use CdiAwareJettyTestContainer as it is. like in the > documentation the important change is marked. > -> you can copy the original implementation from jersey and add the lines > which are marked and also mentioned in the documentation.) > > since parallel test-execution can cause logical (test-)issues with > different contexts (e.g. because we have to mock the http-session), > it isn't supported anyway and therefore ApplicationMockManager doesn't need > to be thread-safe. > i'll check if the documentation covers that already. > > regards, > gerhard > > [1] http://s.apache.org/bE9 > > http://www.irian.at > > Your JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache > MyFaces, DeltaSpike and OpenWebBeans > > > > 2015-02-04 23:28 GMT+01:00 Jean-Christophe Counio < > [email protected]>: > >> Thanks Gerhard, this is really helpful ! >> The problem with JerseyTest is most of the classes are final, I will see >> with Jersey team if they can do something for CDI. >> I updated the demo project. >> >> However, it is still not working as expected. When I try to instrument >> twice in the same test class (same applicationMockManager), the second test >> fails because the mock isn’t properly instrumented. If I run only one test >> in the class, they pass. >> I was wondering if it was because ApplicationMockManager isn’t thread safe >> (stores mock in a Map) ? >> >> Thanks >> >> JC >> >> On Feb 4, 2015, at 11:38 AM, Gerhard Petracek <[email protected]> >> wrote: >> >>> fyi: >>> we added some hints at [1]. >>> that way it works, however, everybody is very welcome to improve it. >>> (a proper integration of jersey-test and cdi would be better for sure...) >>> >>> regards, >>> gerhard >>> >>> [1] >>> >> http://deltaspike.apache.org/documentation/test-control.html#_using_jersey_test_with_test_control >>> >>> >>> >>> http://www.irian.at >>> >>> Your JavaEE powerhouse - >>> JavaEE Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache >>> MyFaces, DeltaSpike and OpenWebBeans >>> >>> >>> >>> 2015-02-04 12:26 GMT+01:00 Gerhard Petracek <[email protected] >>> : >>> >>>> short addition: >>>> >>>> if you can't (or don't like to) register a custom >> ServletRequestListener, >>>> you can create a custom TestContainerFactory (for jersey) to create a >>>> custom TestContainer for wrapping the default handler - e.g. via: >>>> >>>> HandlerWrapper cdiHandlerWrapper = new CdiHandlerWrapper(); >>>> cdiHandlerWrapper.setHandler(this.server.getHandler()); >>>> this.server.setHandler(cdiHandlerWrapper); >>>> >>>> (after creating the server-instance via JettyHttpContainerFactory) >>>> >>>> >>>> CdiHandlerWrapper can look like: >>>> >>>> public class CdiHandlerWrapper extends HandlerWrapper >>>> { >>>> @Override >>>> public void handle(String target, Request baseRequest, >>>> HttpServletRequest request, HttpServletResponse response) throws >>>> IOException, ServletException >>>> { >>>> CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer(); >>>> >>>> try >>>> { >>>> >>>> cdiContainer.getContextControl().startContext(RequestScoped.class); >>>> super.handle(target, baseRequest, request, response); >>>> } >>>> finally >>>> { >>>> >>>> cdiContainer.getContextControl().stopContext(RequestScoped.class); >>>> } >>>> } >>>> } >>>> >>>> with that all your tests work. >>>> >>>> regards, >>>> gerhard >>>> >>>> http://www.irian.at >>>> >>>> Your JavaEE powerhouse - >>>> JavaEE Consulting, Development and >>>> Courses in English and German >>>> >>>> Professional Support for Apache >>>> MyFaces, DeltaSpike and OpenWebBeans >>>> >>>> >>>> >>>> 2015-02-04 10:03 GMT+01:00 Gerhard Petracek <[email protected] >>> : >>>> >>>>> hi jc, >>>>> >>>>> no - that wasn't the point. >>>>> >>>>> #1 CdiTestRunner does the injection, scope-handling,... in the test and >>>>> therefore in the test-thread -> you can't remove it >>>>> #2 CdiTestRunner can't start scopes in any >other thread< (in your case >>>>> jetty has to trigger weld to do it) >>>>> #3 SimpleMockManager needs to be @RequestScoped, but jetty/weld needs >> to >>>>> do the scope-handling for the 2nd thread (like in a normal app) >>>>> >>>>> if you change e.g. PingResource to @RequestScoped even >>>>> PingResourceSimpleTest fails for the same reason. >>>>> >>>>> -> CdiTestRunner is fine, SimpleMockManager is fine and the call to >> #getMock >>>>> is fine as well. >>>>> however, in your setup jetty isn't integrated properly (with weld). >>>>> see any setup of jetty and weld or a manual integration (e.g. used at >>>>> [1]). >>>>> >>>>> regards, >>>>> gerhard >>>>> >>>>> [1] http://s.apache.org/Qja >>>>> >>>>> http://www.irian.at >>>>> >>>>> Your JavaEE powerhouse - >>>>> JavaEE Consulting, Development and >>>>> Courses in English and German >>>>> >>>>> Professional Support for Apache >>>>> MyFaces, DeltaSpike and OpenWebBeans >>>>> >>>>> >>>>> >>>>> 2015-02-04 4:13 GMT+01:00 Jean-Christophe Counio < >>>>> [email protected]>: >>>>> >>>>>> >>>>>> So after further testing, it looks like the issue is the >>>>>> SimpleMockManager is @RequestScoped. The instance is shared properly >> by the >>>>>> container between the test and jersey but the call to getMock is >> proxied >>>>>> and fails since the context isn’t active. Would it fix the problem if >> the >>>>>> MockManager scope was Application in this case ? >>>>>> >>>>>> JC >>>>>> >>>>>> On Feb 3, 2015, at 4:00 PM, Jean-Christophe Counio < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Thanks, yes that makes sense. If I comment the @RunWith (going to >> pure >>>>>> JerseyTest), the dependency injection doesn’t happen at all, so I was >>>>>> thinking Jersey recognize the test container in some way, but I can >> see now >>>>>> there are 2 different BeanManangers in application and tests. >>>>>>> Any idea how to solve that issue ? Doing the same thing in Spring is >> 2 >>>>>> lines of code so I hope there’s way to do the same with CDI. >>>>>>> >>>>>>> JC >>>>>>> >>>>>>> >>>>>>> On Feb 3, 2015, at 3:13 PM, Gerhard Petracek < >>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> hi jc, >>>>>>>> >>>>>>>> it doesn't work because jetty uses an own thread to answer the >>>>>> request and >>>>>>>> therefore the cdi-container needs to be integrated properly >>>>>>>> (the request-context needs to be active for every request answered >> by >>>>>>>> jetty). >>>>>>>> >>>>>>>> just fyi: >>>>>>>> CdiTestRunner just manages the current (test-)thread. >>>>>>>> >>>>>>>> regards, >>>>>>>> gerhard >>>>>>>> >>>>>>>> http://www.irian.at >>>>>>>> >>>>>>>> Your JavaEE powerhouse - >>>>>>>> JavaEE Consulting, Development and >>>>>>>> Courses in English and German >>>>>>>> >>>>>>>> Professional Support for Apache >>>>>>>> MyFaces, DeltaSpike and OpenWebBeans >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-02-03 19:54 GMT+01:00 Gerhard Petracek < >>>>>> [email protected]>: >>>>>>>> >>>>>>>>> hi jc, >>>>>>>>> >>>>>>>>> ok - i'll have a look at it soon. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> gerhard >>>>>>>>> >>>>>>>>> http://www.irian.at >>>>>>>>> >>>>>>>>> Your JavaEE powerhouse - >>>>>>>>> JavaEE Consulting, Development and >>>>>>>>> Courses in English and German >>>>>>>>> >>>>>>>>> Professional Support for Apache >>>>>>>>> MyFaces, DeltaSpike and OpenWebBeans >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-02-03 19:27 GMT+01:00 Jean-Christophe Counio < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Here’s the link : >>>>>>>>>> https://github.com/couniojc/jerseytest-cdi >>>>>>>>>> >>>>>>>>>> If you set >>>>>>>>>> "deltaspike.testcontrol.mock-support.allow_mocked_beans=false”, >> you >>>>>> can run >>>>>>>>>> PingResourceSimpleTest (no mocks in this one) >>>>>>>>>> As soon as you set it to true, it throws the exception. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> JC >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Feb 3, 2015, at 12:29 AM, Gerhard Petracek < >>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> hi jc, >>>>>>>>>>> >>>>>>>>>>> please provide a link to a demo which illustrates the issue. >>>>>>>>>>> >>>>>>>>>>> regards, >>>>>>>>>>> gerhard >>>>>>>>>>> >>>>>>>>>>> http://www.irian.at >>>>>>>>>>> >>>>>>>>>>> Your JavaEE powerhouse - >>>>>>>>>>> JavaEE Consulting, Development and >>>>>>>>>>> Courses in English and German >>>>>>>>>>> >>>>>>>>>>> Professional Support for Apache >>>>>>>>>>> MyFaces, DeltaSpike and OpenWebBeans >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-02-03 2:18 GMT+01:00 Jean-Christophe Counio < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Anyone successfully integrated JerseyTest with mocks using >>>>>> deltaspike ? >>>>>>>>>>>> When I activate >>>>>>>>>>>> deltaspike.testcontrol.mock-support.allow_mocked_beans=true, I >>>>>> have the >>>>>>>>>>>> following error : >>>>>>>>>>>> >>>>>>>>>>>> org.jboss.weld.context.ContextNotActiveException: WELD-001303: >> No >>>>>>>>>> active >>>>>>>>>>>> contexts for scope type javax.enterprise.context.RequestScoped >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:687) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:79) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.proxies.DynamicMockManager$1777947725$Proxy$_$$_WeldClientProxy.getMock(Unknown >>>>>>>>>>>> Source) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.apache.deltaspike.testcontrol.impl.mock.MockAwareInjectionTargetWrapper.produce(MockAwareInjectionTargetWrapper.java:59) >>>>>>>>>>>> at >>>>>> org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>> org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>> >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) >>>>>>>>>>>> at >>>>>>>>>>>> >>>>>> >> com.test.simplerest.PingResource$Proxy$_$$_WeldClientProxy.ping(Unknown >>>>>>>>>>>> Source) >>>>>>>>>>>> >>>>>>>>>>>> The test is like this : >>>>>>>>>>>> @RunWith(CdiTestRunner.class) >>>>>>>>>>>> public class PingResourceTest extends JerseyTest { >>>>>>>>>>>> >>>>>>>>>>>> @Inject >>>>>>>>>>>> ApplicationMockManager applicationMockManager; >>>>>>>>>>>> >>>>>>>>>>>> MyInj injMock = EasyMock.createMock(MockType.NICE, MyInj.class); >>>>>>>>>>>> >>>>>>>>>>>> @Override >>>>>>>>>>>> protected Application configure() { >>>>>>>>>>>> return new MyApp(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> @Test >>>>>>>>>>>> public void testPing() { >>>>>>>>>>>> applicationMockManager.addMock(injMock); //no behavior set >>>>>> so it >>>>>>>>>>>> should return null >>>>>>>>>>>> String resp = target("/ping").request().get(String.class); >>>>>>>>>>>> Assert.assertEquals("Ping", “null", resp); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> I tried to play with @TestControl but there’s no changes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> JC >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >>
