Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322132

Summary: BundleException causes Virgo startup to fail
Product: [RT] Virgo Reporter: Hristo Iliev <hsiliev>
Component: unknownAssignee: Hristo Iliev <hsiliev>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: zteve.powell
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 333641    
Bug Blocks:    
Attachments:
Description Flags
BundleException (fragment) none

Description Hristo Iliev CLA 2010-08-09 09:11:09 EDT
Build Identifier: 2.1.0.M02-incubation

During framework start the call stack seems to be:
Thread [main] (Suspended)	
	FrameworkBuilder.installAndStartBundles(BundleContext) line: 162	
	FrameworkBuilder.start() line: 155	
	Launcher.main(String[]) line: 53	

In FrameworkBuilder.installAndStartBundles() method all the bundles described in the org.eclipse.virgo.kernel.launch.properties are installed and then started. If some of the bundles fails to start a BundleException is caught and then rethrown. 

The problem is that this exception is not processed and the current thread is killed. From this point on the Virgo server is in inconsistent state – the kernel region is partially started and there is no user region initialized. The server seems started but is unusable. An example would be a fragment bundle included in the launch.properties file.


Reproducible: Always

Steps to Reproduce:
1. Describe fragment bundle in org.eclipse.virgo.kernel.launch.properties
2. Start Virgo
3. Check the exception and Virgo state
Comment 1 Steve Powell CLA 2010-08-10 05:06:34 EDT
Hristo,
The bundles in launch properties are not >all< started, and there is a fragment in the list already:
   file:lib/kernel/org.eclipse.virgo.kernel.kerneldmfragment-@KERNEL.VERSION@.jar,\
which is not started, you may notice.
The starts are executed synchronously and serially, in the order they appear in the property.

Could you please attach the actual files you used to see this failure.  The launch properties file, and the fragment source, if necessary.  I suspect a simple bundle, started, that throws a BundleException in its Activator would be sufficient.

There does seem to be a problem with failure detection and management here -- could you please explain what you think is an appropriate behaviour at this point?
Comment 2 Hristo Iliev CLA 2010-08-10 11:13:14 EDT
Created attachment 176244 [details]
BundleException (fragment)
Comment 3 Hristo Iliev CLA 2010-08-10 11:49:10 EDT
If start of the fragment present currently in the list is requested the attached exception is logged and Virgo hangs.

In other words adding @start:

file:lib/kernel/org.eclipse.virgo.kernel.kerneldmfragment-@KERNEL.VERSION@.jar@start,\

causes Virgo to hang.


By default Virgo should react to misconfiguration (@start for fragment) or faulty bundles with shutdown - similar to kernel stop. 

Currently the kernel bundles can be customized by the user and such customization will introduce bundles (user's or 3rd party) in the kernel region that may function improperly.

A configurable behaviour therefore seems to me the best solution. The start of the kernel region can continue ignoring the misbehaving bundles. 

In this way the root cause can be identified not only with logs inspection and debugging but also within the OSGi environment with some supportability tools (shell commands/medic/monitoring or management tools...). 

Furthermore the failure of a single bundle (probably 3rd party) will not lead to the stop of the whole application server. Having a running kernel and user region may additionally help to solve the problem since all the needed infrastructure (Virgo or 3rd party) would be running.
Comment 4 Steve Powell CLA 2010-08-23 06:18:25 EDT
Proposal currently under discussion:

*  Introduce 'kernel start' plug-in to control starts in kernel launch list
*  Plug-in specified in kernel properties file
*  Interface: plug-in passed list of  bundles to start, plus parameter string for each bundle
*  Parameter can be 'start' (as today) or 'start@<user-parm>@...'
*  Default behaviour (no plug-in configured) is as today (but ignoring user parms)
*  Mechanism provided for plug-in to start the bundles (synchronously, as present)
*  Abort mechanism to be designed -- e.g. plug-in can throw an exception -- will shutdown.

What do you think?
Comment 5 Hristo Iliev CLA 2010-08-23 12:08:04 EDT
We made some research on how Virgo can be used as embedded server in Eclipse. It turned out that the default launcher is not really needed (except one reference from Virgo kernel) and currently does not provide more than a fixed startup order (at least for embedded scenario).

If Virgo is to be used inside Eclipse the launcher would not be needed. This may make the proposed extensions (actually any extensions) unwanted since their behaviour cannot and should not be reproduced in Eclipse environment.

From this new point of view it would be better to have only the immediate shutdown. The less features there are in the Virgo launcher the easier it is to have Virgo embedded.

If the launcher is used in standalone case only then the proposed extension looks OK, except the part with the synchronous startup. This contradicts with the requirements of the embedded scenario, where the startup should be done in parallel, but this is another story.
Comment 6 Steve Powell CLA 2010-08-24 04:51:47 EDT
It seems that the extension may not be necessary, then.

This bugzilla will concentrate on the problem whereby the kernel hangs (or worse) upon failure during startup, which can be fixed in the present launcher.

Please raise the notion of an embedded server in eclipse as an enhancement bugzilla, should you wish to pursue it.

The suggestion of an extension to launch to allow a plug-in will be raised as a proposed bugzilla enhancement by me.
Comment 7 Glyn Normington CLA 2011-05-16 11:48:45 EDT
This bug has an assignee, so changing status to ASSIGNED.
Comment 8 Hristo Iliev CLA 2011-06-17 08:07:09 EDT
Commit d5d1cbdf9b67a9361525326d13640f4842809e64 will cause Virgo to exit with code 2 if a kernel bundle throws an exception