[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)
|
- From: Ric Wright <riwright@xxxxxxxxx>
- Date: Thu, 12 Feb 2009 09:07:20 -0800
- Newsgroups: eclipse.platform
- Organization: EclipseCorner
- Thread-index: AcmJYywEsuI+7cvi1EKvu9RbY9D4oQA6mjBwAC9oQYcAiknhDQ==
- Thread-topic: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4)
- User-agent: Microsoft-Entourage/12.15.0.081119
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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>