On 11/4/10 12:06, Richard S. Hall wrote:
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.
Technically, I think Felix is doing all it can do here, but I'll need to
think about it some more. Basically, it is the vtkPanel.RenderCreate()
native method that causes the apple.awt.ComponentModel class load. The
framework detects that this class is loaded by your bundle, so it
enforces strict visibility.
-> richard
-> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
