You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2016/08/03 00:35:51 UTC
CDI testing module
Hi,
Long time user, first time contributor to CXF. Though I'm no stranger to
the ASF by any long shot.
I was looking at putting in some fixes for issues I reported. First one
was a non-problem. However, when trying to figure out how to add tests to
ensure that empty application class applications work fine (CXF-6986), I
realized that the current testing structure in systest wouldn't work.
https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java
It looks like this test code is doing a few odd things. First, its
assuming that Weld is the only testable container. The ASF actually hosts
the other CDI impl, OpenWebBeans. Second, its always doing classpath
scanning. This strategy would mean I need a separate module to test my
feature, which is a little odd.
I was wondering if there was any interest in converting this to an
arquillian based test? The test code could be platform inspecific,
allowing tests to be created for both CDI impls, improving compatibility.
WDYT?
in case it helps understand the problem, my proposed changes can be seen
here: https://github.com/apache/cxf/pull/150
- John
Re: CDI testing module
Posted by Andriy Redko <dr...@gmail.com>.
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.
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.
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
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
Re: CDI testing module
Posted by Andriy Redko <dr...@gmail.com>.
Hey John,
Sorry for delayed response. I haven't seen this kind of exception, I will
try to take a look and help you out.
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 <jo...@apache.org> wrote:
>> Hi Andriy,
>> Thanks for the prompt reply.
>> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
Re: CDI testing module
Posted by "John D. Ament" <jo...@gmail.com>.
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 <jo...@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 <dr...@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 <dr...@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 <dr...@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 *
>>
>>
>>
>>
>>
Re: CDI testing module
Posted by "John D. Ament" <jo...@apache.org>.
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 <dr...@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 <dr...@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 <dr...@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 *
>
>
>
>
>
Re: CDI testing module
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@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 <jo...@apache.org>
>> wrote:
>> >> Hi Andriy,
>> >> Thanks for the prompt reply.
>> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
Re: CDI testing module
Posted by "John D. Ament" <jo...@apache.org>.
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 <dr...@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 <jo...@apache.org>
> wrote:
>
> >> Hi Andriy,
>
> >> Thanks for the prompt reply.
>
> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
>
>
>
Re: CDI testing module
Posted by Andriy Redko <dr...@gmail.com>.
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 <jo...@apache.org> wrote:
>> Hi Andriy,
>> Thanks for the prompt reply.
>> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
Re: CDI testing module
Posted by "John D. Ament" <jo...@apache.org>.
So I'm running into an interesting issue. I'm not sure if I found a bug,
or if I've gone way far into the deep end here.
I'm getting this exception: https://paste.apache.org/8WEp
You can see my changes here:
https://github.com/johnament/cxf/tree/arquillian
I suspect what's happening is that CXF is being initialized twice. Now
that I've enabled CDI, the static initialization and the CDI initialization
are both being triggered. Not sure if you have any ideas.
John
On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <jo...@apache.org> wrote:
> Hi Andriy,
>
> Thanks for the prompt reply.
>
> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
>>
>
Re: CDI testing module
Posted by "John D. Ament" <jo...@apache.org>.
Hi Andriy,
Thanks for the prompt reply.
On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <dr...@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 *
>