Jruby-openssl possible bug?


#1

I have encountered some odd behaviour with jruby-openssl, but I am not
sure
if this is a bug or a feature.

I am running JRuby 1.1.5 on Windows XP with the jruby-openssl gem
installed.

I am trying to make an HTTPS request from a piece of code that creates a
class called Config.

It seems that the existance of the Config class is causing “require
‘net/https’” to fail and fall back to the limited openssl that comes
bundled
with JRuby. This then causes an odd error later on. As an example, in
jirb:

irb(main):001:0> class Config ; end
=> nil
irb(main):002:0> Config.class
=> Class
irb(main):003:0> require ‘net/http’
=> true
irb(main):004:0> require ‘net/https’
JRuby limited openssl loaded. gem install jruby-openssl for full
support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
=> true
irb(main):005:0> h = Net::HTTP.new(‘www.test.com’, 443)
=> #<Net::HTTP www.test.com:443 open=false>
irb(main):006:0> h.use_ssl = true
TypeError: #Class:01x1398cac is not a module
from C:/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:62:in require' from C:/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:62 from C:/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:3:inrequire’
from C:/jruby/lib/ruby/site_ruby/1.8/jruby/openssl/gem.rb:3
from C:/jruby/lib/ruby/site_ruby/1.8/jruby/openssl/gem.rb:124:in
use_ssl=' from (irb):7 from C:/jruby/lib/ruby/1.8/irb.rb:150:ineval_input’
from C:/jruby/lib/ruby/1.8/irb.rb:259:in signal_status' from C:/jruby/lib/ruby/1.8/irb.rb:147:ineval_input’
from C:/jruby/lib/ruby/1.8/irb.rb:146:in eval_input' from C:/jruby/lib/ruby/1.8/irb.rb:70:instart’
from C:/jruby/lib/ruby/1.8/irb.rb:69:in catch' from C:/jruby/lib/ruby/1.8/irb.rb:69:instart’
from c:\jruby\bin\jirb:19
irb(main):007:0>

This can be worked around by renaming the Config class to something
else,
and the code works fine like that, but I would have expected “require
‘net/https’” to have thrown an error to indicate that the require had
attempted to use jruby-openssl and failed, falling back to the built in
openssl support.

The reason for this seems to be that jruby-openssl creates a module
called
Config, which it cannot do if the symbol Config is already in use. But
something is suppressing the exception that I would normally expect.

Is this a bug?


#2

Tom R. wrote:

Is this a bug?

Well it certainly seems like there’s some bugs there somewhere. How does
it behave if you have the jruby-openssl gem installed? It doesn’t look
like it’s installed in the example you provided. Can you try to narrow
this down and toss it into a bug?

It could be as simple as us not creating a Config class, or creating it
under a different namespace (JRuby::OpenSSL?)

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#3

On Fri, Nov 28, 2008 at 7:38 AM, Charles Oliver N. <
removed_email_address@domain.invalid> wrote:

something is suppressing the exception that I would normally expect.
under a different namespace (JRuby::OpenSSL?)

That is with jruby-openssl installed. Here is the behaviour when I
don’t create a Config class beforehand:

irb(main):001:0> defined? Config
=> nil
irb(main):002:0> require ‘net/http’
=> true
irb(main):003:0> require ‘net/https’
=> true
irb(main):004:0> h = Net::HTTP.new(‘www.test.com’, 443)
=> #<Net::HTTP www.test.com:443 open=false>
irb(main):005:0> h.use_ssl = true
=> true
irb(main):006:0> defined? Config
=> “constant”
irb(main):007:0> Config.class
=> Module

And that goes on to work fine from that point onwards.

Notice that the line:

“JRuby limited openssl loaded. gem install jruby-openssl for full
support.”

Is not printed this time after “require ‘net/https’” is run.

Having jruby-openssl create the Config module in a different namespace
would
probably fix this problem, but it is slightly concerning that no
exception
is raised when ‘net/https’ is require’d. Maybe when net/https falls
back to
the built-in openssl after it has failed to load jruby-openssl, it could
check to see if the jruby-openssl gem is installed and raise an
exception if
so? Because if jruby-openssl is installed then it shouldn’t be falling
back
to the built-in openssl support?


#4

Tom R. wrote:

Having jruby-openssl create the Config module in a different namespace
would probably fix this problem, but it is slightly concerning that no
exception is raised when ‘net/https’ is require’d. Maybe when net/https
falls back to the built-in openssl after it has failed to load
jruby-openssl, it could check to see if the jruby-openssl gem is
installed and raise an exception if so? Because if jruby-openssl is
installed then it shouldn’t be falling back to the built-in openssl support?

Ok, I think the problem here is that our built-in logic for “magically”
requiring the gem captures and LoadError that comes out of the gem
require and falls back on the dummy logic. That’s how we detect that the
gem isn’t available, but it also masks any real load errors.

So the Config thing triggers this weird behavior, but the actual problem
is the openssl dummy wrapper capturing too much. Hmm.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#5

Tom R. wrote:

Bug created for this:

http://jira.codehaus.org/browse/JRUBY-3195

Resolved! Long story short, the Config conflict was coming from
‘rbconfig’ library, so you should probably try to avoid using Config as
a top-level constant (lots and lots of libs require ‘rbconfig’). As for
the errors being swallowed…I’ve cleaned up that logic a bit so it only
swallows the one error we want to silence, that of Gem::LoadError when
the ‘jruby-openssl’ gem can’t be activated. We use that as a trigger to
fall back on our dummy impl, and all other errors propagate as normal.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#6

On Fri, Nov 28, 2008 at 7:38 AM, Charles Oliver N. <
removed_email_address@domain.invalid> wrote:

something is suppressing the exception that I would normally expect.
under a different namespace (JRuby::OpenSSL?)

Bug created for this:

http://jira.codehaus.org/browse/JRUBY-3195