dev@glassfish.java.net

Re: deployment error/thread death

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Thu, 19 Apr 2007 14:46:51 -0700

Tim Quinn wrote:

>> Hi, Jan.
>>
>> Really great detective work on this. I probably should have followed
>> this more closely given that the serialization logic I added was
>> involved.
>>
>> In your research into this, did you see any place that the
>> serialization code could have protected better against something like
>> this?
>

One additional comment: You may be wondering why the serialization
logic during redeployment picked up the MessageDigest from the
cryptographic provider that was registered by jruby, when the jruby-based
webapp had already been undeployed.

The reason is that jruby inserts its crypto provider at position 2,
thereby preempting the default crypto provider for MessageDigest
algorithms (named "sun.security.provider.Sun") that ship with Sun's JRE.

According to the runtime's lib/security/java.security file, this provider is
registered in 2nd position (i.e., takes precendence over providers
registered
in higher positions):

  security.provider.1=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/sunpkcs11-solaris.cfg
  security.provider.2=sun.security.provider.Sun
  security.provider.3=sun.security.rsa.SunRsaSign
  security.provider.4=com.sun.net.ssl.internal.ssl.Provider
  security.provider.5=com.sun.crypto.provider.SunJCE
  security.provider.6=sun.security.jgss.SunProvider
  security.provider.7=com.sun.security.sasl.Provider

jruby really should have used java.security.Security.addProvider(),
which registers the specified provider "at the next available
position", instead of using java.security.Security.insertProviderAt()
with a position of "2". Then, in order to make sure their provider's
instance of MessageDigest was used, they could have used the version
of MessageDigest.getInstance() that takes a provider name (in addition
to the algorithm name).

Had they done this, the serialization logic of the AppDescriptor during
redeployment would have picked up the MessageDigest from
"sun.security.provider.Sun", and we would not have seen any ThreadDeath
errors.

Still, as I mentioned in my earlier message, jruby really should unregister
their provider during undeployment.


Jan