You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by A Leg <ha...@yahoo.com> on 2005/03/25 14:54:44 UTC
Re: [httpclient] about bad_record_mac; Solved
Hi
I finaly find out the problem :
I was a ClassLoader problem :
For my application I make a jar containing all classes required.
Including httpclient classes etc.
On the devt machine my custom SecureProtocolSocketFactory was loaded and
so it was working.
On the production machine it was a common-httpclient.jar in the
J2RE_LIBRARY/ext
And the classLoader was not loading the SecureProtocolSocketFactory from
my jar but from this common-httpclient.jar in the J2RE_LIBRARY/ext
I have deleted common-httpclient.jar in the J2RE_LIBRARY/ext and now it
works.
I really have difficulties to understand how classLoader works. I am
comming from C language, with .a static it was simple, with dynamic .so
it is still possible to understand. But here I really don't understand.
When I am launching the appli I do :
java -jar myjar.jar
So I don't understand why this stupid loader go get anything in
J2RE_LIBRARY/ext and use it with higher priority than elements in my jar.
I still don't beleive it. I got the same problem using java 1.5 on the
same machine. And j2sdk1.4.2_04 is exactly the same between both machines.
I dont have any common-httpclient.jar in the J2RE_LIBRARY/ext in the
devt machine.
If any body understand better than me. Please tell me it would be usefull.
One more time thank's for httpclient team. This project is realy well
written.
To figure out what was going on I have been inside the code and it is a
really nice job.
Thank's specially to Brad, Steve and Oleg.
Have nice time.
Andre
A Leg wrote:
> Hi
>
> I post a few weeks ago a bad_record_mac error.
> With Steve, Brad and Oleg help I solved it.
>
> My appli was working good until now. I have added
> ((SSLSocket)socket).setEnabledProtocols(new String[] {"SSLv3"});
> ((SSLSocket)socket).setUseClientMode(true);
>
> In my custom SecureProtocolSocketFactory
>
> I just install my appli on the production machine : just transfert the
> jar and run appli.
> And patatra similar (not same) problem (see log below). I then
> recompile on production machine : same result.
>
> My production machine run mandrake 10.1 with 2.6.8.1 kernel and
> j2sdk1.4.2_04
> Devt machine run fedora2 with 2.6.7 kernel and j2sdk1.4.2_04.
> The problem does not arrived at same level it is at the very begining
> on the good working machine the blocking point is passed with success
> even it the connection to internet is closed.
>
> Any idea welcome
>
> Andre
>
> Mar 25, 2005 7:46:23 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: I/O exception caught when processing request: Received fatal
> alert: bad_record_mac
> Mar 25, 2005 7:46:23 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: Retrying request
> Mar 25, 2005 7:46:24 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: I/O exception caught when processing request: Received fatal
> alert: bad_record_mac
> Mar 25, 2005 7:46:24 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: Retrying request
> Mar 25, 2005 7:46:25 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: I/O exception caught when processing request: Received fatal
> alert: bad_record_mac
> Mar 25, 2005 7:46:25 AM
> org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> INFO: Retrying request
> Exception in thread "main" javax.net.ssl.SSLException: Received fatal
> alert: bad_record_mac
> at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> at
> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> at
> org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:825)
>
> at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1920)
>
> at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1002)
>
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:382)
>
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
>
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:393)
>
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
>
> at org.compiere.mfg_scm.mageManager.Mages.main(Unknown Source)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [httpclient] about bad_record_mac; Solved
Posted by A Leg <ha...@yahoo.com>.
Hi Brad
Brad Wetmore wrote:
>
>> On the production machine it was a common-httpclient.jar in the
>> J2RE_LIBRARY/ext
>
>
> I assuming this points to <java-home>/lib/ext, and that we're talking
> about standard extensions.
>
>> And the classLoader was not loading the SecureProtocolSocketFactory
>> from my jar but from this common-httpclient.jar in the J2RE_LIBRARY/ext
>> I have deleted common-httpclient.jar in the J2RE_LIBRARY/ext and now
>> it works.
>>
>> I really have difficulties to understand how classLoader works. I am
>> comming from C language, with .a static it was simple, with dynamic
>> .so it is still possible to understand. But here I really don't
>> understand.
>>
>> When I am launching the appli I do :
>> java -jar myjar.jar
>>
>> So I don't understand why this stupid loader go get anything in
>> J2RE_LIBRARY/ext and use it with higher priority than elements in my
>> jar.
>
>
> The short answer is that Java searches/loads bootstrap classes
> (java.io, java.lang, etc) first, then classes found in the extensions
> directory, before loading user classes (i.e. -classpath). The
> extensions directory is kind of a "second" system classes area.
>
Thank's Brad. I understand better now. For inheritance reasons it seems
to me natural that load would be from particular to generic.
But now I will take a particular attention to ext content.
> Have a look at the classloader info for the extension mechanism.
>
> http://java.sun.com/docs/books/tutorial/ext/index.html
> http://java.sun.com/j2se/1.5.0/docs/guide/extensions/index.html
>
> or have a look at the Java 2 Platform Security book
> (Gong/Elison/Dageforde) section 4 on secure classloaders for much more
> detailed info on the actual class search/load mechanism.
>
> The classloading mechanism including the classloader hierarchy and
> delegation model is too hard to explain in a quick email.
>
> Brad
>
>
Cheers
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [httpclient] about bad_record_mac; Solved
Posted by Brad Wetmore <Br...@Sun.COM>.
> On the production machine it was a common-httpclient.jar in the
> J2RE_LIBRARY/ext
I assuming this points to <java-home>/lib/ext, and that we're talking
about standard extensions.
> And the classLoader was not loading the SecureProtocolSocketFactory from
> my jar but from this common-httpclient.jar in the J2RE_LIBRARY/ext
> I have deleted common-httpclient.jar in the J2RE_LIBRARY/ext and now it
> works.
>
> I really have difficulties to understand how classLoader works. I am
> comming from C language, with .a static it was simple, with dynamic .so
> it is still possible to understand. But here I really don't understand.
>
> When I am launching the appli I do :
> java -jar myjar.jar
>
> So I don't understand why this stupid loader go get anything in
> J2RE_LIBRARY/ext and use it with higher priority than elements in my jar.
The short answer is that Java searches/loads bootstrap classes (java.io,
java.lang, etc) first, then classes found in the extensions directory,
before loading user classes (i.e. -classpath). The extensions directory
is kind of a "second" system classes area.
Have a look at the classloader info for the extension mechanism.
http://java.sun.com/docs/books/tutorial/ext/index.html
http://java.sun.com/j2se/1.5.0/docs/guide/extensions/index.html
or have a look at the Java 2 Platform Security book
(Gong/Elison/Dageforde) section 4 on secure classloaders for much more
detailed info on the actual class search/load mechanism.
The classloading mechanism including the classloader hierarchy and
delegation model is too hard to explain in a quick email.
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org