Bugzilla – Full Text Bug Listing
| Summary: | Bundles deployed in pickup directory are order-dependent | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | unknown | Assignee: | Project Inbox <virgo-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | b.kapukaranov, glyn.normington |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 389416 | ||
| Bug Blocks: | |||
|
Description
Alex Blewitt
Note that this may also affect restarts; a user may have copied A and B in the right order initially, but upon restart it may scan them again in a different order. This is an old chestnut [1] and is one of the reasons we introduced plan support. We advise people to avoid dependencies between bundles in pickup for just this reason. However, if they carefully drop the bundles in the right order (assuming there is a right order), then Virgo preserves the order on a warm restart. We advise the use of plans to cover these scenarios with bundles in e.g. repository/usr. We are also looking at extending plans to contain URIs which will also help this kind of scenario - see bug 327538. In general, this kind of sorting/retrying logic may be useful in a development scenario, but it's not something users really want in production. If the dependencies are wrong, they need sorting out properly. I will leave this bug open however because the idea of retrying all the failed bundles in pickup after another bundle arrives in pickup hasn't been considered before and may be a useful configurable mode. [1] https://issuetracker.springsource.com/browse/PLATFORM-7 Flagging as enhancement because this is working as designed. A restart will pick this up, and fill in the missing bits (which is good). Granted, one probably wouldn't want to do this in production, but at the moment there are some problems with productionised deployments. The repositories/usr is only considered when there is a package import. So if you have: Import-Package: com.knownpackage and com.knownpackage is in the repository, then it gets deployed along with it. However, if you have a requirement that is not expressed as an Import-Package dependency (hellooooo DS) then this approach doesn't work. Incidentally, that's one argument for deploying DS as part of the standard base (see other bug report for that though...) The problem is that there are plenty of these extender bundle patterns, where there isn't an Import-Package dependency but there is a requirement for an extender to be present and running. The other example is Gemini JPA; your bundle just has Meta-Persistence: in the header, with no other dependencies. So Virgo won't know to deploy a JPA provider, and the bundle/par will just sit there and not have JPA wirings created. I can't deploy the JPA in with the main bundle (refreshing takes out the system, as noted elsewhere) so it needs to be in pickup or repository. But it doesn't get auto-deployed since there's no dependencies. Perhaps what I really need is: * All dependencies in the repository * A plan which lists the bundles (and order) but with 'scope=false' and then drop the plan in the pickup. Is there some good documentation for the plan format? Googling for Virgo plan takes me to project related plans, not runtime plans ... Oh, another case: Gemini DBAccess. There's no (direct) link between the persistence bundle (which depends on a JDBC driver) and the Gemini DB provider. The design point of Virgo is that you configure any necessary infrastructure such as extenders prior to deploying applications which require such infrastructure. Typically, I would recommend adding such infrastructure bundles/plans to the initialArtifacts property in the user region properties file as described in "Configuring the User Region" [1] in the User Guide. Documentation of plans [2] is in the Programmer Guide. [1] http://www.eclipse.org/virgo/documentation/virgo-documentation-2.1.0.RELEASE/docs/virgo-user-guide/htmlsingle/virgo-user-guide.html#configuring-kernel [2] http://www.eclipse.org/virgo/documentation/virgo-documentation-2.1.0.RELEASE/docs/virgo-programmer-guide/htmlsingle/virgo-programmer-guide.html#developing-applications-plans Oh I should mention that the OSGi Alliance are exploring mechanisms to express generic requirements and capabilities which would allow the kind of implicit dependencies you describe to be made explicit. This would then, in principle, enable Virgo (suitably modified) to fault in the dependencies like package dependencies. |