[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Starting bundles automatically using plans

I think this is working as designed because the HttpService appears to be marked for lazy activation and so it will not transition to ACTIVE and fire the STARTED event until either a class loader occurs from the bundle or the bundle is explicitly started.

The encompassing plans stay in STARTING state until the contents transition to ACTIVE and fired their STARTED events.

I don't understand why the HttpService is marked as lazy, but presumably it is passive and waits until someone "uses" it and causes a class load. Do there therefore need to be a bundle activator in one of the other bundles to trigger that activation?

Regards,
Glyn

On 28 Oct 2010, at 15:26, Florian Waibel wrote:

>> Hmmm. Something's gone wrong it seems. Please paste the event log messages or, equivalently the console and we'll take a look.
> 
> I used a fresh installation to reproduce the STARTING scenario. Same result...the logs capture the following steps
> 
> step 1 - install Virgo Kernel and put bundles and plans into repository/usr
> step 2 - start Virgo Kernel
> step 3 - restart after enabling the OSGi console
> step 4 - manually start HttpService
> step 5 - shutdown
> 
>> You may like to look for exceptions in serviceability/logs/log.log too in case of some serious failure.
> 
> Looks fine to me.
> 
>> grep Exception log.log
> [2010-10-28 15:19:13.618] region-dm-2                  .a.d.i.BlueprintEventPostingOsgiBundleApplicationContextListener  Failed to send event to topic 'org/osgi/service/blueprint/container/DESTROYED'. Exception message: 'The EventAdmin is stopped'. This may be expected during shutdown. Turn on debug logging for more details. 
> [2010-10-28 15:24:44.208] region-dm-2                  .a.d.i.BlueprintEventPostingOsgiBundleApplicationContextListener  Failed to send event to topic 'org/osgi/service/blueprint/container/DESTROYED'. Exception message: 'The EventAdmin is stopped'. This may be expected during shutdown. Turn on debug logging for more details. 
> 
> <serviceability-1.zip><ATT00001..txt><serviceability-2.zip><ATT00002..txt><ATT00003..txt>