| RE: [equinox-dev] BSF, Groovy, OSGi - class resolution |
Hi,
Well, I'm about to throw in the towel, regarding BSF; I think I'll move to javax.scripting and see where that leads (which is a bit unwieldy, I know)...
I've tried bsfManager.setClassPath() -- that doesn't work;
I've tried bsfManager.setClassLoader() with just about every class loader out there, including writing my own class loader, following the groovy monkey scheme, which basically wraps Bundle.loadClass() -- and that didn't work;
Now, if I run my script using straight groovy with the ENVIRONMENT variable CLASSPATH set to point to org.eclipse.services.xxxx.jar / org.osgi.compendium.jar, that actually works (where the class to resolve is org.osgi.services.log.LogService)!
So, that means that the hook(s) to pass class loaders / class path through BSF to groovy are just not implemented / wired up / etc... I've spent days and days trying just about everything and it simply won't set up the class resolution...
For what it's worth, appreciate several folk out there attempting to give me a hand, but BSF just seems to be going no where with groovy and/or ruby... Interestingly, I've seen a few posts out there about beanshell performing admirably while the others fall down (which, of course, seems to be in agreement with my experiences) -- but there have been no posts on any resolution...
Shrug, I gave it a good attempt, but I'm throwing in the towel on BSF...
Have a good weekend, Craig
________________________________
From: equinox-dev-bounces@xxxxxxxxxxx on behalf of Craig Phillips
Sent: Wed 10/8/2008 2:45 PM
To: Equinox development mailing list
Subject: RE: [equinox-dev] BSF, Groovy, OSGi - class resolution
Re: Pax-Script... looks pretty nice... unfortunately, for reasons unknown, I'm sort of stuck on jdk1.5... It's nice to see the various scripting engines moving to OSGi-fication...
I tried doing the BSFManager.setClassLoader(Thread.currentThread().getContextClassLoader()); -- that didn't work either...
One thing I wanted to put out there, that's pretty funny/confusing -- if I use the objects, and never actually declare a class, everything works... take for example:
// Note that bundleContext is declared as a bean in my java bundle that wraps BSF (e.g., bsfManager.declareBean() ); So, in groovy:
def logRef = bundleContext.getServiceRef("org.osgi.service.log.LogService");
def logger = logRef.getService();
logger.log(1, "Test");
The above actually works... yet, if I attempt to declare an actual class, then it fails... I'm not sure what that is telling me... I want to content that it's a class loader issue versus a class path issue, since it seems to be able to work with the object instances/references, as long as I don't actually type anything... But, maybe that is suggesting just the opposite - that the declaration of the class is a class path issue, not a class loader issue...
OK, my brain could be getting full... I've been racking it over this stuff for a few hours now...
For what it's worth, thought I'd throw that out there... I'd look at the source for pax-script, but that leads back to jsr223 which is jdk6/above and catch-22... I must say, as compared to how wieldy javax.scripting is (at least when you marry it with OSGi), the pax-script seems to have done all the hard work -- but I just barely scratched the surface on pax-script...
Thanks again, Craig Phillips, Praxis
________________________________
From: equinox-dev-bounces@xxxxxxxxxxx on behalf of Stuart McCulloch
Sent: Wed 10/8/2008 1:26 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] BSF, Groovy, OSGi - class resolution
2008/10/9 Craig Phillips <lcphillips@xxxxxxxxxxxxx>
Hi,
I'm attempting to do groovy a la BSF, as embedded in an OSGi/equinox bundle...
I get this "unable to resolve class" exception on something like the following:
import org.osgi.service.log.* // seems to get passed this line
def logger = new LogService(); // exception is thrown here
I have been surfing for help, but the only thing I get is along the lines of external classpath options (versus using the classes as loaded into the bundle)...
Any ideas/suggestions? Thanks, Craig Phillips, Praxis
PS - I'm not considering javax.scripting (jsr-223 I believe) at this time...
even though you're not considering jsr-223, you might want
to look at the OSGi scripting work done by Hendy Irawan:
http://wiki.ops4j.org/confluence/display/ops4j/Pax+Script
as that might give you some hints how to solve this issue
( afaik Groovy 1.5.7-SNAPSHOT has OSGi manifests )
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Cheers, Stuart
<<winmail.dat>>