On Fri, 2013-04-26 at 16:58, Peter Firmstone wrote:
> Checked RIVER-[404], the jtreg test certs still fail.
> 
> It's been fixed in trunk, we need to remove it from the release notes 
> for 2.2.1
> 
> I don't think River-[403] or River-[417] made it into 2.2.1 either.
> 

According to 
svn log --stop-on-copy
https://svn.apache.org/repos/asf/river/jtsk/branches/2.2
RIVER-417 was fixed by dreedy in revision 1444437.

I think you're right about RIVER-403 and RIVER-404.  On RIVER-404 I sort
of feel that it's a test environment issue and certs should never have
been in svn in the first place.  I'm OK with changing the release notes.


> I think these issues were marked as completed as part of a previous 
> release process that was left unfinished.  
> 
> River-[403] really needs to be included though.
> 
> Regards,
> 
> Peter.
> 
>  *** Start test: Sat Apr 27 06:46:43 EST 2013
>     [jtreg] Test 1: TestRMI$TestClientSubjectAfterSwitchConstraints:
>     [jtreg] FAIL: Unexpected exception: java.lang.IllegalStateException: 
> no object exported via this exporter
>     [jtreg]     at 
> net.jini.jeri.BasicJeriExporter.unexport(BasicJeriExporter.java:661)
>     [jtreg]     at 
> TestRMI$TestClientSubjectAfterSwitchConstraints.run(TestRMI.java:182)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:185)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:130)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:143)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:99)
>     [jtreg]     at TestRMI.main(TestRMI.java:53)
>     [jtreg]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     [jtreg]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [jtreg]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [jtreg]     at java.lang.reflect.Method.invoke(Method.java:585)
>     [jtreg]     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     [jtreg]     at java.lang.Thread.run(Thread.java:595)
>     [jtreg]
>     [jtreg] Test 2: TestRMI$TestUnexportInServerImpl: force=true
>     [jtreg] FAIL: Unexpected exception: java.rmi.server.ExportException: 
> listen failed; nested exception is:
>     [jtreg]     net.jini.io.UnsupportedConstraintException: Problem with 
> certificates: CN=serverDSA, C=US
>     [jtreg] java.security.cert.CertificateExpiredException: NotAfter: 
> Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.export(BasicExportTable.java:84)
>     [jtreg]     at 
> net.jini.jeri.BasicJeriExporter.export(BasicJeriExporter.java:603)
>     [jtreg]     at TestRMI$TestUnexportInServerImpl.run(TestRMI.java:240)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:185)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:130)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:134)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:143)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:99)
>     [jtreg]     at TestRMI.main(TestRMI.java:53)
>     [jtreg]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     [jtreg]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [jtreg]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [jtreg]     at java.lang.reflect.Method.invoke(Method.java:585)
>     [jtreg]     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     [jtreg]     at java.lang.Thread.run(Thread.java:595)
>     [jtreg] Caused by: net.jini.io.UnsupportedConstraintException: 
> Problem with certificates: CN=serverDSA, C=US
>     [jtreg] java.security.cert.CertificateExpiredException: NotAfter: 
> Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.checkCredentials(SslServerEndpointImpl.java:726)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.listen(SslServerEndpointImpl.java:658)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.Binding$2.run(Binding.java:92)
>     [jtreg]     at java.security.AccessController.doPrivileged(Native 
> Method)
>     [jtreg]     at net.jini.security.Security$5.run(Security.java:543)
>     [jtreg]     at java.security.AccessController.doPrivileged(Native 
> Method)
>     [jtreg]     at 
> net.jini.security.Security.doPrivileged(Security.java:540)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.Binding.activate(Binding.java:89)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.getBinding(BasicExportTable.java:221)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.access$100(BasicExportTable.java:46)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable$LC.addListenEndpoint(BasicExportTable.java:247)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl.enumerateListenEndpoints(SslServerEndpointImpl.java:568)
>     [jtreg]     at 
> net.jini.jeri.ssl.HttpsServerEndpoint.enumerateListenEndpoints(HttpsServerEndpoint.java:835)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.export(BasicExportTable.java:81)
>     [jtreg]     ... 14 more
>     [jtreg] Caused by: java.security.cert.CertificateExpiredException: 
> NotAfter: Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> sun.security.x509.CertificateValidity.valid(CertificateValidity.java:256)
>     [jtreg]     at 
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:570)
>     [jtreg]     at 
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:543)
>     [jtreg]     at 
> net.jini.jeri.ssl.Utilities.checkValidity(Utilities.java:774)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.checkCredentials(SslServerEndpointImpl.java:698)
>     [jtreg]     ... 27 more
> 
> Greg Trasuk wrote:
> > Hi all:
> >
> > This build https://builds.apache.org/job/river-2.2-qa-jdk7/4/ says it
> > failed, but if you look closely at the console output, all the testing
> > passed.  There was a configuration error (mine) in the archiving results
> > post-build step. There's another build scheduled which should show a
> > complete "pass" result.  Unfortunately, as we know, the test run is
> > about 16 hours.  And we're not the only project with long test runs, so
> > there's a substantial wait time before the run gets onto an executor
> > machine (just as an aside, I'm looking into setting up a Jenkins
> > instance of my own to run test builds in the future.  Perhaps others
> > should think of doing the same thing).  In any case, given the minimal
> > changes from 2.2, I'm now comfortable going forward with a release.
> >
> > I'm currently building the 2.2.1 release candidate and am thinking of
> > calling for a vote shortly.  Should I go straight to the vote, or do
> > people want to review and independently test the 2.2 branch first?
> >
> > Not that I'm calling a vote yet, but as I'm typing, I see the release
> > candidate has finished uploading to
> > http://people.apache.org/~gtrasuk/river/, so if you want to have a look
> > at it, go ahead, and let me know if there's any issues.  I will mention
> > that if you read the RAT reports, the "qa_jtreg" report names 224 files
> > without license headers.  These are ".policy" and other configuration
> > files with little creative content.  Further, they were in the previous
> > release as approved by the Incubator, so I think we're on safe ground
> > here, although they probably should have license headers added in the
> > trunk at some point.
> >
> > Also, as a point of order, normally a vote would run for 72 hours. 
> > Given that the weekend is coming up, I'm inclined to extend that to 96
> > hours.  Opinions?
> >
> > Cheers,
> >
> > Greg Trasuk.
> >
> >
> >
> >   

Reply via email to