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:36:02 GMT
On 9/10/11 3:24 PM, thiebault@artenum.com wrote:
> I was thinking that maybe just putting the bundles in Felix bundle repository is not
the best way to deploy my application. Maybe I could create an OBR repository file that would
describe what bundles to deploy. OBR
> supports start level, isn't it? I have not looked too much at OBR right now but will
try to dig deeper this aspect of OSGi.

OBR doesn't deal with start levels...in general start levels shouldn't 
be used unless there is no other way around it.

>
> I read the part of your book (OSGi in Action) regarding start levels very quickly, but
it seems the start level has to be set outside of the bundle? Like a config file for Felix
or a bundle agent? In other words, can a
> bundle define its own start level?

No, bundles don't set their own start levels. And generally, it is not a 
good idea, since a bundle doesn't really know what kind of environment 
it will be deployed into, so it cannot really guess how start levels are 
being employed...that is the job of the deployer and/or the management 
agent.

You could create your own management agent that understands something 
about your start level needs. Your management agent could use OBR to 
calculate transitive dependencies, but handle the actual deployment 
itself or could make a separate pass after OBR deployment to set start 
levels according to your app's needs.

>
> Combining both bundles is not a solution: what I want is to reuse the one containing
the native libraries with other bundles than the sample one. One of the most tedious tasks
with OSGi is to create bundles with
> native code, so I want to prevent other developers to do it and just develop whatever
business logic they want on top of my native bundle.
>
> The service approach would work but would put some more constraints on the developers
of the bundles using the first one. But I will think about it too.

This is probably the only way to explicitly capture the dependency and 
is better because you cannot always control the start levels your 
bundles are in...maybe someone has other suggestions.

-> richard

>
> Thanks for your answer anyway, they are very useful.
>
> Kind regards
>
> Le sam 10/09/11 21:07, "Richard S. Hall" heavy@ungoverned.org a écrit:
>
>> 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@un
>> governed.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-h
>> elp@felix.apache.org
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: u
>>>>>> se
>>>> rs-h
>> elp@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
>>>> 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