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
