On 4/22/10 16:48, Richard S. Hall wrote:

>> and making sure the framework initially starts up to startlevel 1 by
>> specifying:
>>
>> felix.startlevel.framework=1
>>    

> If you are using Felix 2.0.x, then you should use 
> "org.osgi.framework.startlevel.beginning" which is the standard name
for 
> this property starting with OSGi R4.2.

Yes. Unfortunately we are still on Felix 1.6.0. That's another thing we
need to work on, but first we wanted to have our startup sequence in
order. :)


>> I still have one question though:
>>
>> I read in various places that you should never use startlevels to
manage
>> dependencies between services (not applicable for us I think) and
that
>> there is a compatibility option in OSGi that will force all
startlevels
>> of all bundles to 1....

> Not precisely sure to what you are referring, but perhaps if the 
> framework doesn't offer a start level service, then it would treat
them 
> all as being start level 1. You could just have your application fail
if 
> there is no start level service, but typically this should not be the
case.

I was referring to "Compatibility Mode" as described in the OSGi spec.
section 8.3.
http://www.osgi.org/download/r4v41/r4.core.pdf  (page 208)

I have been reading up a bit about it and have come to the conclusion
that 
it's intended for backward compatibility with older OSGi specifications
and 
not applicable for us.

Thanks again to everyone for helping. This was my first interaction with
this 
Mailing list and it has been a very good experience!

-Stijn


> -----Original Message-----
> From: Stijn de Witt [mailto:[email protected]]
> Sent: donderdag 22 april 2010 11:42
> To: [email protected]
> Subject: RE: Prevent specific cached bundle from starting
>
> Ok thanks Karl, going to read up on that right away!
>
> -Stijn
>
>
> -----Original Message-----
> From: Karl Pauls [mailto:[email protected]]
> Sent: donderdag 22 april 2010 11:39
> To: [email protected]
> Subject: Re: Prevent specific cached bundle from starting
>
> Just have a look at the startlevel service. It can do what you want. I
> guess the idea would be something like: start the framework with
> startlevel one. All bundles in startlevel one get started. When the
> bundle in question is done with its work, it uses the startlevel
> service to go to startlevel two. File install will be started in
> startlevel two.
>
> regards,
>
> Karl
>
> On Thu, Apr 22, 2010 at 11:33 AM, Stijn de
Witt<[email protected]>
> wrote:
>    
>> Ok that sounds interesting. I will definitely look into these start
>> levels, thanks!
>>
>> One question though. If we have some time consuming work to do after
>> Felix has started, but before we enter NORMAL mode, wouldn't the File
>> Install bundle still start during that time consuming work? It is
>> important to us that it never starts before we enter NORMAL mode,
even
>> if it might take ten seconds after the last system bundle was
>>      
> installed
>    
>> in INITIALIZE mode before we finally enter NORMAL mode.
>>
>> I am currently looking into uninstalling the File Install bundle when
>>      
> we
>    
>> shutdown, so it will be removed from the cache once we startup again,
>> but the problem I have with that is that I fear it may not be as
>>      
> robust.
>    
>> if the server would stop without going through the shutdown code in
>>      
> the
>    
>> intended manner (crash, power outage etc) the File Install bundle
>>      
> would
>    
>> still be lingering in the cache and cause problems on the next
>>      
> startup.
>    
>> A possible solution would be to set some flag after the shutdown code
>> has finished and check that flag again on startup, clearing the
bundle
>> cache if the shutdown code was not completed correctly. But this all
>> adds to complexity of course.
>>
>> Maybe I could combine both approaches.
>>
>> Is there some way to set a startlevel manually? Something like this:
>>
>> Server.enterNormalMode();
>> Felix.setStartLevel(3);
>>
>> Or perhaps by using the ServiceTracker we could signal the File
>>      
> Install
>    
>> bundle when it's good to go?
>>
>> -Stijn
>>
>>
>> -----Original Message-----
>> From: Karl Pauls [mailto:[email protected]]
>> Sent: donderdag 22 april 2010 11:05
>> To: [email protected]
>> Subject: Re: Prevent specific cached bundle from starting
>>
>> It sounds to me like what you want to do is to look into startlevels.
>> Basically, all your bundles from your INITIALZE mode should be in one
>> startlevel and the file install bundle in a higher level. That way,
>> all your bundles will be started before the file install bundle gets
>> started (and that will be the case for the startup with an exisiting
>> cache as well).
>>
>> regards,
>>
>> Karl
>>
>> On Thu, Apr 22, 2010 at 10:49 AM, Stijn de Witt
>>      
> <[email protected]>
>    
>> wrote:
>>      
>>> Hi all,
>>>
>>>
>>>
>>> I was wondering if it is possible to prevent a specific cached
bundle
>>> from starting when Felix starts?
>>>
>>>
>>>
>>> We have started using OSGi and Felix in our existing product a while
>>>        
>> ago
>>      
>>> but still are coming to grips with it. One thing that we had some
>>> trouble with (and had implemented badly) is the use of the Felix
>>>        
>> bundle
>>      
>>> cache.
>>>
>>> We initially always cleared the bundle cache before starting Felix
>>>        
> and
>    
>>> then had Felix install some system bundles by setting the property
>>> "felix.auto.start.1" to a list of bundles to be started. We then did
>>> some application specific startup logic and only when that was done
>>> would we install the Felix File Install bundle 'manually' with a
call
>>>        
>> to
>>      
>>> BundleContext#installBundle.
>>>
>>>
>>>
>>> Unfortunately this degraded our startup performance. An OSGi expert
>>> pointed out to us that this is not very efficient and that the
bundle
>>> cache is meant to (be able to) survive between shutdown and startup,
>>>        
>> so
>>      
>>> we are now refactoring our code to use this feature. It is here that
>>>        
>> we
>>      
>>> run into the problem.
>>>
>>>
>>>
>>> Basically startup of our server consists of two phases: INITIALIZE
>>>        
>> mode
>>      
>>> and NORMAL mode. During initialize mode the system bundles should be
>>> installed and started and any 'user' bundles that were already
>>>        
>> installed
>>      
>>> and running before the server was stopped should resume. Then, when
>>>        
> we
>    
>>> enter NORMAL mode, the File Install bundle should be installed and
>>> started and monitor the bundle deploy folder for new, changed or
>>>        
>> removed
>>      
>>> user bundles. However, when we start Felix with the File Install
>>>        
>> bundle
>>      
>>> in the cache, that starts right away and immediately begins
>>>        
> installing
>    
>>> 'user' bundles when we are still in INITIALIZE mode, causing havoc.
>>>
>>>
>>>
>>> So what I want is, just before calling Felix.start, remove the File
>>> Install bundle from the cache so we can install it manually after we
>>> entered the NORMAL mode.
>>>
>>>
>>>
>>> Is that possible? Or even the right way to go about it? Or is there
>>>        
>> some
>>      
>>> smarter approach we could take?
>>>
>>> Any advice would be greatly appreciated.
>>>
>>>
>>>
>>> Thanks for a great open source project!
>>>
>>>
>>>
>>> -Stijn
>>>
>>>
>>>
>>>
>>>        
>>
>>
>> --
>> Karl Pauls
>> [email protected]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>      
>
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to