You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Marcel Offermans (Created) (JIRA)" <ji...@apache.org> on 2012/01/31 11:22:10 UTC
[jira] [Created] (FELIX-3329) Allow the autoconf resource processor
to defer the setting of the configuration until ConfigurationAdmin is
available
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
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
[jira] [Updated] (FELIX-3329) Allow the autoconf resource processor
to defer the setting of the configuration until ConfigurationAdmin is
available
Posted by "Bram de Kruijff (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bram de Kruijff updated FELIX-3329:
-----------------------------------
Attachment: FELIX-3329_ResourceDeleteNPE.patch
> 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
[jira] [Commented] (FELIX-3329) Allow the autoconf resource
processor to defer the setting of the configuration until
ConfigurationAdmin is available
Posted by "Bram de Kruijff (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211547#comment-13211547 ]
Bram de Kruijff commented on FELIX-3329:
----------------------------------------
Hi, Marcel a couple of comments and findings on this code
1) If found the ambiguous use of "resource" throughout the code is rather confusing. First there is the "deployment resources" which are effectively representations of metadata files. Second there are the "autoconf resources" which are effectively representations of designates. So, for example the DropResource and DeleteResource tasks are entirely different beasts. I think some renaming could help future adventurers. I'll use the aforementioned terms throughout this comment.
2) When an existing deployment resource gets updated with a new version prepare() will fail throwing a NPE on the m_configAdmin which will always be null. I think it even tries to delete all previous autoconf resources potentially also deleting the once that were in the update as well. I've attached a patch that should illustrate and fix this issue.
3) You have implemented the defer only to the end of a DeploymentSession. After that all outstanding configuration tasks are simply discarded. This does not cover our Amdatu use case and IMHO has some fundamental issues. Let me eleborate a little on both:
The use case is a Felix Fileinstall Autoconf extension. Whenever fileinstall detects a new file in the deployement directory is calls our artifactinstaller. Our approach is to simply translate such an event into one small deployment session. It only holds one file at a time. Now the deployment of such a configuration file can trigger the registration of a new ConfigurationAdmin. A second configuration file can then be deployed that contains a filter (FELIX-3330) to match the newly created ConfigurationAdmin and via the same route the AutoConfResourceProcessor will deliver it. This works well, but fails when the second configuration file is delivered first. Each deployment translates into a separate session, as the filter wont match the first ConfigurationAdmin and when the deployment session ends AutoConfResourceProcessor will simply discard it. As fileinstall will deliver only one file at a time and there is no defined delivery order the means we can not use it in this way. Either we need to rework the fileinstall in ways I don care to think about right now or we need to defer to extend beyond deployment sessions.
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.
Previously the AutoConfResourceProcessor would simply throw a ResourceProcessorException when no ConfigurationAdmin was available which, as explained in this issue, has severe limitations. 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.
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". 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.
> 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
[jira] [Commented] (FELIX-3329) Allow the autoconf resource
processor to defer the setting of the configuration until
ConfigurationAdmin is available
Posted by "Marcel Offermans (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Assigned] (FELIX-3329) Allow the autoconf resource
processor to defer the setting of the configuration until
ConfigurationAdmin is available
Posted by "Marcel Offermans (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Offermans reassigned FELIX-3329:
---------------------------------------
Assignee: Marcel Offermans
> 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
>
> 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