Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 84247 invoked from network); 1 Jun 2008 06:01:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2008 06:01:07 -0000 Received: (qmail 29182 invoked by uid 500); 1 Jun 2008 06:01:09 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 29145 invoked by uid 500); 1 Jun 2008 06:01:09 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 29134 invoked by uid 99); 1 Jun 2008 06:01:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 May 2008 23:01:09 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jun 2008 06:00:29 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C7DFB234C126 for ; Sat, 31 May 2008 23:00:45 -0700 (PDT) Message-ID: <567901205.1212300045807.JavaMail.jira@brutus> Date: Sat, 31 May 2008 23:00:45 -0700 (PDT) From: "Dieter Wimberger (JIRA)" To: dev@felix.apache.org Subject: [jira] Updated: (FELIX-584) org.apache.felix.webconsole.internal.compendium.AjaxConfigManagerAction.applyConfiguration(): "create" action is not handled properly In-Reply-To: <1542033043.1212296445379.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/FELIX-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dieter Wimberger updated FELIX-584: ----------------------------------- Attachment: AjaxConfigManagerAction.java.diff Obtained using: svn diff AjaxConfigManagerAction.java > AjaxConfigManagerAction.java.diff > 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 > Attachments: AjaxConfigManagerAction.java.diff > > > 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.