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 <drr...@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 <johndam...@apache.org>
>> wrote:
>> >> Hi Andriy,
>> >> Thanks for the prompt reply.
>> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drr...@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 *
