Can run WAR on Websphere due to: NameError: uninitialized constant Krypt::ASN1::BOOLEAN

Since 1.7.4 of jRuby, I have been unable to successfully run my
application on WebSphere (8.5) (WAS is running on my Dev PC along with
WEBrick)

I installed jRuby 1.7.8 and started clean with a bundle install (I
deleted the Gem Lock file). I’m using Warbler 1.4

The WAR deploys ok to WAS but on application start, I get:

NameError: uninitialized constant Krypt::ASN1::BOOLEAN

Reading that removing the jruby-openssl reference from the Gem file
might fix this, I removed the reference, did a bundle update and
deployed a new WAR.

Now I get this error:

NameError: missing class or uppercase package name
(`org.jruby.ext.openssl.OSSLLibrary’)

Any ideas on how to work around this problem?

BTW, my application runs fine with WEBrick with and without the
jruby-openssl gem defined in the gem file.

Here are my gems:

bundler-1.3.5
rake-10.1.0
i18n-0.6.5
minitest-4.7.5
multi_json-1.8.2
atomic-1.1.14-java
thread_safe-0.1.3-java
tzinfo-0.3.38
activesupport-4.0.1
builder-3.1.4
erubis-2.7.0
rack-1.5.2
rack-test-0.6.2
actionpack-4.0.1
mime-types-1.25
polyglot-0.3.3
treetop-1.4.15
mail-2.5.4
actionmailer-4.0.1
activemodel-4.0.1
activerecord-deprecated_finders-1.0.3
arel-4.0.1
activerecord-4.0.1
activerecord-jdbc-adapter-1.3.3
jdbc-mysql-5.1.27
activerecord-jdbcmysql-adapter-1.3.3
hike-1.2.3
jruby-jars-1.7.8
json-1.5.0-java
json-jruby-1.5.0-java
net-ldap-0.3.1
thor-0.18.1
railties-4.0.1
tilt-1.4.1
sprockets-2.10.0
sprockets-rails-2.0.1
rails-4.0.1
rest-client-1.6.7
rufus-scheduler-3.0.2

When you say “Since 1.7.4” you mean 1.7.5 and higher? I have 1.7.4
running fine on WebSphere, but later releases of JRuby haven’t been
working. This is a known issue(s). I think some of these issues are
relevant:

  • Bruce

Yes, 1.7.4 works fine. Our production version is stuck at 1.7.4 until I
can get 1.7.8 to work.

What is also interesting is removing jruby-openssl from the Gem file
causes a different error. Maybe if this problem is fixed, then
everything will work.

if I look the jruby-jars then the following jar files are vendored:

lib/ruby/shared/bcpkix-jdk15on-1.47.jar
lib/ruby/shared/bcprov-jdk15on-1.47.jar
lib/ruby/shared/kryptproviderjdk.jar
lib/ruby/shared/kryptcore.jar
lib/ruby/shared/jopenssl.jar

sticking them into WEB-INF/lib could indeed help or maybe any subset of
them. please let me know if that really helps.

  • christian

Thanks…this worked!

I copied all 5 jar files to my lib directory, removed the reference to
jruby-openssl in my Gem file, deployed my app and it works.

I suspect if I included the Gem reference to jruby-openssl, then I would
just need the two krypt jar files.

Ken:

I had similar looking issues , wonder if this works for you, put the
following in your load path or class path. I am packaging with warbler
and I keep the following jars in my lib directory I also push said
directory explicitly in to the load path so that its accessible when the
app sever explodes the war

jars:

bcmail-jdk15-146.jar
bcprov-jdk15on-1.47.jar
jopenssl.jar

Please do let me know if this helps, curious.

Charles

I updated to jRuby 1.7.9 and now getting this error in WAS:

ERROR: initialization
failed:.org.jruby.rack.RackInitializationException: no such file to load
– classpath:C:/META-INF/jruby.home/lib/ruby/shared/krypt_missing

Any ideas?

Sure and great news.

BTW, I was also encountering issues where it was picking up the wrong
bouncy castle jars, now I was in the flux between 1.7.4 and 1.7.8 which
now warbler automatically uses , so perhaps just a dev artifact of where
I was but anyhow thats why Im including those explictly. It seems to be
that when in doubt and when you just dont have time , just include those
jars in the local lib directory , perhaps in the vendored directory (not
tried packing up with bundler), Warbler uses that also as a one of its
config.dirs.

Hate to sidetrack, but I was hoping that Christians Jbundler would
basically do that for me i.e. put the jar dependencies in the lib dir
when used with bundler, but have not tried to figure it out. Just
including it in my gem file at the top did not seem to do that.

Charles

Are you running under Windows ? If I recall in Windows once the app
server explodes the war if the path where the war is exploded has spaces
you will get that error.

Let me know I bumped into that but under Windows 2003 server, had to
change the users temp location vars which in my case was where Jetty was
exploding the war.

-Charles

Yes, I am running WAS on Windows.

Note however, 1.7.8 worked OK (after I moved the ssl jars into my LIB
directory). I figured a new bug was introduced with 1.7.9.

With 1.7.9, I get this error no matter if the ssl jars exist or don’t
exist in LIB.

The WAS file path to the exploded WAR file has no spaces in the path.

This is the backtrace:

LoadError: no such file to load –
classpath:C:/META-INF/jruby.home/lib/ruby/shared/krypt_missing
require at org/jruby/RubyKernel.java:1083
require_relative at classpath:/jruby/kernel19/kernel.rb:21
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/krypt.rb:37
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/krypt/ossl.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/krypt/ossl.rb:33
load at org/jruby/RubyKernel.java:1099
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/jopenssl19/openssl.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/jopenssl19/openssl.rb:23
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/jopenssl/load.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/jopenssl/load.rb:20
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/openssl.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
classpath:/META-INF/jruby.home/lib/ruby/shared/openssl.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
C:/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/IBM-23H4ECBETIINode01Cell/USPTrack.ear/USPTrack.war/WEB-INF/gems/gems/activesupport-4.0.2/lib/active_support/key_generator.rb:1
require at org/jruby/RubyKernel.java:1083
(root) at
C:/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/IBM-23H4ECBETIINode01Cell/USPTrack.ear/USPTrack.war/WEB-INF/gems/gems/activesupport-4.0.2/lib/active_support/key_generator.rb:2
require at org/jruby/RubyKernel.java:1083
(root) at
C:/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/IBM-23H4ECBETIINode01Cell/USPTrack.ear/USPTrack.war/WEB-INF/gems/gems/railties-4.0.2/lib/rails/application.rb:1
(root) at
C:/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/IBM-23H4ECBETIINode01Cell/USPTrack.ear/USPTrack.war/WEB-INF/gems/gems/railties-4.0.2/lib/rails/application.rb:3
(root) at
C:/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/IBM-23H4ECBETIINode01Cell/USPTrack.ear/USPTrack.war/WEB-INF/gems/gems/railties-4.0.2/lib/rails.rb:1

The path seems to be working for the other files in the call stack with
the only difference being the require_relative call.

I am running WAS on my dev PC and Webrick works without any problems.

I’m baffled and not sure where to look next.

Yes, I just noticed

classpath:C:/META-INF/jruby.home/lib/ruby/shared/krypt_missing

is different from

classpath:/META-INF/jruby.home/lib/ruby/shared/krypt.rb:37

C:/ is inserted in the path.

Looks like a bug.

I guess I will stick with 1.7.8 for now.

This looks the only change between 1.7.8 and 1.7.9 that could have
caused the issue:

a quote :

"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.
from here:

perhaps helpful

Charles