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 Fri, 05 Aug 2016 02:55:28 GMT
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 <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