felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thiébault Benoît <...@artenum.com>
Subject Re: VTK OSGi bundle and Felix
Date Thu, 04 Nov 2010 15:21:06 GMT
Thanks Richard !
Can I say I love you?

"org.osgi.framework.bootdelegation=*" did the work and my VTK bundle works perfectly now.
Just to understand what I just did, what is this variable doing?

Regarding the processor, I indeed have a Core2Duo proc, which is 64bits. The VTK version I
compiled is 64bits as well.

Kind regards, and again thank you very much

Benoît

Le 4 nov. 2010 à 16:06, Richard S. Hall a écrit :

> On 11/4/10 10:43, Thiébault Benoît wrote:
>> Thank you Richard,
>> 
>> I added "processor=x86_64" and it "worked". I now have the same error message than
with Equinox :-)
>> 
>> When I add like you "processor=x86", it crashes, but my error message is not as explicit
as yours:
>> 
>>> org.osgi.framework.BundleException: Unresolved constraint in bundle test-osgi-vtk
[5]: No matching native libraries found.
> 
> It appears that you have a different processor than me, which is why x86 doesn't work
for you.
> 
>> I have two questions regarding this "processor" issue:
>> - Could it be possible in future versions of felix to have a more detailed error
message for this issue?
> 
> It is difficult to get a detailed error message, because the selecting of matching libraries
happens earlier than the resolve, so by then we don't know why they didn't match.
> 
>> - Is it a bug or a feature? I mean, what does the OSGi standard say about the "processor":
is it mandatory (in this case, Felix is right to crash) or optional (and its a felix bug)?
> 
> It didn't crash, it just didn't resolve the bundle.
> 
> I'm not sure about whether requiring processor is correct or not, so I will look into
it, but it would definitely be a best practice.
> 
>> Now, regarding my VTK-specific error, does anyone have any clue what OSGi does that
makes the pure Java application work and not the OSGi bundle?
>> I have looked for an answer to this problem for days and can't find what causes it
(and how to solve it)
>> Any hint is thus very welcome :-)
> 
> Hard to say. For the fun of it, try editing conf/config.properties to include:
> 
>    org.osgi.framework.bootdelegation=*
> 
> And see if that has any impact.
> 
> -> richard
> 
>> Kind regards,
>> 
>> Benoît
>> 
>> Le 4 nov. 2010 à 15:26, Richard S. Hall a écrit :
>> 
>>> It appears that Felix treats processor as a required attribute on the native
library, so you have to specify "processor=FOO" on the end of your Bundle-NativeLibrary header.
I added "processor=x86" and got it to resolve on my Mac, but ended up getting errors when
I started it:
>>> 
>>> Caused by: java.lang.UnsatisfiedLinkError: /Users/rickhall/Projects/felix-trunk/main/felix-cache/bundle5/version1.1/bundle.jar-lib/0/vtk/osx64b/libvtkproj4.jnilib:
 no suitable image found.  Did find:  /Users/rickhall/Projects/felix-trunk/main/felix-cache/bundle5/version1.1/bundle.jar-lib/0/vtk/osx64b/libvtkproj4.jnilib:
mach-o, but wrong architecture
>>> 
>>> Not sure if processor should be required, but it seems like a good idea.
>>> 
>>> ->  richard
>>> 
>>> 
>>> On 11/4/10 10:00, Thiébault Benoît wrote:
>>>> Hi everyone,
>>>> 
>>>> I am currently working on creating an OSGi bundle embedding VTK, the Visualization
ToolKit (http://www.vtk.org), written in C++, on Mac OS X.
>>>> 
>>>> I have written an article about my adventures and the related issues I have
encountered so far: http://dev.artenum.com/blog/ben/posts/osgi_vtk_and_macosx
>>>> 
>>>> The short story is that by default, the compilation configuration of VTK
does not create and link properly the dynamic libraries on Mac OS X. I thus had to modify
3 things:
>>>> 	• change the .dylib extensions to .jnilib
>>>> 	• prepend the @loader_path prefix to the library transitive dependencies
>>>> 	• remove the version numbers from the library file names and dependencies.
>>>> 
>>>> This way, I managed to execute the bundle without an UnsatisfiedLinkError
with Equinox. I however have a new problem, that seems much more complex to me.
>>>> 
>>>> When the bundle starts, it creates a "vtkPanel", which extends the AWT Canvas.
The rendering on the panel is then performed by a native method call that crashes.
>>>> 
>>>>> WARNING in native
>>>>>  method: JNI call made with exception pending
>>>>> 	at vtk.vtkPanel.RenderCreate(Native Method)
>>>>> 	at vtk.vtkPanel.Render(vtkPanel.java:166)
>>>>> 	- locked<1060ffa88>   (a vtk.vtkPanel)
>>>>> 	at vtk.vtkPanel.paint(vtkPanel.java:189)
>>>>> 	at sun.awt.RepaintArea.paintComponent(RepaintArea.java:276)
>>>>> 	at sun.awt.RepaintArea.paint(RepaintArea.java:241)
>>>>> 	at apple.awt.ComponentModel.handleEvent(ComponentModel.java:263)
>>>>> 	at java.awt.Component.dispatchEventImpl(Component.java:4790)
>>>>> 	at java.awt.Component.dispatchEvent(Component.java:4544)
>>>>> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:635)
>>>>> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
>>>>> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
>>>>> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
>>>>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
>>>>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
>>>>> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>>>> FATAL ERROR in
>>>>> native
>>>>>  method: Bad global or local ref passed to JNI
>>>>> 	at vtk.vtkPanel.RenderCreate(Native Method)
>>>>> 	at vtk.vtkPanel.Render(vtkPanel.java:166)
>>>>> 	- locked<1060ffa88>   (a vtk.vtkPanel)
>>>>> 	at vtk.vtkPanel.paint(vtkPanel.java:189)
>>>>> 	at sun.awt.RepaintArea.paintComponent(RepaintArea.java:276)
>>>>> 	at sun.awt.RepaintArea.paint(RepaintArea.java:241)
>>>>> 	at apple.awt.ComponentModel.handleEvent(ComponentModel.java:263)
>>>>> 	at java.awt.Component.dispatchEventImpl(Component.java:4790)
>>>>> 	at java.awt.Component.dispatchEvent(Component.java:4544)
>>>>> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:635)
>>>>> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
>>>>> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
>>>>> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
>>>>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
>>>>> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
>>>>> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>>>> Invalid memory access of location 0x0 rip=0x1010af1f4
>>>>> ./ben.sh: line 11: 23453 Abort trap              java -Xcheck:jni -jar
org.eclipse.osgi_3.6.0.v20100517.jar -console
>>>> This native method crashes when calling the jawt.h method GetDrawingSurfaceInfo(ds),
and I have no idea where it may come from.
>>>> 
>>>> The pure Java (no OSGi) application works fine, so I thought it could be
Equinox-related. This is why I tried to load the same bundle in Felix.
>>>> But here I have a new error message:
>>>> 
>>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle test-osgi-vtk
[5]: No matching native libraries found.
>>>> ... and nothing more (even with log level at 4).
>>>> How can I know what does not work?
>>>> What did I do that is Equinox-compatible and Felix-incompatible? I don't
recall using specific Manifest entries...
>>>> 
>>>> Project source code can be downloaded here: http://dev.artenum.com/blog/ben/download/test-osgi-vtk_zip?action=download&nodecorator
>>>> 
>>>> Kind regards,
>>>> 
>>>> Benoît
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message