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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>


        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
        [email protected]
        https://dev.eclipse.org/mailman/listinfo/equinox-dev
        


-- 
Cheers, Stuart

<<winmail.dat>>

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to