Hi Evgeni, About those fixpackages: I'm sorry, I misunderstood. I indeed meant different versions of the same package (so, sharing the same DeploymentPackage-SymbolicName). Summing up, I think we agree about the situation and the solution.
Angelo On Feb 28, 2012, at 8:23 AM, Evgeni Grigorov wrote: > Hi, > > and my inline comments... > > On 27.2.2012 г. 20:25 ч., Angelo van der Sijpt wrote: >> 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? > Ah, about "fix package", I mean that all DP 1, DP2 and DP3 have the same > name. So, the DP update will be triggered and we will get the issue. >> >>>> 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. > :) Ok, I see. > > ATB, Evgeni >> >> 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 >> >> > > > -- > ----------------------------------------------------------------------------------- > 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
