[
https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211892#comment-13211892
]
Marcel Offermans commented on FELIX-3329:
-----------------------------------------
1) I totally agree this can and should be improved and created a separate issue
for it: FELIX-3357
2) The patch looks good. I'll further review and apply it.
3) Let me start by stating that the primary goal of this project (autoconf) is
to implement the Auto Configuration Specification (115) in the compendium.
In Amdatu there is a plugin for File Install that tries to emulate a deployment
session so it can re-use this bundle to install configurations, but as
discussed in http://jira.amdatu.org/jira/browse/AMDATU-558 there are mismatches
between what File Install does and what Deployment Admin does. I don't think
it's fair though to state that via a File Install extension, this has now also
become a use case of this project when the goal of that extension was to
emulate a deployment session.
> The fundamental issue with discarding updates at the end of a
> deployment session if rather arbitrary. It covers the use case in the
> description of this issue where DeploymentAdmin stops the
> ConfigurationAdmin bundle during deployment, then starts it again AND
> it synchronously registers its service during start. If for whatever
> reason the ConfigurationAdmin is deferred asynchronously this
> mechanism will fail in a non deterministic way. It couples bundles
> and service lifecycle and places requirements on the implementation
> of the ConfigurationAdmin bundle.
To set the record straight, the use case in the description of this issue is
all about the problem of the initial deployment, where you start out with an
empty system and have a deployment package that contains an implementation of
Configuration Admin, this resource processor and some configuration resources.
That is a use case that is simply not covered by the spec, as discussed
previously here:
http://www.mail-archive.com/[email protected]/msg01934.html
> Previously the AutoConfResourceProcessor would simply throw a
> ResourceProcessorException when no ConfigurationAdmin was available
> which, as explained in this issue, has severe limitations.
If Configuration Admin already was available because it was somehow already
deployed outside of the deployment package, there is no problem. Same goes for
a scenario where it was already installed via an earlier deployment package
(depending on the setting of the optional flag to not stop all bundles in a
deployment package while doing the update). So this is really about the initial
deployment.
The question remains, how long should we defer configuration?
> Thus deferring IMHO is a good option changing the
> AutoConfResourceProcessor contract from "yes, the configuration is
> valid and I have delivered the it" to "yes, the configuration is
> valid and I will deliver it when the (appropriate) ConfigurationAdmin
> shows up". To be honest I am not sure this is within the intent of
> the specification which specifies the processor must create/delete
> configurations in the commit(), but as we have use cases for this
> behavior I am inclined to support defer when needed.
Deferring the delivery is clearly beyond the spec.
However, we only defer if there is no Configuration Admin available. If there
is, the delivery will happing synchronously in the commit.
> Thus, my concern is about the "before the end of the deployment
> session" part. Effectively the contract is now "yes, the
> configuration is valid and I will deliver the configuration when the
> (appropriate) ConfigurationAdmin shows up before the end of the
> deployment session OR ELSE I WILL SILENTLY DROP THEM".
The spec dictates we cannot deliver the configurations before the commit.
The spec also dictates that commit cannot fail, so in case Configuration Admin
is not around at commit time, there is no other option but to silently fail.
114.8 step 14 even states (about exceptions during commit) that "Any exceptions
should be logged as warnings, but must be ignored.".
> Why and why
> not defer indefinitely? It is true that deferring longer does not
> guarantee delivery, but as long as AutoConfResourceProcessor honors
> its contract maintaining configuration update order I think it's much
> more robust. You can hardly blame AutoConfResourceProcessor for a
> ConfigurationAdmin not showing up.
> Concluding, IMHO defer is a good option but it should not be limited
> to deployment session lifetime because that is not very robust and
> does not cover use cases that exceed the deployment session.
> Obviously, to support that AutoConfResourceProcessor would also have
> to persist its state to survive restarts itself.
Deferring updates indefinitely does not work in for example the following
scenario:
We start from scratch and install "dp-1" (depoyment package version 1) with the
following content:
{confadmin-1, autoconf-1, someconf-1}
So far so good. But now we have an update called "dp-2" with:
{confadmin-2, autoconf-1, someconf-2}
Now we get into trouble, because confadmin is updated to version 2, which means
the service briefly goes away. Our configuration from the first deployment
package (someconf-1) will be delivered indefinitely, so it will be delivered
*again* when dp-2 is installed. In fact, it will be hard to predict the order
of delivery of someconf-1 and someconf-2 in this scenario.
So indefinitely is too long, as it would effectively let sessions overlap. At
least we should limit it to the time until the next session starts. But even
that from a design point of view is weird. Why allow updates to go on beyond
the end of the session?
The only downside is that the first time that Configuration Admin starts (as
part of the initial deployment) the configuration won't be delivered if CA
asynchronously publishes its service. The Felix implementation we use does it
synchronously, so it will work.
> Allow the autoconf resource processor to defer the setting of the
> configuration until ConfigurationAdmin is available
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3329
> URL: https://issues.apache.org/jira/browse/FELIX-3329
> Project: Felix
> Issue Type: Task
> Reporter: Marcel Offermans
> Assignee: Marcel Offermans
> Attachments: FELIX-3329_ResourceDeleteNPE.patch
>
>
> Right now, autoconf will always fail if you start out with an empty container
> and install a deployment package with all your bundles, including
> configuration data and ConfigurationAdmin, because at the time it tries to
> find the ConfigurationAdmin service, that won't be started yet. A solution
> would be to (in that case) defer setting the configuration until the service
> becomes available. The downside of this is that we never know for sure if
> this will work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
