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

Attachment: 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

Reply via email to