Ok, I raised a PR to add parent scanning. I'm not sure if it makes sense to do it a bit more cautiously, but to me it makes sense that app path is inherited (and hence raised a ticket on JAX-RS spec).
John On Sun, Aug 7, 2016 at 4:26 PM John D. Ament <[email protected]> wrote: > 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 * >> >> >> >> >>
