| RE: Ruby addendum: [equinox-dev] BSF, Groovy, class/OSGi resolution |
Hi, For what it's worth, I am not seeing the memory leak with groovy... I'm only seeing it with ruby... I don't see a leak with a 24x7 ruby script, only when I "yo-yo" and start/stop/restart scripts... My gut feeling tells me it has something to do with the attachment to the class loader, which I pass along from the bundle activator, which gets it from equinox which <who knows where it comes from but suffice to say>... Thought I'd throw that out there... At least I think that settles the matter that it's not my code per se, nor BSF... Regards, Craig Phillips, Praxis ________________________________ From: equinox-dev-bounces@xxxxxxxxxxx on behalf of Craig Phillips Sent: Mon 10/20/2008 1:15 PM To: Equinox development mailing list Subject: RE: Ruby addendum: [equinox-dev] BSF, Groovy, class/OSGi resolution Hi, I did run into one issue - a memory leak... and, I don't think it's in my code, although I'll desk check it with a fine tooth comb... I've been watching a la jconsole (as well, I had yoyo'd enough time that I actually ran out of heap)... It seems that when I have a script return and I subsequently join the thread, jconsole is happy with the cleanup as far as threads are concerned, but the heap does not return to original levels; When I run a new bsf instance (and engine thereof - either groovy or ruby), it adds about 2 to 3 mb to the heap size; I reuse my class loader instance, however -- hmmm... I wonder if I should un-reference it and start over? Maybe BSF and the engines are attaching to the loader -- at which point they "pile up" ??? Shrug... Anybody out there have similar experiences? Thanks again... ________________________________ From: equinox-dev-bounces@xxxxxxxxxxx on behalf of Simon Kaegi Sent: Mon 10/20/2008 1:03 PM To: Equinox development mailing list Subject: Re: Ruby addendum: [equinox-dev] BSF, Groovy, class/OSGi resolution Craig, This is starting to sounds a bit like what I had to do to get JSPs to compile and run in an OSGi environment. You might want to take a look at some of the code in the org.eclipse.equinox.jsp.jasper project as it might provide an even better fit in terms of the class loaders you want. -Simon Inactive hide details for "Craig Phillips" ---10/20/2008 12:42:04 PM---Hi,"Craig Phillips" ---10/20/2008 12:42:04 PM---Hi, From: "Craig Phillips" <lcphillips@xxxxxxxxxxxxx> To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx> Date: 10/20/2008 12:42 PM Subject: Ruby addendum: [equinox-dev] BSF, Groovy, class/OSGi resolution ________________________________ 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 (See attached file: winmail.dat)_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<winmail.dat>>