I did it: I created the system bundle fragment that exports apple.awt. I tried it and it works great. For those interested, I enclose it to my mail Kind regards, Benoît
apple.awt.1.0.0.jar
Description: application/java-archive
Le 4 nov. 2010 à 21:14, Richard S. Hall a écrit : > > > 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org