[2.0b3] another reason for not logging in
Reported by wernerflamme | July 22nd, 2008 @ 10:01 AM | in 2.0 Full Release
Hi,
after I chanced to get 2.0b3 running on my openSUSE Linux 11.0 x86_64, I tried the same on a 10.3 x86_64 box with a Sun Java 1.5 32bit.
java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)
Here I see the error:
Tue Jul 22 18:54:40 CEST 2008: Getting the sign in cookie.
Exception in thread "MQ_ebay" java.lang.NoClassDefFoundError
at javax.crypto.Cipher.getInstance(DashoA12275)
at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(JsseJce.java:90)
at com.sun.net.ssl.internal.ssl.RSACipher.<init>(RSACipher.java:35)
at com.sun.net.ssl.internal.ssl.RSACipher.getInstance(RSACipher.java:69)
at com.sun.net.ssl.internal.ssl.PreMasterSecret.<init>(PreMasterSecret.java:82)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:515)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:160)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:877)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1089)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1116)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1100)
at sun.net.www.protocol.https.HttpsClient.a...(HttpsClient.java:402)
at sun.net.www.protocol.https.AbstractDeleg...(AbstractDelegateHttpsURLConnection.java:170)
at sun.net.www.protocol.http.HttpURLConnect...(HttpURLConnection.java:934)
at sun.net.www.protocol.http.HttpURLConnect...(HttpURLConnection.java:1976)
at sun.net.www.protocol.https.HttpsURLConne...(HttpsURLConnectionImpl.java:287)
at com.jbidwatcher.util.http.CookieJar.handleRedirect(CookieJar.java:164)
at com.jbidwatcher.util.http.CookieJar.getAllCookiesFromPage(CookieJar.java:146)
at com.jbidwatcher.util.http.CookieJar.getAllCookiesFromPage(CookieJar.java:126)
at com.jbidwatcher.auction.server.ebay.ebayLoginManager.getSignInCookie(ebayLoginManager.java:185)
at com.jbidwatcher.auction.server.ebay.ebayLoginManager.getSignInCookie(ebayLoginManager.java:160)
at com.jbidwatcher.auction.server.ebay.ebayLoginManager.getNecessaryCookie(ebayLoginManager.java:171)
at com.jbidwatcher.auction.server.ebay.ebayServer.messageAction(ebayServer.java:381)
at com.jbidwatcher.util.queue.PlainMessageQueue.run(PlainMessageQueue.java:55)
at java.lang.Thread.run(Thread.java:595)
OK, I should not use JBW at the office ;-)
Regards,
Werner
Comments and changes to this ticket
-
Morgan Schweers July 22nd, 2008 @ 11:18 AM
- → State changed from “new” to “open”
Greetings,
That message basically is an indication that there is a necessary cryptography library missing from that version of Java. :(
Try this:
grep security.provider /usr/java/{jre version}/lib/security/java.security
That's presuming java is installed in /usr/java. If not, find where it is, and grep for the security.provider entries.
They should read roughly like (this is for 1.6.0_03):
security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.8=sun.security.smartcardio.SunPCSCBasically something's screwing up the list of JAR libraries Java is going to use, and injecting the wrong (or no) Java Security library, which is then failing when JBidwatcher tries to use the HTTPS protocol.
-- Morgan Schweers, CyberFOX!
-
wernerflamme July 23rd, 2008 @ 12:50 AM
Thanks for the help!
At home, I get:
> grep security.provider /etc/alternatives/jre_1.5.0/lib/security/java.security # security.provider.<n>=<className> # named Sun appears in the sun.security.provider package. Thus, the # security.provider.1=sun.security.provider.Sun security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider policy.provider=sun.security.provider.PolicyFile system.scope=sun.security.provider.IdentityDatabaseAt the office, the result is
grep security.provider /etc/alternatives/jre_1.5.0/lib/security/java.security # security.provider.<n>=<className> # named Sun appears in the sun.security.provider package. Thus, the # security.provider.1=sun.security.provider.Sun security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider policy.provider=sun.security.provider.PolicyFile system.scope=sun.security.provider.IdentityDatabaseHm. I think I understand the message, but not the reason... :-/
Regards, Werner
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
