Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Ruby addendum: [equinox-dev] BSF, Groovy, class/OSGi resolution

I have had the most luck with Groovy, JRuby and Beanshell as far as utilizing them in an OSGi container with BSF.  Rhino in my experience has been a nightmare and I can almost get Jython to work.

James

On Mon, Oct 20, 2008 at 11:41 AM, Craig Phillips <lcphillips@xxxxxxxxxxxxx> wrote:
Hi,

I also managed to successfully get ruby scripting up and running with BSF and OSGi ... that was another riddle WRT class loaders... I'm using ruby 1.3.0, BTW...  Turns out, it's a similar trick to log4j... Ruby's JavaSupport.class is essentially hard set to use the context class loader... So. I basically play the "take away and put back" game... I swap out the context class loader for my own custom class loader -- which has a copy of the original context class loader anyway; When the script is complete, I simply put the original back -- in it's own thread, of course... This "trick" also didn't "break" groovy...  I'm not doing any other scripting engines at the moment, but apparently each engine has it's own "quirkiness"...

Between ruby and groovy, I prefer groovy... the **feel** is a bit closer to java... Of course, I'm no guru...

For what it's worth, Craig Phillips, Praxis

________________________________

From: equinox-dev-bounces@xxxxxxxxxxx on behalf of Craig Phillips
Sent: Fri 10/17/2008 8:34 AM
To: equinox-dev@xxxxxxxxxxx
Subject: [equinox-dev] BSF, Groovy, class/OSGi resolution


Hi,

Update to a former post (of which I deleted) on the same subject -- I did manage to get bsf/groovy working in an OSGi container and do class resolution...  I was on the right track, thanks to and appreciate of support from J. Ervin as well as postings around the net -- to write and plug in a custom class loader...

My problem was that I did not implement all the methods and method signature variants... I blame that on Sun because: Classloader should be an interface, not something you extend;

When using BSF/groovy in an OSGi container, you want to write a custom class loader (be sure to implement findClass() as well as loadClass() -- bsf uses loadClass() while groovy uses findClass() -- go figure) that will search through the registered bundles in the OSGi container for a class, noting that Bundle has a method called loadClass() [what, no findClass() ??? LOL];

Anyway, you register your custom class loader to bsf and groovy a la:  BsfManager.setClassLoader()...

BTW - be sure to consult the context class loader as well -- useful for core classes as well as when junit testing....

Lastly, I did not implement getResource() and variations thereof -- Bundle does not, IIRC, have anything equivalent [and, I think that makes sense]...

For what it's worth, Craig Phillips, Praxis


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev




--
James E. Ervin, IV

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein

Blog: http://iacobus.blogspot.com

Back to the top