Hi,

After putting initialization of beans in a static method, I was able to run the 
tests in different tests cases and . As you mention in the documentation, it 
seems there are optimizations/caching at CDI level that prevents to modify mock 
behavior once it is injected.
Anyway I updated my test cases and examples in github.

However we cannot use DeltaSpike with EasyMock if you are mocking an interface, 
there was a ticket opened on it :
https://issues.apache.org/jira/browse/DELTASPIKE-707

I added a test to my repo to demonstrate this :
https://github.com/couniojc/jerseytest-cdi/blob/master/src/test/java/com/test/simplerest/PingResourceInjectionInterfaceTest.java

This is due to the fact that the ‘addMock’ is calling the superClass of the 
mocked object, which in the case of mock frameworks (mockito, easymock) is a 
proxy object, so the superclass is like java.lang.reflect.Proxy
I’m not sure why the ticket was closed since it can be solved easily (e.g., 
just add an overloading addMock() entry with one more parameter that is the 
interface - I’m happy to provide a patch for this -), even if there’s a 
workaround using @Typed it is quite ugly, especially if you have several mocks.

Thanks

JC

On Feb 8, 2015, at 2:55 PM, Gerhard Petracek <[email protected]> wrote:

> hi jc,
> 
> just by adding a web.xml file (in WEB-INF), mvn clean package works here
> (jdk 1.7.x)
> 
> 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-06 21:55 GMT+01:00 Jean-Christophe Counio <
> [email protected]>:
> 
>> 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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Reply via email to