Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 46904 invoked from network); 19 Mar 2010 13:19:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Mar 2010 13:19:51 -0000 Received: (qmail 95865 invoked by uid 500); 19 Mar 2010 13:19:51 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 95814 invoked by uid 500); 19 Mar 2010 13:19:51 -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 95802 invoked by uid 99); 19 Mar 2010 13:19:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Mar 2010 13:19:51 +0000 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; Fri, 19 Mar 2010 13:19:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 791F4234C4B4 for ; Fri, 19 Mar 2010 13:19:27 +0000 (UTC) Message-ID: <60434523.363441269004767495.JavaMail.jira@brutus.apache.org> Date: Fri, 19 Mar 2010 13:19:27 +0000 (UTC) From: "Felix Meschberger (JIRA)" To: dev@felix.apache.org Subject: [jira] Updated: (FELIX-2206) Localization causes a problem in Configuration Printers In-Reply-To: <1026729754.291311268755707418.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/FELIX-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-2206: ------------------------------------- Attachment: FELIX-2206-fmeschbe.patch Here is a patch implementing the idea sketched on the dev list: The ConfigurationRender is now a special plugin known to the OsgiManager. It is created with the ResourceBundleManager such that the english (only english as discussed earlier) ConfigurationPrinter service titles can be generated. This leaves plugin developers the freedom to merge ConfigurationPrinter and Web Console Plugin implementations and to not require reverting to static methods etc. WDYT ? > Localization causes a problem in Configuration Printers > ------------------------------------------------------- > > Key: FELIX-2206 > URL: https://issues.apache.org/jira/browse/FELIX-2206 > Project: Felix > Issue Type: Bug > Components: Web Console > Reporter: Valentin Valchev > Fix For: webconsole-3.0.0 > > Attachments: FELIX-2206-fmeschbe.patch, services_config_printer.patch > > > When Configuration Status is opened, the Bundles and Services tabs are rendered respectively as 'bundles.pluginTitle' and 'services.pluginTitle'. > Unfortunately, the ConfigurationRender cannot access the ResourceBundleManager which is required to translate the titles. > So there are few possibilities: > 1. A dirty hack, when OsgiManager creates the ConfigurationRender calls a method, to *set* the resourceBundleManager. > 2. Make resource bundle manager accessible to all plugins as a request parameter. This will also require to make the ResourceBundleManager class public... or define the following interface in the public API: > interface ResourceBundleManager { > public ResourceBundle getResourceBundle( final Bundle provider, final Locale locale ) > } > 3. Refactor the Bundles & Services plugins, and change the title to respectively %Bundles and %Services. This is another dirty hack but the titles will be shown correctly. > 4. Refactor the Bundles & Services plugins and extract the configuration printer code in a separate class. In this case no localization will be supported for these printers - just like other ones. I want to remind again, that we choose that no localization is required for Configuration Status as the provided information is more for diagnostics and is better to remain not-localized. > So what do you think. Which variant is better? I personally vote for 4. We can make some method static and package private, so they can be reused by both - plugins & printers can reduce the duplicate code to minimum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.