Hi Andriy, That explains quite a few things then. I basically rewrote the test from scratch, got rid of the original errors, but now just get 404's.
I may actually have a fix for you. I'll let you know this evening. John On Sun, Aug 7, 2016 at 4:15 PM Andriy Redko <[email protected]> wrote: > 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 <[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 * > > > > >
