I hadn’t noticed this until now…replies inline below…
On Tue, May 11, 2010 at 7:42 AM, Krum B. [email protected]
wrote:
Hi dear JRuby folks,
I was wondering whether i could place here some questions of mine about
integrating JRuby with OSGi.
The JRuby jars we publish have been "bnd"ed so they can be used with
OSGi, but that’s about as far as we have gone.
being done by someone ? Have someone tried to make such experiments ? I
suppose that there could emerge
some issues with getting this to work cleanly. One of them could be
classloading/resource-related.
The closest analog, I suppose, would be mkristian’s work on
integrating RubyGems and Maven:
http://github.com/mkristian/jruby-maven-plugins
There, he’s basically taking the package information from the RubyGem
and converting it to Maven (pom) data, with an explicit dependency on
JRuby of course. This seems like a pretty good approach, since it
single-sources the dependencies and project metadata from RubyGems
themselves.
He also has the reverse direction, making Maven artifacts appear to be
RubyGems, There could be something equivalent for non-OSGi JRuby
bundles.
I’m very interested in trying to make JRuby work better in an OSGi
environment, but I frankly have almost no knowledge of how OSGi is
structured. You’d definitely have support from JRuby proper if you
wanted to try to make this work well.
What could you kindly tell me about the analogy of class loading in Ruby ?
How could a Ruby program dynamically
load resources or even classes ? Is there such an analogous mechanism in
Ruby at all ?
Most Ruby code is loaded explicitly at runtime by filename, e.g.
“require ‘path/to/my/library’” looking for path/to/my/library.rb
somewhere in the load path. The load path is roughly analogous to a
class path, and so then the filename given to require is roughly
analogous to a classloader resource lookup (and when completely
bundled into jar files, that’s what it actually is in JRuby too).
Under normal operation, Ruby code will be interpreted for a while and
then piece of it will compile to JVM bytecode, loaded under a child
classloader of whatever classloader loaded JRuby. These classes are
mostly just “bags of methods” and have no real utility to Java
consumers; they’re just a vector to get bytecode-compiled Ruby code
loaded into memory.
There are newer options in JRuby (and in the jrubyc compiler) to
precompile Ruby scripts entirely ahead-of-time. In that case, you’d
precompile them and just bundle everything as part of some jar file.
The classloading has been a tricky issue for OSGi and JRuby in the
past, but we have never really understood how to do it properly. We
basically need to be able to load new bytecode at runtime to speed hot
code up, or else we need to iron out remaining challenges in the
ahead-of-time compilation process. Maybe you can help us understand
OSGi’s requirements here.
Do things change in a Rails environment ? (Since Java EE application servers
typically define complex hierarchy of
class loaders that can handle applications and their modules, and thus one
could question himself whether Rails
defines some different class loading approaches from a ‘Ruby SE’ environment
)
Rails applications deployed to production generally don’t change much
after their initial boot cycle. Methods may come into existence later,
like if a rarely-used controller calls a new “find” variant on an
ActiveRecord model. Much of the Rails + application code will exist in
a static form on disk, but some is generated after startup as part of
the boot process or as part of lazily-created methods and adapters.
It has always been my hope that we could unify the load path and class
path concepts, but we have so far not attempted this. There’s also
still a small but important need for “eval” to work, which means that
under many circumstances JRuby will need to be able to load new
bytecode at runtime, but it is also possible to just leave it
interpreted if the performance cost is not too high.
And what about JRuby ? How does it handle class loading ? If i have a
JRuby-based OSGi bundle, could i somehow
force it to use the underlying OSGi class loading ? Or not ?
JRuby proper doesn’t do much for classloading tricks. Where things get
complicated are when loading jitted code (as described above) or when
people dynamically load jar files into Ruby applications (a la
“require ‘something.jar’”) which adds something.jar (located somewhere
in the load path) to a JRuby-instance-wide URLClassLoader. The former
case may present challenges to OSGi, but the loaded code should only
depend upon JRuby proper, and therefore could be seen as a
wholly-contained child domain. The latter would definitely require
some OSGi love, since ideally those required libraries would get
sourced out of OSGi (or at least would not conflict with how OSGi
wants to locate and load resources).
And I’ll say it again: I’d love it if we played better in an OSGi
environment, and we will entertain any suggestions to help us get
there. We’re just not really OSGi experts, so we need help deciding
what direction to go and what changes need to be made
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
)