Charles
I spent more time debugging this on mac os x and windows and I have to
say that I am now quite confused about jruby behaviour.
On the mac, jruby seems to do the right thing, consistent with the code
you proposed below, whereas the parent class loader of gfv3 is a
JRubyClassLoader with 1 jar file in the classpath :
glassfish-10.0-SNAPSHOT. The parent class loader of that one is the
AppClassLoader for jruby which contains all the .jar files in the jruby
lib directory.
However on windows, the situation is quite different. The parent class
loader of gfv3 is directly the AppClassLoader for jruby not only
including the .jar files in the jruby lib directory but also including
all the .jar located in the glassfish lib installed gem like I described
below.
This is the exact same gem I installed on mac and windows, I am using
jruby rev 4201 (1.0.1) on both machines. On Mac OS, this is jdk 5, on
Windows, this is JDK 6.
Can you shed some light on what may cause this behaviour difference ?
Thanks, Jerome
Jerome Dochez wrote:
> lovely debugging session.
>
> so we have a problem starting gfv3 from jruby. The issue is that the
> jruby classloader itself includes all jars files found in any
> installed gem. That of course includes *all* gfv3 jars files so too
> bad for the modular application server, everything is loaded by the
> single parent class loader. Although there could be ways of working
> around that in this present situation, I am afraid that we would get
> into more issues if we don't stop having the gfv3 modules loaded by
> the jruby class loader. Is there a way to achieve this ?
>
> jerome
>
> Jerome Dochez wrote:
>> the gem does not seem to work correctly on windows, probably due to
>> GF not understanding where it is located. I am going to debug this
>> and push a new version.
>>
>> jerome
>>
>> Charles Oliver Nutter wrote:
>>> I tried the current gem and it doesn't seem to have the stuff below.
>>> Basically, inside the gem bin/glassfish_rails.rb needs to be the
>>> first section of code below and lib/glassfish.rb needs to be the
>>> second section of code. This will allow glassfish_rails to install
>>> with gem's executable wrappers and also to be loaded as a library if
>>> someone wants to start up glassfish from another app.
>>>
>>> We should probably figure out how this would be named and versioned
>>> as well...10.0 is likely to be pretty confusing for some folks, and
>>> the gem itself should probably be named
>>> "glassfish_rails-<version>-java" or -jruby.
>>>
>>> - Charlie
>>>
>>> Charles Oliver Nutter wrote:
>>>> - The startup script should be a normal Ruby script rather than a
>>>> shell script; then we do all the hassle of locating JRuby and Java
>>>> for you, as well as processing normal JRuby command-line logic.
>>>> Here's the script I came up with:
>>>>
>>>> bin/glassfish_rails:
>>>>
>>>> <CODE>
>>>> #!/usr/bin/env jruby
>>>> require 'java'
>>>> require 'rubygems'
>>>> require 'glassfish'
>>>>
>>>> GlassFish.startup(ARGV)
>>>> </CODE>
>>>>
>>>> And inside the gem under lib, glassfish.rb:
>>>>
>>>> <CODE>
>>>> require 'glassfish-10.0-SNAPSHOT.jar'
>>>>
>>>> module GlassFish
>>>> import com.sun.enterprise.glassfish.bootstrap.Main
>>>> def startup(args)
>>>> Main.main(args.to_java(:string))
>>>> end
>>>>
>>>> module_function :startup
>>>> end
>>>> </CODE>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>