deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remo Meier <remo.me...@adnovum.ch>
Subject Re: Jersey, OpenEJB, Deltaspike
Date Thu, 18 Aug 2016 10:50:59 GMT
yes, maybe. I basically just followed the instructions on 
https://deltaspike.apache.org/documentation/test-control.html. And the 
jersey test framework looked quite good to me. Maybe the instructions 
could be completed with alternatives. For me it is now working quite ok.

Personally it would be great to have a second full-fledged container 
next to openejb. Having all of them would be great but unrealistic I 
guess. Weld seems to be a dead end because wildfly does not run as 
embedded library (as far as I know). Glassfish might work

Regards Remo



> +1, what about simply using openejb with the built-in CXF?
> Do you need something special from Jersey?
>
> LieGrue,
> strub
>
>
>
>
>
>> On Tuesday, 16 August 2016, 15:00, Gerhard Petracek <gerhard.petracek@gmail.com>
wrote:
>>> hi remo,
>> if you would like to stick with tomee/openejb as well as with jersey, you
>> need a setup which integrates jersey with owb like jersey-weld2-se is doing
>> it with weld  (or jersey with the cdi 1.1+ api) or you need a setup which
>> integrates tomee/openejb with jersey.
>>
>> the last time i looked at jersey, only the out-of-the-box integration with
>> weld worked as expected.
>> -> if jersey still doesn't provide a better out-of-the-box integration
>> (based on the cdi 1.1+ api or with owb directly), you need to contact one
>> of the two communities (tomee or jersey) or replace one of the parts.
>>
>> regards,
>> gerhard
>>
>>
>>
>>
>> 2016-08-16 10:03 GMT+02:00 Remo Meier <remo.meier@adnovum.ch>:
>>
>>>   Hi
>>>
>>>   I attempt to get get the Jersey integration running together with
>>>   Deltaspike, OpenEJB and Test Control according to the documentation at the
>>>   bottom of the page here:
>>>
>>>   https://deltaspike.apache.org/documentation/test-control.html
>>>
>>>   Not working so far is the injection of CDI beans into JAX-RS resources.
>>>   The resulting exceptions look like like:
>>>
>>>   MultiException stack 1 of 1
>>>   org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object
>>>   available for injection at SystemInjecteeImpl(requiredTyp
>>>   e=EntityManagerFactory,parent=KatharsisMgmtFeature,qualifier
>>>
>> s={},position=-1,optional=false,self=false,unqualified=null,1475912655)
>>>       at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThir
>>>   tyResolver.java:75)
>>>       at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:945)
>>>       at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLoca
>>>   torImpl.java:979)
>>>       at org.jvnet.hk2.internal.ServiceLocatorImpl.createAndInitializ
>>>   e(ServiceLocatorImpl.java:1054)
>>>       at org.jvnet.hk2.internal.ServiceLocatorImpl.createAndInitializ
>>>   e(ServiceLocatorImpl.java:1045)
>>>       at org.glassfish.jersey.model.internal.CommonConfig.configureFe
>>>   atures(CommonConfig.java:711)
>>>       at org.glassfish.jersey.model.internal.CommonConfig.configureMe
>>>   taProviders(CommonConfig.java:648)
>>>       at org.glassfish.jersey.server.ResourceConfig.configureMetaProv
>>>   iders(ResourceConfig.java:829)
>>>       at org.glassfish.jersey.server.ApplicationHandler.initialize(Ap
>>>   plicationHandler.java:453)
>>>       at org.glassfish.jersey.server.ApplicationHandler.access$500(Ap
>>>   plicationHandler.java:184)
>>>       at org.glassfish.jersey.server.ApplicationHandler$3.call(Applic
>>>   ationHandler.java:350)
>>>       at org.glassfish.jersey.server.ApplicationHandler$3.call(Applic
>>>   ationHandler.java:347)
>>>       at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
>>>       at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
>>>       at org.glassfish.jersey.internal.Errors.processWithException(Er
>>>   rors.java:255)
>>>       at org.glassfish.jersey.server.ApplicationHandler.<init>(Applic
>>>   ationHandler.java:347)
>>>       at org.glassfish.jersey.server.ApplicationHandler.<init>(Applic
>>>   ationHandler.java:311)
>>>       at org.glassfish.jersey.jetty.JettyHttpContainer.<init>(JettyHt
>>>   tpContainer.java:474)
>>>       at org.glassfish.jersey.jetty.JettyHttpContainerProvider.create
>>>   Container(JettyHttpContainerProvider.java:60)
>>>       at org.glassfish.jersey.server.ContainerFactory.createContainer
>>>   (ContainerFactory.java:81)
>>>       at org.glassfish.jersey.jetty.JettyHttpContainerFactory.createS
>>>   erver(JettyHttpContainerFactory.java:161)
>>>       at ch.adnovum.jcan.test.deltaspike.jaxrs.internal.DeltaspikeAwa
>>>
>> reJettyTestContainer.<init>(DeltaspikeAwareJettyTestContainer.java:41)
>>>       at ch.adnovum.jcan.test.deltaspike.jaxrs.internal.DeltaspikeAwa
>>>   reJettyTestContainerFactory.create(DeltaspikeAwareJettyTes
>>>   tContainerFactory.java:16)
>>>       at org.glassfish.jersey.test.JerseyTest.createTestContainer(Jer
>>>   seyTest.java:277)
>>>       at org.glassfish.jersey.test.JerseyTest.setUp(JerseyTest.java:607)
>>>       at ch.adnovum.moap.movie.management.web.EntityAccessTest.setUp(
>>>   EntityAccessTest.java:50)
>>>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>>   ssorImpl.java:62)
>>>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>>   thodAccessorImpl.java:43)
>>>       at java.lang.reflect.Method.invoke(Method.java:483)
>>>       at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>>>   FrameworkMethod.java:50)
>>>       at org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>>>   ectiveCallable.java:12)
>>>       at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>>>   ameworkMethod.java:47)
>>>       at org.junit.internal.runners.statements.RunBefores.evaluate(
>>>   RunBefores.java:24)
>>>       at org.junit.internal.runners.statements.RunAfters.evaluate(Run
>>>   Afters.java:27)
>>>       at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>       at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>>   4ClassRunner.java:78)
>>>       at org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.
>>>   runChild(CdiTestRunner.java:177)
>>>       at org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.
>>>   runChild(CdiTestRunner.java:76)
>>>       at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>       at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>       at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>       at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>       at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>       at org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$Be
>>>   foreClassStatement.evaluate(CdiTestRunner.java:372)
>>>       at org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$Af
>>>   terClassStatement.evaluate(CdiTestRunner.java:393)
>>>       at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>       at org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.
>>>   run(CdiTestRunner.java:144)
>>>       at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.
>>>   run(JUnit4TestReference.java:86)
>>>       at org.eclipse.jdt.internal.junit.runner.TestExecution.run(
>>>   TestExecution.java:38)
>>>       at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>>   sts(RemoteTestRunner.java:459)
>>>       at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>>   sts(RemoteTestRunner.java:678)
>>>       at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
>>>   RemoteTestRunner.java:382)
>>>       at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
>>>   RemoteTestRunner.java:192)
>>>
>>>   KatharsisMgmtFeature is a regular Feature. And their is a Producer that
>>>   makes the EntityManagerFactory available with @Inject.
>>>
>>>   The application works if I manually register a
>>>   org.glassfish.hk2.utilities.binding.AbstractBinder bean as singleton to
>>>   the Application and use it to bind CDI beans to jersey/hk2 with
>>>   AbstractBinder.bind(x).to(y). But I would rather prefer for Jersey to
>>>   directly access the CDI beans instead of bridging those with the
>>>   AbstractBinder.
>>>
>>>   My dependencies for Jersey currently look like:
>>>
>>>       compile 'org.glassfish.jersey.core:jersey-client:2.23.1'
>>>       compile 'org.glassfish.jersey.core:jersey-common:2.23.1'
>>>       compile 'org.glassfish.jersey.test-framework:jersey-test-framework-
>>>   core:2.23.1'
>>>       compile 'org.glassfish.jersey.test-framework.providers:jersey-test-
>>>   framework-provider-jetty:2.23.1'
>>>       compile 'org.glassfish.jersey.containers:jersey-container-jetty-
>>>   http:2.23.1'
>>>       compile
>> 'org.glassfish.jersey.bundles.repackaged:jersey-guava:2.23.1'
>>>       compile 'org.glassfish.jersey.ext.cdi:jersey-cdi1x:2.23.1'
>>>       compile
>> 'org.glassfish.jersey.ext.cdi:jersey-cdi1x-transaction:2.23.1'
>>>       compile
>> 'org.glassfish.jersey.ext.cdi:jersey-cdi1x-servlet:2.23.1'
>>>   The last three are new jersey libraries first having become available last
>>>   year. Documentation about those is available here:
>>>   https://jersey.java.net/documentation/latest/cdi.support.html.
>>>   Potentially that api would open up the possiblity for a small deltaspike
>>>   library that does all the necessary integration work (request scoping, cdi
>>>   binding), probably independent of Jetty.
>>>
>>>   Or is there a complete example somewhere?
>>>
>>>   Regards Remo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Mime
View raw message