[
https://issues.apache.org/jira/browse/FELIX-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dieter Wimberger resolved FELIX-584.
------------------------------------
Resolution: Fixed
The new version resolves the issue.
However, we realized that the Equinox implementation of the configuration admin
behaves differently from the Apache Felix one: the methods that create a new
instance of a Managed Service Factory do not imply that the Configuration
instances "exist" (i.e. they cannot be listed or obtained otherwise if they are
not updated using the instance returned by the methods themselves).
Even though it seems unimportant, as a matter of fact it can make a big
difference for management agents. Thus, it seems as if there is a need to have
a clear statement as to whether the standard specifications (Service
Compendium, 104.7.2) implicitly assume that using one of the two methods "to
create a new instance of a Managed Service Factory" automatically implies that
the created Configuration instance "exists" in the meaning of "existence" as
used in 104.7.3.
> 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.
