Hi Andriy, Actually I had come to that conclusion a couple of days ago. So I have to wonder, was the test ever valid? I know that JAX-RS 2 specified that it was OK to have multiple application impls per deployment, so I figure that should work.
And if this is the issue, how come it was fine with how CXF built it before? John On Sun, Aug 7, 2016 at 2:44 PM Andriy Redko <[email protected]> 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 <[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 * > > >
