cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andriy Redko <drr...@gmail.com>
Subject Re: CDI testing module
Date Sun, 07 Aug 2016 20:15:05 GMT
Hi John,

That's pretty interesting, the issue caused by the fact that in your test 
the Application class instances are Weld proxies, while in orginal test case
they aren't. As such, the @ApplicationPath annotations happen to be lost for Weld 
proxies, which causes address conflicts for JAXRSServerFactoryBeans. I will
try to figure out what are the differences ...

Thanks!

Best Regards,
    Andriy Redko


JDA> Hi Andriy,

JDA> Actually I had come to that conclusion a couple of days ago.  So I have to
JDA> wonder, was the test ever valid? I know that JAX-RS 2 specified that it was
JDA> OK to have multiple application impls per deployment, so I figure that
JDA> should work.

JDA> And if this is the issue, how come it was fine with how CXF built it before?

JDA> John

JDA> On Sun, Aug 7, 2016 at 2:44 PM Andriy Redko <drreta@gmail.com> wrote:

>> Hey John,

>> The exception in question comes from the fact that your deployment
>> descriptor
>> contains 2 applications, BookStoreApplication and
>> BookStoreCustomApplication:

>>         return ShrinkWrap.create(WebArchive.class)
>>                 .addClasses(BookStoreApplication.class,
>> BookStoreCustomApplication.class,
>>                         BookStoreService.class, BookStore.class)

>> It is surely possible to have more than one JAX-RS application but in CDI
>> context they
>> both try to bind to root path "/" (@ApplicationPath is taken into account
>> but later). In this
>> case both  JAXRSServerFactoryBean instances try to registered themselved
>> under "/" and exception
>> is being raised :(

>> Thanks.

>> Best Regards,
>>     Andriy Redko

>> JDA> So I'm running into an interesting issue.  I'm not sure if I found a
>> bug,
>> JDA> or if I've gone way far into the deep end here.

>> JDA> I'm getting this exception: https://paste.apache.org/8WEp

>> JDA> You can see my changes here:
>> JDA> https://github.com/johnament/cxf/tree/arquillian

>> JDA> I suspect what's happening is that CXF is being initialized twice.
>> Now
>> JDA> that I've enabled CDI, the static initialization and the CDI
>> initialization
>> JDA> are both being triggered.  Not sure if you have any ideas.

>> JDA> John

>> JDA> On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <johndament@apache.org>
>> wrote:

>> >> Hi Andriy,

>> >> Thanks for the prompt reply.

>> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drreta@gmail.com> wrote:

>> >>> Hi John,

>> >>> Thanks a lot for your fixes, much appreciated and of great value for
>> CDI
>> >>> users. To answer a couple of your questions / concerns.



>> >>> *JDA> First, its assuming that Weld is the only testable container.
>> *This
>> >>> is very true. The reason for that is Weld was the only one implementing
>> >>> CDI 1.2 at the moment the CXF/CDI integration was done. OpenWebBeans
>> were
>> >>> behind but there is no obstacles or objects to have a test suite(s)
>> >>> against
>> >>> it as well, it's been a while OpenWebBeans implements 1.2.


>> >> I just realized that the CDI integration has been around for all of the
>> >> 3.x line.  I only found out about it in the last couple of weeks.

>> >> With that said, I'd like to try to put together a test suite.  I'll send
>> >> it over when ready.  If you guys like it, its yours.

>> >> I created https://issues.apache.org/jira/browse/CXF-6988





>> >>> *JDA> Second, its always doing classpath scanning.   *This is also
>> true,
>> >>> as there was an intention to test exactly the way it is
>> >>> going to be used. The suite also tests against Tomcat and Jetty,
>> embedded
>> >>> and
>> >>> WAR based deployments. With that being said, if Arquillian allows to
>> >>> simplify
>> >>> the test structure while opening more opportuties to test different
>> >>> scenarios
>> >>> (including the ones we already have), it would be great in my opinion.


>> >> Sounds good.  Some of the things I'd like to make sure are proved out:

>> >> - Testing both Weld and OWB
>> >> - Running different parts of the test per deployment.
>> >> - Ensuring the various tests with Jetty/Jetty Embedded/Tomcat



>> >>> Thanks.

>> >>> Best Regards,
>> >>>     Andriy Redko











>> >>> *JDA> Hi, JDA> Long time user, first time contributor to CXF.
 Though
>> I'm
>> >>> no stranger to JDA> the ASF by any long shot. JDA> I was looking
at
>> putting
>> >>> in some fixes for issues I reported.  First one JDA> was a non-problem.
>> >>> However, when trying to figure out how to add tests to JDA> ensure
that
>> >>> empty application class applications work fine (CXF-6986), I JDA>
>> realized
>> >>> that the current testing structure in systest wouldn't work. *JDA>
>> >>>
>> https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java
>> >>> <
>> https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java
>> >













>> >>> *JDA> It looks like this test code is doing a few odd things.  First,
>> its
>> >>> JDA> assuming that Weld is the only testable container.  The ASF
>> actually
>> >>> hosts JDA> the other CDI impl, OpenWebBeans.  Second, its always
doing
>> >>> classpath JDA> scanning.  This strategy would mean I need a separate
>> module
>> >>> to test my JDA> feature, which is a little odd. JDA> I was wondering
if
>> >>> there was any interest in converting this to an JDA> arquillian based
>> >>> test?  The test code could be platform inspecific, JDA> allowing
tests
>> to
>> >>> be created for both CDI impls, improving compatibility. JDA> WDYT?
>> JDA> in
>> >>> case it helps understand the problem, my proposed changes can be seen
>> JDA>
>> >>> here: *https://github.com/apache/cxf/pull/150



>> >>> *JDA> - John *





Mime
View raw message