If you're interested in a something like Deployment Admin that does allow bundle sharing, take a look at the new Subsystems spec, it's part of the Enterprise R5 release and an implementation with much of the functionality is already available at Apache Aries.
See also my summary here: http://osgithoughts.blogspot.com/2012/06/osgi-enterprise-r5-specifications.html Best regards, David On 14 June 2012 14:11, <[email protected]> wrote: > Hi Jan, > Please, check my inline comments... > Jan Willem Janssen writes: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Hi, >> I've some questions about the (non) sharing options of bundles in the >> deployment admin that is not clearly described in [1]: >> Suppose a bundle is already installed on the system, but not as part >> of a deployment package, e.g., MyLogService v1.0. >> If we would install a deployment package containing another version of >> MyLogService, say, v1.1, is this considered valid? >> If so, then the text of step 6 on page 334 of [1] should be changed as >> it suggests that *any* installed bundle should be upgraded, regardless >> whether it is part of the source package or not. > > That bundle is so called "externally" (outside DeploymentAdmin) installed. > Why do you think that it should be upgraded? > >> >> If not, then the text of the first bullet of step 3 on page 333 of [1] >> should be changed as it suggests that source packages can *only* >> contain bundles that are either not present at all or present in the >> target package, missing the scenario where a bundle is present in the >> system, but not part of *any* deployment package. >> Another question is the (non) sharing of resources; section 114.2.2 of >> [1] clearly suggests that no sharing is allowed between deployment >> packages for *any* resource. For bundles we should check for symbolic >> name and version, but for any other resource this is up to the >> implementation of the customizer, or not? > > Yes, but the resource processor, not the customizer, because of: > " > A sharing violation must be considered an error. The install or update of > the offending Deployment > Package must fail if a resource would be affected by another Deployment > Package. The verification of > this rule is delegated to the Resource Processor services, or the Deployment > Admin service in case of > bundles. > " > ATB, Evgeni > > ---------------------------------------------------------------------------- > ------- > Evgeni Grigorov . Senior Software Engineer/Development Tools > ProSyst Software GmbH > Tel. +359 2 953 05 88 . Fax +359 2 953 26 17 > Mobile +359 895 300 305 > http://www.prosyst.com . [email protected] > ---------------------------------------------------------------------------- > ------- > stay in touch with your product. > ---------------------------------------------------------------------------- > ------- > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
