On 11/4/10 11:58, Richard S. Hall wrote:
On 11/4/10 11:45, Richard S. Hall wrote:
On 11/4/10 11:21, Thiébault Benoît wrote:
Thanks Richard !
Can I say I love you?
(blush) Thank 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?
Bundle class loaders only make java.* packages from the boot class
path available to bundles by default. The normal Java class loader
makes everything available by default. Setting this property to *
makes a bundle class loader behave like a normal Java class loader
(which isn't very modular).
Regarding the processor, I indeed have a Core2Duo proc, which is
64bits. The VTK version I compiled is 64bits as well.
Using boot delegation is generally bad practice. If you can help me
get a version of this bundle that works on my machine, then I can try
to see if I can get this to work properly without boot delegation.
Strange thing, though, my processor is a Intel Core 2 Duo too, it
says, so I'm not sure why it doesn't work.
Ok, I got it to work by starting Java like this:
java -d64 -jar bin/felix.jar
It looks like the bundle is being asked for apple.awt.ComponentModel, so
it is sufficient to do:
org.osgi.framework.bootdelegation=apple.*
Which is better than boot delegating everything. However, I will try to
look into it a little further to see if I can get it to work without
boot delegation at all.
-> richard
-> richard
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
