uninitialized constant Krypt::ASN1::BOOLEAN #1119

atambo opened this Issue Oct 11, 2013 · 20 comments


None yet
8 participants

atambo commented Oct 11, 2013

I get the following exception when trying to boot a rails app with jruby-openssl 0.9.2 on jruby 1.7.4 or jruby 1.7.5 using warbler. But if I use jruby-openssl 0.8.8 things are fine.


Maybe this is somewhat related to: #1071


bruceadams commented Oct 11, 2013

My attempts to trigger this kind of problem in a simple Rails app running under Tomcat have failed. That is: nothing breaks. I'm using JRuby 1.7.5, Rails 3.2.14, Warbler 1.3.8 and Tomcat 7.0.42. I have a stupid "welcome" page in the Rails app that does uses Net:HTTP with use_ssl=true to get a remote web page. It works just fine. This has to mean the jruby_openssl code and underlying Java code embedded in JRuby's stdlib is being found on the Java and/or JRuby classpath.

I know that @atambo is using WebSphere and, of course, a real (that is: complex) application; not sure which differences matter.


bruceadams commented Oct 12, 2013

WebSphere is at least part of the problem. A development build of our application fails on WebSphere but runs fine on Tomcat 7.


headius commented Oct 21, 2013

Hmmm. Seems like krypt may not be booting, or something? Can you confirm that the other namespaces leading up to this constant are there?


atambo commented Oct 22, 2013

@jkutner, do you think this commit could be related to this?:



jkutner commented Oct 22, 2013

Unfortunately, I don't think it's related. That commit only affects the runnable feature in warbler, and it failed pretty hard on 1.7.5. Something like LoadError: no such file to load -- bcpkix-jdk15on-147


headius commented Oct 22, 2013

Can you try jruby-openssl-0.9.3 and see if it's any better, preferably with jruby-1.7.6? Those versions fix the multiple loads, which could be related to this issue.


headius commented Oct 22, 2013

It appears that this constant is supposed to be defined in krypt-core's native ext, in org.jruby.ext.krypt.asn1.RubyAsn1. Perhaps the extension is not loading before the use of this constant (or not loading at all?)

Have a look at -Xdebug.loadService=true log and see if you can see kryptcore.jar getting loaded.


atambo commented Dec 6, 2013

@headius, I turned on debug.loadService and I see that kryptcore.jar is found:

[err] 2013-12-06T14:13:34.018-05:00: LoadService: found: wsjar:file:/opt/wlp/!/META-INF/jruby.home/lib/ruby/shared/kryptcore.jar

This happens before the constant Krypt::ASN1::BOOLEAN is used within template.rb. So somehow the constant that is supposed to be defined here:


is not defined.

I'm not really sure why this would be.

I can workaround this issue by copying the krypt*.jars from the jruby-stdlib jar and place them directly into the WEB-INF/lib directory.

So why does the constant get defined when the krypt jars are not nested inside of the stdlib jar?


mkristian commented Dec 7, 2013

On Fri, Dec 6, 2013 at 8:01 PM, Alex Tambellini notifications@github.comwrote:


found but does it get loaded ? I would say no. the wsjar protocol looks
something unexpected to me.

there was another email-thread with websphere where workaround was to place
all the vendored jars from jruby-stdlib into the WEB-INF/lib and then it


atambo commented Dec 7, 2013

@mkristian, so you are thinking that maybe the jruby LoadService doesn't handle the wsjar protocol? I'm not very familiar with how this stuff works but it looks like lots of places in the jruby LoadService know about "jar" and "file" protocols but and have no knowledge of the "wsjar" protocol:


I wonder if the right fix is to just make the LoadService think "wsjar" is the same as "jar" or is there a better way?


mkristian commented Dec 7, 2013

On Sat, Dec 7, 2013 at 1:56 AM, Alex Tambellini notifications@github.comwrote:

"wsjar" protocol:

according to the first statement there (

The wsjar protocol is used to access classes and resources
stored in Java EE archives (WARs, EARs, EJB JARs,etc.) and is
similar to the jar protocol.

and matches exactly the behaviour which these people with the websphere
problem see. so the fix would be to treat wsjar like jar protocol. maybe
just turn the 'equals' into a 'contains' ;).

I think that solve the problem, since the protocol handler will open the
stream . . . .


mkristian commented Dec 9, 2013

@atambo could you provide the whole debug log around that LoadService - it is not clear where exactly this "found ... " entry was created. and the restriction to the jar protocol is definitely the problem and that restriction is not really clear because whatever the classloader returns as URL it can be loaded since the respective protocol handlers are registered.


atambo commented Dec 9, 2013

@mkristian, here is the load service debug log for booting as rails app using websphere:



mkristian commented Dec 9, 2013

thanx - I will have a look . . .


mkristian commented Dec 11, 2013

well, I decided to get myself websphere but do not find time after that big
download to proceed.

jruby finds the jar twice and adds it at least one time to the
jruby-classloader BUT still it can not load that class. hope to find more
time soon for this one ;)

I don't know if this is related but we are having this same error in Tomcat.

INFO jruby.rack - An exception happened during JRuby-Rack startup
uninitialized constant Krypt::ASN1::BOOLEAN
--- System
jruby 1.7.10 (1.9.3p392) 2014-01-09 c4ecd6b on Java HotSpot(TM) 64-Bit Server VM 1.7.0_51-b13 [linux-amd64]
Time: 2014-01-28 16:40:13 +0000
Server: Apache Tomcat/7.0.50
jruby.home: file:/usr/local/apache-tomcat/webapps/ROOT/WEB-INF/lib/gems-gems-jruby-jars-1.7.10-lib-jruby-stdlib-complete-1.7.10.jar!/META-INF/jruby.home

--- Context Init Parameters:
jruby.max.runtimes = 8
jruby.min.runtimes = 8
jruby.rack.logging = log4j
public.root = /
rails.env = production

--- Backtrace
NameError: uninitialized constant Krypt::ASN1::BOOLEAN

JRuby-openssl 0.9.4, Rails 3.2.16, jruby-rack
But the odd thing is that it is hit and miss. Sometimes it happens and sometimes it doesn't. I sat there this morning stopping and starting tomcat over and over and eventually it failed. But then even after it fails sometimes it won't again. This does not happen at all with JRuby 1.7.3, jruby-openssl 0.8.7, jruby-rack, rails 3.2.13. I seriously doubt its rails since it isn't getting that far. Don't know exactly if its the combination of the other 3 or just one of them all I know is when we roll back to the combination of lower versions there isn't a problem. This first started with JRUBY 1.7.8, I tried 1.7.10 and it seemed to make it better but then eventually failed.

I was able to duplicate this, Java 1.7.0_51 jruby 1.7.10, here is my gemfile:

source 'https://rubygems.org'

gem 'rails', '3.2.16'

gem 'activerecord-jdbcmysql-adapter', '1.3.3'
gem 'jruby-rack', ''
gem 'jruby-jars', '1.7.10'
gem 'jruby-openssl', '0.9.4', :require => false

gem 'warbler', '1.4.0'

group :assets do
gem 'sass-rails', '> 3.2.3'
gem 'coffee-rails', '
> 3.2.1'

gem 'therubyrhino'

gem 'uglifier', '>= 1.0.3'

I created a testapp in rails, and did not add anything to it. I created an executable war file with

RAILS_ENV=production bundle exec warble executable war

and executed the war file with

java -jar testapp.war

Sometimes it starts, sometimes it does not and I get the error above. So this eliminates tomcat and our actual web app's source code.

malletto commented Feb 3, 2014

Want to update this since i'm still researching. Moving the krypt jars into the lib directory is not a fix. It eventually will fail. I ran it 20 times without a problem and then it eventually failed with:

undefined method `_mod_included_callback' for Krypt::ASN1::Template:Module

Sometimes it also echos

WARNING: while creating new bindings for class org.jruby.ext.krypt.asn1.RubyTemplate$RubyAsn1Template, found an existing binding; you may want to run a clean build.

Which would make sense, its trying to load the krypt jar twice, but I would think if it gets that error then it shouldn't also get the undefined method error. I also have a war file that I have placed out there that is downloadable. Just run it with java -jar testapp.war


malletto commented Mar 3, 2014

A late update on this. We thought we figured out what was going on. We removed
gem 'jruby-openssl', '0.9.4', :require => false
from the gemfile. Since it is included in jruby jars it should already be there. This "fixed" the test app and we thought everything was fine. But just last week we hit failures again. Extremely rare, maybe about 4% of the time when starting tomcat over and over again it will eventually fail.


kares commented Feb 27, 2015

has been fixed for a while now (by @mkristian) ... Warbler also has support to handle .jar copying to WEB-INF/lib in a way that is easier with class-loaders.

kares closed this Feb 27, 2015

enebo added this to the Non-Release milestone Apr 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment