cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Failure building latest trunk
Date Thu, 06 Jan 2011 20:49:43 GMT
Hudson is still reporting 1 test failure for JAXRSSimpleSecurityTest. I have
just run this test on Windows XP :

C:\Work\ApacheCXF\trunk space\systests\jaxrs>

mvn test -Dtest=JAXRSSimpleSecurityTest

-------------------------------------------------------
Running org.apache.cxf.systest.jaxrs.security.JAXRSSimpleSecurityTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.063 sec
Results :
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0


I've restarted the build on Windows, lets see. If it fails then I'll update
JAXRSSimpleSecurityTest to start the test server in-process and proceed from
there

Cheers, Sergey


On Wed, Jan 5, 2011 at 2:53 PM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> This is a new JAAS test that is failing on Windows now, the Windows build
> would be green if I did not add it :-). I'll look at at asap. Hope it's a
> test issue only...
>
> cheers, Sergey
>
> On Tue, Jan 4, 2011 at 9:59 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
>>
>> Applied the patch, but there still seems to be 5 test failures in jax-rs
>> system tests.    Getting closer though.   :-)
>>
>> https://hudson.apache.org/hudson/view/A-F/view/CXF/job/CXF-trunk-
>> windows/6/testReport/<https://hudson.apache.org/hudson/view/A-F/view/CXF/job/CXF-trunk-%0Awindows/6/testReport/>
>>
>>
>> Dan
>>
>>
>> On Sunday 19 December 2010 6:06:56 pm Jim Talbut wrote:
>> >   Dan,
>> >
>> > The attached patch makes the error go away, though I can't guarantee
>> > it's still a valid test of whatever the test was supposed to test :)
>> >
>> > Jim
>> >
>> > On 17/12/2010 20:08, Jim Talbut wrote:
>> > >  Dan,
>> > >
>> > > This particular fault isn't caused by a space in the build path
>> > > ("C:\Work\cxf").
>> > >
>> > > Jim
>> > >
>> > > On 17/12/2010 14:46, Daniel Kulp wrote:
>> > >> I actually  did start adding a Windows job to Hudson, but there are
>>  a
>> > >> bunch of test failues with it:
>> > >>
>> > >>
>> https://hudson.apache.org/hudson/view/A-F/view/CXF/job/CXF-trunk-windows
>> > >> /lastBuild/testReport/
>> > >>
>> > >>
>> > >> The job was setup with putting the checkout location (and the .m2
>> > >> repo) into a directory with spaces (to test that scenario since, for
>> > >> some reason, windows people like spaces in dirs) so some of the
>> > >> tests may be failing for that reason.    I just haven't had time to
>> > >> really
>> > >> look into any of them, especially since I don't even have a windows
>> > >> machine.
>> > >>
>> > >> At some point, I'd like to also get some hudson builds on Solaris
>> > >> and also on Linux using the IBM JDK.   Right now, a bunch of
>> > >> tests fail with the 1.6 IBM JDK as well.
>> > >>
>> > >> If anyone is looking for some places to start contributing, there's
>> > >> a couple good ones.   :-)
>> > >>
>> > >> Dan
>> > >>
>> > >> On Friday 17 December 2010 5:14:29 am Jim Talbut wrote:
>> > >>>    Hi,
>> > >>>
>> > >>> On revision 1050333 building on Windows Vista 64bit, java version
>> > >>> 1.6.0_21, Maven 2.2.1, I hit the following error:
>> > >>>
>> > >>> 17-Dec-2010 09:09:05
>> > >>> org.apache.cxf.tools.validator.internal.WSDLRefValidator
>> > >>> collectValidationPointsForBindings
>> > >>> SEVERE: {http://child/}Binding <http://child/%7DBinding>
is not
>> correct, please check that the
>> > >>> correct namespace is being used
>> > >>>
>> > >>> WSDLToJava Error: Thrown by JAXB: A class/interface with the same
>> name
>> > >>> "org.apache.cxf.testcase.cxf3105.LoginResponse" is already in use.
>> > >>> Use a
>> > >>> class customization or the -autoNameResolution option to resolve
>> this
>> > >>> conflict.
>> > >>>
>> > >>> Tests run: 63, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
>> 21.963
>> > >>> sec<<<  FAILURE!
>> > >>> testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) 
Time
>> > >>> elapsed: 0.078 sec<<<  FAILURE!
>> > >>>
>> > >>> java.lang.AssertionError:
>> > >>>           at org.junit.Assert.fail(Assert.java:91)
>> > >>>           at org.junit.Assert.assertTrue(Assert.java:43)
>> > >>>           at org.junit.Assert.assertTrue(Assert.java:54)
>> > >>>           at
>> > >>>
>> > >>>
>> org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCXF3105(CodeGenBug
>> > >>> Test
>> > >>>
>> > >>> .java:1148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> > >>> Method)
>> > >>> at
>> > >>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
>> > >>> va:3
>> > >>>
>> > >>> 9) at
>> > >>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
>> > >>> rImp
>> > >>>
>> > >>> l.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
>> > >>>
>> > >>>
>> > >>>
>> > >>> Looking at the wsdl I wonder if this is caused by a case
>> insensitivity
>> > >>> issue on Windows?
>> > >>>
>> > >>> Jim
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>

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