Bugzilla – Full Text Bug Listing
| Summary: | Re-Installing a PAR with a fragment on system.bundle hangs Virgo | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | unknown | Assignee: | Borislav Kapukaranov <b.kapukaranov> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, glyn.normington |
| Version: | unspecified | ||
| Target Milestone: | 3.0.0.M01 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alex Blewitt
I think it would be better to configure the fragment on the system bundle to be installed during kernel or user region initialisation rather than embedding it in a PAR which is really designed to be a self-contained entity. Perhaps you would like to try this and see if you get good results. The User Guide should provide sufficient guidance, but please come back here if not. However, we should at least fail more gracefully in this case, so thanks for raising the bug and I'll look forward to a slimmed down test case. The problem (in my specific case) is that it's a JPA sample (that isn't using Spring) and the EclipseLink support automatically creates the fragment on the system bundle. Since I'm still grappling with this to work I am not sure if it's my problem with JPA, but you're right, a workaround would be to install JPA stuff in a separate location rather than the application. NB one use case for system bundle fragments I've used in the past is to expose classes available on the boot path. For example, one might have a system bundle fragment that exports the 'sun.misc' package. If someone includes that in a PAR it might be safer not to stop the system bundle but merely uninstall the fragment, though in the general case this may not be possible. I suspect that the refresh packages call to package admin after undeployment is where the kernel shuts down as the transitive dependencies of the undeployed bundles get refreshed, which includes stopping them and restarting them. Hi Alex, Glyn was correct that the refresh packages call to package admin is the root cause - it shuts down the system bundle of the user region. It is done on uninstall of a PAR. Virgo's strategy for PAR re-install or refresh is a basic one - we first uninstall the old one and then install the new one. This basically means that if you have a PAR containing fragment on a system bundle, then you can do almost nothing with it - you can re-install it since it'll shut down the user region, you also can't uninstall it once you've deployed it since it'll again shut down the user region. Basically there are two solutions: 1) somehow disable the refresh for PARs with such fragments - but that won't work so good since it'll leave the system in an incosistent state(possibly very inconsistent, depending on the PAR) until the next restart after the PAR is re-installed/uninstalled. 2) forbid having fragments on system bundles in a PAR - which me and Glyn think is the preferable solution. Note that having only fragments on system bundle will be forbidden, not having fragments at all. I'll start implementing it. But first wanted to see what do you think? I think there's two use-cases for fragments on the System bundle: 1) To add additional packages that get exported by the system bundle (e.g. via an empty Export-Package type of fragment) 2) To add code to the system bundle itself In the latter case, I don't see how you can do that without potentially affecting other users of the system bundle, which might then cause further problems for users down the line. If I have a fragment contributed by PAR A and then I have a PAR B installed, I'll see the results of the fragment attach from A, right? So I think disallowing fragments on the system bundle makes sense, though I could see an argument to let the former through. However, since Virgo naturally exports all of those anyway, I'm not sure it even makes sense to do 1) in the context of a Virgo runtime, since it exports everything. Thanks Alex. Please note that we are proposing to disallow "deploying" (using the Virgo kernel) fragments on the system bundle, but you can still attach such fragments by configuring them on the kernel startup. This makes more sense from an update point of view. Fix pushed. Closing the bug now. closing... |