ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: deployment, cache and startlevels
Date Wed, 15 Jul 2009 15:18:33 GMT
On Wed, Jul 15, 2009 at 5:15 PM, Bram de
Kruijff<> wrote:
> Marcel wrote:
>> The OSGi spec states that bundles and their states are persisted and
>> restored when starting up again, so cleaning the cache is something
>> you should not normally do. It is used more often during development,
>> because then you often try to launch a framework with bundles that
>> might still have serious bugs in them, causing updates to fail, etc.
>> In a production environment I would say you don't need to clear the
>> cache on every launch.
> I was afraid you were going to say that :P As I recall we were experiencing
> some strange wiring issues a long time ago. These were 'resolved' by
> clearing the cache at startup. I guess we kind of kept it once it was in
> place also because with many updates the bundlecache has a nasty habbit
> of getting very(!) big with lots of bundle versions that just sit there
> doing nothing sensible. Maybe I don't want a clean but rather a garbage
> collector :)

The framework will clean-up the versions on refresh and on restarts.
So all you have to do is to do refreshs at the right moments (which
the deployment admin will do for you if you use ace).



>> DA and start levels are separate concepts. One thing you could do is
>> to actually provide some kind of "configuration information" that
>> determines the start levels of the bundles. That configuration
>> information could then be deployed as part of the same deployment
>> package and sent to a bundle that translates this information into
>> instructions for the start level service. We did not implement such a
>> thing yet, but that should not be hard.
> Aha! Thanks for clearing that up :) I guess that should be done using
> a Resource Processor of some sort? If I feel lucky later on this week
> I'll have a look at this.
> Regards,
> Bram

Karl Pauls

View raw message