On 11/4/10 15:54, Thiébault Benoît wrote:
Le 4 nov. 2010 à 17:23, Richard S. Hall a écrit :
On 11/4/10 12:14, Thiébault Benoît wrote:
I tried to add an apple.* in the Import-Package tag, but it does not work.
To do this, you'd need to configure the system bundle to export the packages
you need, e.g.:
org.osgi.framework.system.packages.extra=apple.awt
Then your bundle could import it.
I tried it and it worked.
This makes however my config.properties file platform dependent, isn't it?
I guess that if I use the "org.osgi.framework.bootdelegation=apple.*" on Linux, it will
not care, but if I use "org.osgi.framework.system.packages.extra=apple.awt" Felix might
complain that it does not find the package, isn't it?
Anyway, that would have make my bundle OSX-dependent which is not the idea in
the end (I want a multi-platform bundle, using fragments... next step of my
work)
You could make the import optional, I suppose, but that really wouldn't help in
this situation. If you create a fragment, then the fragment could import
apple.awt.
And what is your opinion about this way to proceed
("org.osgi.framework.system.packages.extra=apple.awt" in fragment). Do you
think it is the best approach?
Yes, this is probably the best way. And you could also use a system
bundle fragment that simple has "Export-Package: apple.awt" in its
metadata (it doesn't actually need to contain it), then you can deploy
this to an OSGi framework running on a Mac to make the system bundle
automatically export the package without having to modify the
system.packages.extra configuration property.
It is somewhat ugly, but it is better to be explicit so that people know
what is actually required rather than hiding it.
-> richard
-> richard
Benoît
Le 4 nov. 2010 à 17:06, Richard S. Hall a écrit :
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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
