cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: CDI testing module
Date Sun, 07 Aug 2016 20:26:22 GMT
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 <drreta@gmail.com> 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 <drreta@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 <
> johndament@apache.org>
> >> wrote:
>
> >> >> Hi Andriy,
>
> >> >> Thanks for the prompt reply.
>
> >> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drreta@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 *
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message