On 27/04/2013 11:26 AM, Greg Trasuk wrote:
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.
The certs have been there since the early days of Jini (see the creation
date), however there is code in trunk that generates the certificates
now, so this could be added as an ant target. That's the reason the
bouncy castle library was added.
They're not ordinary certs though, they simulate a CA.
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.
