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 <[email protected]> wrote:
>> Hi Andriy,
>> Thanks for the prompt reply.
>> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <[email protected]> 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 *
