On Linux, that wss4j.RoundTripTest and the SequenceTest in systests seem 
to fail occasionally and randomly.   I haven't had a chance to try and 
figure out why.  Usually, just re-running mvn install seems to work fine 
for me.   I'd be OK with putting an @Ignore on it (with a note saying it 
randomly fails) for now.

Dan


On Saturday 06 October 2007, Glen Mazza wrote:
> Am Freitag, den 05.10.2007, 20:31 -0400 schrieb Daniel Kulp:
> > > I'm not sure why we need to have the "name" attribute added to the
> > > wsdl:input and wsdl:output of these operations.  Since you're just
> > > restating their default values[1] anyway, it seems distracting to
> > > be including them here.  Apparently only the wsdl:faults need an
> > > explicit name.
> >
> > Probably right.   I just took a bunch of wsdl's in the testutils,
> > copied them, and changed them from using relative imports to using
> > catalogs. Other than the imports, I left the rest alone.    Feel
> > free to fix them since you have the Karma.  :-)
>
> I'm trying to...BTW, if I do a complete checkout, and type "mvn
> install" in the trunk directory, I should *not* see any test failures,
> correct? I'm getting this error:
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.cxf.ws.security.wss4j.RoundTripTest
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 10.433
> sec <<< FAILURE!
> testUsernameToken(org.apache.cxf.ws.security.wss4j.RoundTripTest) 
> Time elapsed: 3.499 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<test> but was:<null>
>         at org.junit.Assert.fail(Assert.java:71)
>         at org.junit.Assert.failNotEquals(Assert.java:451)
>         at org.junit.Assert.assertEquals(Assert.java:99)
>         at org.junit.Assert.assertEquals(Assert.java:116)
>         at
> org.apache.cxf.ws.security.wss4j.RoundTripTest.testUsernameToken(Round
>TripTest.java:110)
>
> I don't know how normal it is for test failures to occur from
> trunk--or whether we should commit things if we are getting such
> failures locally.
>
> Thanks,
> Glen
>
> > Thanks!



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to