felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thiébault Benoît <...@artenum.com>
Subject Re: VTK OSGi bundle and Felix
Date Thu, 04 Nov 2010 19:54:01 GMT

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?

> 
> -> 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-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message