Hi,
I was wondering what the correct lifecycle of a customizer bundle is in
a deployment admin session. Let's assume a deploymentpackage has been
installed containing a customizer bundle (a resource processor) and one
processed resource. Now this deploymentpackage is updated not to contain
the resource anymore: an empty deployment package. According to the spec
(as I see it) the following should happen (the numbers refer to the
numbering in the spec, chapter 114.8):
4) all target bundles are stopped (in this case, only the customizer bundle)
5) no bundles have to be installed or updated
7) customizer and stale customizer bundles should be started (in this
case, only one stale customizer is started)
8-10) all resources are processed (in this case none)
11) all stale processed resources are dropped (in this case, only the
processed resource that was previously deployed. It will be dropped by
the stale customizer/resource processor we just started)
12) all stale bundles are uninstalled (in this case, only the stale
customizer bundle)
13-14) all resource processors involved are told to prepare and commit
(in this case, the stale customizer should prepare and commit - but we
just uninstalled it?)
This would imply that we should not uninstall stale customizer bundles
in step 12 because we need to call prepare and commit on it to finalize
dropping stale resources. This would mean the customizer/resource
processor is present from the moment it is deployed alongside a
processed resource until the deployment package is uninstalled entirely.
One solution could be: If a resource is present in deploymentpackage N
then the corresponding resource processor/customizer should always be
present in deploymentpackage N+1, even if that does not contain the
resource anymore.
That seems odd to me, any idea's on what the intended use of customizer
bundles is here?
-Christian
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
