felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OSGi application deployment and Felix auto-deploy problem
Date Sat, 10 Sep 2011 19:07:16 GMT
On 9/10/11 2:51 PM, thiebault@artenum.com wrote:
> I tried that (added Bundle-ActivationPolicy: lazy in the manifest file of the org-test-view3d-linux64b-0.0.1.jar
bundle), but I still get the UnsatisfiedLinkError. Changing the bundle name fixes it.

Sorry, yes, the issue is that the lazy activation will only help if the 
first bundle is lazily started before the other. So, it won't help in 
this situation, since it is not being started beforehand.

I'm trying to think of another way to accomplish the same thing, but I 
can't think of any good way off the top of my head. This type of 
dependency is not directly modeled in OSGi and it likely requires the 
code to be packaged differently to work well in an OSGi environment.

You are going to either have to use start levels or model the dependency 
as a service dependency. For the latter, you could have your one bundle 
provide a "ready" service and have your second bundle wait until it sees 
the "ready" service.

Another option is to combine the bundles into one bundle.

-> richard

p.s. Keep in mind that renaming the bundle is not a good option, since 
ordering by name isn't guaranteed. The only form of ordering control 
provided by OSGi is start levels.

>
> Kind regards
>
> Le sam 10/09/11 16:45, "Richard S. Hall" heavy@ungoverned.org a écrit:
>>
>> On 9/10/11 10:22 AM, thiebau
>> lt@artenum.com wrote:
>> Thank you Richard for your answer.
>>>
>>> Let me explain a bit further the way both bundle
>> work.
>>
>>> The first bundle,
>> org-test-view3d-platform-0.0.1.jar, embeds the VTK library in the form
>> of:
>> - native dynamic library files (.so, .jnilib or .dll
>> depending on the platform)
>> - a jar file containing the Java wrapping of
>> VTK
>>
>>> The bundle exports the Java classes of the Jar, but
>> does not provide any service in the sense of OSGi.
>>
>>> In the bundle activator of this bundle, I load in a
>> static block all the libraries required by VTK to work, as explained here,
>> section 2)b): http://dev.artenum.com/blog/ben/posts/osgi_vtk_and_linux
>>> In classic Java, I just need to load the top-level
>> library, but in OSGi, it is required to load all of them, one by one, so
>> that the framework can extract the dynamic library files from the
>> bundle.
>>
>>> Then, I have the second bundle, org-sample-view3d.
>> This is the one that is cross-platform and implements the business logic.
>> In this test bundle, I create a vtkPanel, which is a JPanel containing the
>> VTK 3D view.
>> The vtkPanel class is located in the jar exported by
>> the first bundle. This is why the second bundle imports vtk from the first
>> one. But when I create a vtkPanel, the class contained in the Java wrapping
>> loads the top-
>> level native library of VTK (System.loadLibrary). I
>> can't do anything about it, it's not my code and I use it as a third party
>> component.
>>
>>> Thus, if the first bundle has been started, all low
>> level dynamic libraries are already loaded and everything works like a
>> charm. If the first has not been started however, the load library call of
>> the top-level library
>> performed in the second bundle fails.
>>> I don't want to call the loadLibrary method in the
>> second bundle as the second bundle is supposed to be reused for each
>> platform, while the first one is platform specific (the name and the number
>> of libraries to load
>> vary from one platform to another).
>>
>> So apparently doing it in a static block of the activator of the first
>>
> bundle is too late unless you make your first bundle use lazy
>> activation, which will cause the framework to start its activator the
>> first time the other bundle loads any class from it.
>>
>> ->  richard
>>
>>> Ben
>>>
>>>
>>> Le sam 10/09/11 15:12, "Richard S. Hall" heavy@un
>> governed.org a écrit:
>>> On 9/10/11 5:49 AM, thiebau
>>>> lt@artenum.com
>>   wrote:
>>> Hi everyone,
>>>>> I am currently developing an OSGi
>> desktop
>>> application and I would like some advice and/or
>> feedback on the release
>>> process that I put in place.
>>>>> The project is a multi-modules Maven
>> project, where
>>> each modules generates an OSGi bundle (with BND
>> and for some bundles
>>> iPOJO).
>>>>> In addition, I have an Ant script
>> controlling Maven
>>> with Maven Ant Tasks and I have a special
>> release target that automatically
>>> performs the following actions:
>>>>> 1) It first calls "mvn install" that
>> generates the
>>> bundle in each target directory of the
>> modules
>>> 2) It creates a "release" directory named after
>> the
>>> SVN revision number and 4 sub-directories:
>> linux32b, linux64b, osx64b and
>>> win32b
>>>> 3) It unzips Felix framework in each of the
>> release
>>> directories (its a light version of Felix, with
>> only the OBR bundle in the
>>> "bundle" directory)
>>>> 4) It copies all modules bundles in the
>> "bundle"
>>> directory of the Felix framework. I have some of
>> my bundles using native
>>> code (for 3d visualisation for instance). They
>> are named
>>> my-bundle-platform-version.jar,
>>>> where platform takes the values linux32b,
>> linux64b,
>>> osx64b and win32b. The Ant script thus only
>> copies the bundle for the
>>> required platform in each directory
>>>> 5) It copies the execution scripts (.sh
>> for
>>> Linux/OSX, .bat for Windows) for each platform
>> in each directory
>>> (ultimately, I will have .exe and .app
>> respectively for Windows and Mac,
>>> but one step at a time)
>>>> 6) I can then zip (manually or with Ant)
>> each
>>> release directory and distribute them to my
>> users depending on their
>>> platform.
>>>>> My questions are the following:
>>>>>
>>>>> A) My first problem is with the automatic
>> bundle
>>> deployment from Felix.
>>>>> In a first attempt, I only deployed two
>> bundles that
>>> are (for example for Linux 64 bits)
>> :
>>> - org-test-sample-view3d-0.0.1.jar
>>>>> -
>> org-test-view3d-linux64b-0.0.1.jar
>>>>> org-test-sample-view3d-0.0.1.jar imports the
>> Java
>>> wrapping of the native library while
>> org-test-view3d-linux64b-0.0.1.jar
>>> exports it (and calls the System.loadLibrary
>> method in its
>>> BundleActivator).
>>>>> The problem is that when Felix is launched,
>> it
>>> installs and starts the bundle
>> org-test-sample-view3d-0.0.1.jar first,
>>> resulting in an UnsatisfiedLinkError. When I
>> rename
>>> org-test-sample-view3d-0.0.1.jar to
>> org-test-
>>> xsample-view3d-0.0.1.jar, then Felix installs
>> and
>>> starts org-test-view3d-linux64b-0.0.1.jar first
>> and everything works
>>> perfectly.
>>>>> Is this normal behavior (starting jars
>> in
>>> alphabetical order)? Do I really have to play
>> with start levels? I thought
>>> OSGi would be smart enough to launch first the
>> bundles providing the
>>> function and then the one
>>>> requiring it.
>>>>
>>>> The order is whatever order returned by
>> File.listFiles(), I would guess.
>>> The bundles are not installed and started one at a
>> time, they are all
>>> installed, then all started. This ensures that
>> any code-level
>>> dependencies (i.e., Import-Package) will be
>> satisfied properly. This
>>> doesn't help service-level dependencies, which
>> have to be handled by the
>>> bundles themselves (or something like
>> iPOJO).
>>> If you are not getting a resolve exception, then
>> your code-level
>>> dependencies are properly satisfied. Just a
>> guess, are you doing your
>>> load library in your activator start() method?
>> If so, perhaps you should
>>> try to do it in a static block instead or else make
>> the bundle lazily
>>> activated so it will be started automatically on
>> first class load.
>>>> ->   richard
>>>>
>>>>> B) The whole process is a bit rigid. I know
>> I could
>>> have performed all the Ant actions with Maven
>> assembly plugin, but it is
>>> less flexible than Ant (regarding naming and
>> positioning of the output and
>>> SVN revision
>>>> checking) and slower (I tried both
>> in
>>> fact).
>>>>> The problem is at step 4): sometimes, I just
>> want to
>>> deploy a certain number of bundles (says, the 3d
>> visualization ones) and
>>> sometimes only the 2d visualization for
>> instance. This smells a lot like
>>> configuring
>>>> different OBR to me, but I'm not sure to know
>> how.
>>> Is there a way to automate this with Ant (or
>> Maven)?
>>>>> Kind regards
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: u
>>>> se
>> rs-help@felix.apache.org
>>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: u
>>>> se
>> rs-help@felix.apache.org
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: u
>> sers-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: u
>> sers-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