[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform] Re: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4)

I guess nobody knows the answer (or is willing to say ;-).  I have now
reproduced the same problem on Windows, so it is not a Mac issue.  And I set
up the jars like I always do, with the jar in an external folder and the
native library beside it and the build path points to both.  But I still get
an error that it cannot find a public class in the native library.  But it
compiles fine - it is just at runtime it fails.  This strongly suggests to
me that Eclipse is not loading the native library.  The exact same code and
procedures work fine in Eclipse 3.2.

I found this:
http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv
/porting/3.3/incompatibilities.html
And section 3 talks about boot delegation changes in class loading, but
frankly that is out of my ken.

Can some classloading maven suggest what I might do next?  Could this be
some manifest/buddy-loading issue?  I'll look at that next, but any
suggestions would be appreciated.

Thanks, Ric


On 2/9/09 3:07 PM, in article C5B5F73E.1B2F8%riwright@xxxxxxxxx, "Ric
Wright" <riwright@xxxxxxxxx> wrote:

> I poked at this a little more during lunch and I am still puzzled.
> Previously, on Windows, I would point at the JOGL jar, and then set the
> native library location field.  However, since Eclipse found the jars on its
> own and placed them in JRE System Library section of the build path dialog,
> I thought I would just set the native location there.  But no soap.  Eclipse
> lets me set it, but immediately it clears it again - read-only perhaps?  I
> suppose I could move the JOGL jars somewhere else and explicitly add them
> and set their native library attributes, etc.  But since Eclipse and the Mac
> have done 90% of the task seamlessly, that seems like a shame.
> 
> Does anyone know the right way to do this?
> 
> TIA, Ric
> 
> 
> On 2/8/09 4:30 PM, in article C5B4B919.1B1AC%riwright@xxxxxxxxx, "Ric
> Wright" <riwright@xxxxxxxxx> wrote:
> 
>> OK.  After a little digging I found a few more things.  First, I had a raw
>> Iterator, which Eclipse warned me about, but which worked fine in 3.2.  But
>> apparently not in 3.4.  It also caused another weird behaviour in that there
>> were no local variables shown.
>> 
>> So I fixed the Iterator and suddenly I had local variables and got more info
>> back in the stack trace.  Turns out that Eclipse is apparently complaining
>> that it cannot instantiate one of my classes.  I call Class.forName() with
>> the name of one of my classes.  Since I am using JOGL, that class extends
>> GLEventListener, which at base is a native class accessed via JNI.  All the
>> proper JARs and JNILibs are in /Library/Java/Extensions and the
>> java.library.path points to it.  This all seems correct to me.  The build
>> path for the project shows the JOGL libs under the JRE System libs in the
>> build path dialog.  Again, this all seems correct.
>> 
>> I'm still digging, but if this suggests anything to anybody, I'd appreciate
>> it.
>> 
>> TIA, Ric
>> 
>> 
>> On 2/7/09 12:32 PM, in article C5B32FD4.18A37%riwright@xxxxxxxxx, "Ric
>> Wright" <riwright@xxxxxxxxx> wrote:
>> 
>>> Thanks for responding, Derek.
>>> 
>>> AFAIK, the activator is valid (attached).  When brought up in Eclipse, there
>>> is only a warning about a raw iterator (that I will fix once I get past
>>> this).
>>> 
>>> I did read through the migration and the only thing that seemed relevant was
>>> the boot delegation order.  I tried the org.osgi.framework.bootdelegation=*
>>> in the config.ini, but it made no difference, so that doesn't seem to be it.
>>> 
>>> The execution never gets to the Activator BTW, neither ctor nor start()
>>> methods are ever called.  My suspicion is that one of the dependencies (e.g.
>>> The JOGL or Java3D jars can't be resolved so the message is a little bogus.
>>> But I don't know how to find out WHICH class it thinks it can't find.  It
>>> says com.geofx.opengl.view.OpenGLView but I think that is misleading since
>>> that file IS in the exported package, etc.  But I could be missing
>>> something.
>>> 
>>> I included the plugin.xml, manifest.xml etc. in the previous post on this
>>> thread.
>>> 
>>> Thanks, Ric
>>> 
>>> 
>>> On 2/7/09 10:54 AM, in article gmkld3$9h$1@xxxxxxxxxxxxxxxxx, "Derek"
>>> <subs@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>> 
>>>> I think it more likely that your activator isn't a valid activator for
>>>> 3.3. Have you tried opening the source in a 3.3 PDE and see what it
>>>> complains about?
>>>> 
>>>> Have you looked at the 3.3 Migration Guide?
>>>> 
>> 
> 
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/>>
>
>> 
>> p
>>>> orting/eclipse_3_3_porting_guide.html
>>>> 
>>>> Ric Wright wrote:
>>>>> This is a post I put up in the newbie section, but got no response.  I
>>>>> subsequently saw several posts about invalid activators on this list
>>>>> (though
>>>>> none were entirely relevant to my case).  The odd thing about this is that
>>>>> it is absolutely due to some change in classloaders from 3.2 to 3.3.  I'm
>>>>> still working on it, but if anyone can make any suggestions, I would be
>>>>> appreciative.
>>>>> 
>>>>> TIA, Ric
>>>>> 
>>>>> --------------------------------------------------
>>>>> I've gotten a little farther. I turned on the debugging in the launch tab
>>>>> and I found:
>>>>> 
>>>>> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
>>>>> !MESSAGE The activator
>>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>>>> invalid
>>>>> !STACK 0
>>>>> org.osgi.framework.BundleException: The activator
>>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>>>> invalid
>>>>> 
>>>>> at 
>>>>> 
> 
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator>>>>
>
> (
>>>>> AbstractBundle.java:146)
>>>>>     at
>>>>> 
> 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleCont>>>>
>
> e
>>>>> xtImpl.java:980)
>>>>>     at
>>>>> 
> 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.>>>>
>
> j
>>>>> ava:346)
>>>>> 
>>>>> Not clear what change between 3.2 and 3.3 would have produced this error.
>>>>> Some spelunking suggests it might have something to do with the third
>>>>> party
>>>>> jars
>>>>> (e.g. Jogl) that I use but no further clues.  But a JOGL view works fine
>>>>> only plugins fail.  Any suggestions or tips welcome.
>>>>> 
>>>>> TIA, Ric
>>>>> 
>>>>> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@xxxxxxxxx, "Ric
>>>>> Wright" <riwright@xxxxxxxxx> wrote:
>>>>> 
>>>>>> I have a plugin that I wrote a while ago.  It's a normal Eclipse plugin.
>>>>>> It's main class is com.geofx.opengl.OpenGLView.  The plugin loads and
>>>>>> runs
>>>>>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4  with the
>>>>>> message
>>>>>> 
>>>>>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to
>>>>>> load
>>>>>> class com.geofx.opengl.view.OpenGLView."
>>>>>> 
>>>>>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4.  To
>>>>>> be
>>>>>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>>>>>> that way). I don't really know how to start figuring this out.
>>>>>> 
>>>>>> I posted a question here once before about this but didn't get any
>>>>>> pointers.
>>>>>> I am happy (or at least resigned) to dig into this, but frankly not sure
>>>>>> where to start.  Any pointers would be appreciated.
>>>>>> 
>>>>>> Thanks,
>>>>>> Ric
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>