cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: CDI testing module
Date Sun, 07 Aug 2016 22:56:36 GMT
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 <johndament@apache.org> 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 <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