[
https://issues.apache.org/jira/browse/FELIX-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620533#action_12620533
]
Felix Meschberger commented on FELIX-584:
-----------------------------------------
Yes, you are right there was a difference between the Equinox and Felix
implementations: Apache Felix configadmin used to persist _all_ configuration
objects immediately upon creation regardless of whether it was obtained by
getConfiguration or by createFactoryConfiguration. Equinox on the other hand
only persist configuration objects obtained from getConfiguration immediately.
After clarifying this difference on the OSGi developers list [1], I have
created an issue here as FELIX-612. This changes the Apache Felix configadmin
behaviour to only persist the configuration created by
createFactoryConfiguration when update with properties is called. The fix for
FELIX-612 will be contained in the forth-coming configadmin 1.0.4 release.
Hope this helps.
[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00189.html
> org.apache.felix.webconsole.internal.compendium.AjaxConfigManagerAction.applyConfiguration():
> "create" action is not handled properly
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-584
> URL: https://issues.apache.org/jira/browse/FELIX-584
> Project: Felix
> Issue Type: Bug
> Components: Web Console
> Reporter: Dieter Wimberger
> Assignee: Felix Meschberger
> Attachments: AjaxConfigManagerAction.java.diff, FELIX-584-1.png
>
>
> The current revision of the code (662145) creates the configuration, and
> returns true.
> else if ( request.getParameter( "create" ) != null )
> {
> // pid is a factory PID and we have to create a new configuration
> // we should actually also display that one !
> Configuration config = ca.createFactoryConfiguration( pid, null );
> // request.setAttribute(ATTR_REDIRECT_PARAMETERS, "pid=" +
> // config.getPid());
> return true;
> }
> The problem with this approach is the fact that in many cases the
> Configuration instance will not be persisted or available until the update()
> method is used to set new properties.
> Based on the fact that the "create" action may be called already with a
> complete set of properties edited in the form, I would suggest to only
> differentiate between factory "create" and "save" in the way the
> Configuration instance is created. i.e.:
> if ( request.getParameter( "create" ) != null )
> {
> // pid is a factory PID and we have to create a new configuration
> config = ca.createFactoryConfiguration( pid, null );
> } else {
> // pid is managed service, get configuration
> config = ca.getConfiguration( pid, null );
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
