felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3329) Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available
Date Mon, 20 Feb 2012 14:51:34 GMT

    [ 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/osgi-dev@mail.osgi.org/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

        

Mime
View raw message