Hello,

suppose you have a Rails project and you can start it with

# jruby -S glassfish


Then, consider starting it with

# CLASSPATH="$CLASSPATH:$(find /usr/share/jruby/lib/ruby/gems/1.8/gems/glassfish-0.9.5-universal-java/modules -iname
"*.jar" -printf "%p:")" jruby -S glassfish

instead where "/usr/share/jruby/lib/ruby/gems/1.8/gems/glassfish-0.9.5-universal-java" is the path the glassfish
gem is installed.

In the former case, glassfish starts successfully.
In the latter case, glassfish fails to start (e.g. the process exits after some seconds), with no apparent reason why
glassfish fails to start.

The only difference is that the JavaVM has access to all possible .class files right from the start. Can this make a
difference? Maybe. But it should not make a difference. (Should it?)

Date: 2009-09-02 18:05
Sender: Vivek Pandey

I am not sure what you are trying to do and why.

Anyway, GlassFish loads the required jar files itself and does
not look for classes to be present in its classpath and does
lots of injections of different services. What might happen is
that there are different versions of the classes present in JVM
and that might be causing this issue.

There is no point in making these classes available right from
the start. Do you think it has any benefit over how glassfish
does it by itself?

The only way you should start glassfish is by simply typing 'jruby
-S glassfish' and it knows what to do.

I am closing this issue as not a bug. If you want to further
discuss please bring the discussion to open-forum,
http://rubyforge.org/forum/forum.php?forum_id=21309