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

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. 

http://eclipsesource.com/blogs/2010/10/28/running-rap-on-virgo

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.

Regards,
  florian

PS: I created Bug 328986 - Add vsh deploy subcommand to Virgo Kernel 



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>

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev