I tried to add an apple.* in the Import-Package tag, but it does not work. 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)
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
