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

Hi Florian

Nice blog. I've linked to it from the Virgo home page.

The odd thing about the suggestion of extending the plan syntax to support activate="true" is that Virgo does start HttpService when it deploys the plan (e.g. after it is dropped pickup). That's what gets HttpService into the STARTING state. Then it needs a class load or, it appears, a second start to really start it. So I think the spelling would be activateagain="true", which seems plain wrong to me. Is there another way of rationalising this behaviour?


On 28 Oct 2010, at 22:38, Florian Waibel wrote:

Hi Dmitry, hi Glyn,

thanks for sharing your thoughts and insight here and for investigating the "lazy" HttpService.

I wrote a blog post about running RAP applications on Virgo Kernel.


Your thoughts on the post would be appreciated... :-)

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.

This makes sense to me.
The state STARTING made me think of a bundle in the state STARTING, stuck in its Activator.start() method. But with a plan
marked as atomic="false" this can be a long living and valid state when one of its bundles is marked lazy...o.k. So far so good.

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?

Neither a manual interaction nor a start-the-world-bundle as a possible solution is not the best solution. Most RAP applications currently use the @start notation in the config.ini to kick the HttpService into action.

How about extending the artifact tag like this:

<artifact type="bundle" name="org.eclipse.equinox.http.jetty" version="[2.0.0, 3.0.0)" activate="true" />

That would allow us to start bundles without using the console/shell.


PS: I created Bug 328986<https://bugs.eclipse.org/bugs/show_bug.cgi?id=328986> - Add vsh deploy subcommand to Virgo Kernel


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.


virgo-dev mailing list