Hi, See inline.
On Feb 27, 2012, at 5:56 PM, Evgeni Grigorov wrote: > Hello Angelo, > > On 27.2.2012 г. 12:29 ч., Angelo van der Sijpt wrote: >> Hello Evgeni, >> >> Deployment packages 2 and 3 can be fix packages, but that isn't significant >> in this case, the situation outlined will happen based on what is in the >> deployment package's manifest. > It's important! The deployment package customizer must never process > resources from another deployment package. Still, I don't see the difference: a fix package allows you to not include resources and bundles that have not changed with relation to some previous deployment package (they are marked as Missing in that case). Am I missing something? >> >> When you say 'stale deployment package customizers should be uninstalled >> after the commit of the resource processors', do you mean that this behavior >> is implied in the spec, or the spec should be updated for it? > From my point of, that is missing in the specification and should be fixed. I'll open a bugzilla issue for this. >> >> To be clear, I agree with your idea that we should have a second stage of >> removing stale bundles (especially for customizer bundles) after the commit. >> This would be an additional step between steps 14 and 15 in 114.8, so >> _before_ the refreshPackages. > Just to clarify, you mean between 15(commit) and 16(refresh package) i.e. > just after commit and before refresh packages. Are we talking about the same specification? I am referring to the 4.2 compendium specification, since 4.3 isn't out yet. In 4.2, step 14 is the commit. Angelo > > ATB, Evgeni >> >> Thanks again, >> >> Angelo >> >> >> On Feb 27, 2012, at 9:05 AM, Evgeni Grigorov wrote: >> >>> Hi Angelo, >>> >>> You can find my inline comments below... >>> >>> On 26.2.2012 г. 16:24 ч., Angelo van der Sijpt wrote: >>>> 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. >>> Just to clarify, Deployment package 2 and 3 are fix packages for Deployment >>> package 1, right? >>>> >>>> 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? >>> It looks like a specification deviation. The stale deployment package >>> customizers should be uninstalled after the commit of the resource >>> processors. >>> >>> ATB, Evgeni >>>> Thanks, >>>> >>>> Angelo >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>> >>> -- >>> ----------------------------------------------------------------------------------- >>> 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 >> >> > > > -- > ----------------------------------------------------------------------------------- > 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
