| Summary: | BundleException causes Virgo startup to fail | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Hristo Iliev <hsiliev> | ||||
| Component: | unknown | Assignee: | 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
Hristo Iliev
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? Created attachment 176244 [details]
BundleException (fragment)
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. 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? 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. 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. This bug has an assignee, so changing status to ASSIGNED. Commit d5d1cbdf9b67a9361525326d13640f4842809e64 will cause Virgo to exit with code 2 if a kernel bundle throws an exception |