Hi list, After filing the issue, it has been rather quiet on this subject. Anyone else that cares to weigh in on this subject?
Angelo On Feb 28, 2012, at 1:29 PM, Angelo van der Sijpt wrote: > If you would like to keep track: > https://www.osgi.org/bugzilla/show_bug.cgi?id=139 > > Angelo > > ________________________________________ > From: Angelo van der Sijpt > Sent: Sunday, February 26, 2012 3:24 PM > To: OSGi Developer Mail List > Subject: When should ResourceProcessors be uninstalled? > > H list, > > While working on the Apache Felix Deployment Admin, I noticed it is unclear > when resource processors are allowed to be uninstalled. > Figure 114.8 of the Compendium specification suggests that stale bundles have > to be removed _before_ calling commit() on the resource processors'; hence, > we cannot remove customizer bundles that should be removed because they are > no longer part of the current deployment package. So, while it is described > how to _update_ customizer bundles, I can't find anything about removing them. > > > We could choose to not remove them at all, but that, in turn, can lead to the > following situation: > > Deployment package 1 > - contains Resource A > - contains Customizer bundle (version 1) with Resource Processor for A > > Deployment package 2 > - (removed Resource A) > - (removed Customizer bundle with Resource Processor for A) > - ... > > Deployment package 3 > - contains Resource A' > - contains Customizer bundle (version 2) with Resource Processor for A > > Installing these packages in their order means that after deployment package > 2 is installed, we leave the Customizer bundle (in version 1) in the > framework. Installing package 3 now fails, because it tries to update > Customizer bundle to version 2, but doesn't expect the bundle in version 1 to > be in the framework. > > > Any thoughts on this? Does the spec need some clarification or update to > allow a specific moment for removing resource processors? Or am I reading the > spec wrong, and is there a natural solution? > > Thanks, > > Angelo > > > _______________________________________________ > 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
