Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 48135 invoked from network); 29 Jan 2008 10:44:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Jan 2008 10:44:55 -0000 Received: (qmail 84814 invoked by uid 500); 29 Jan 2008 10:44:45 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 84793 invoked by uid 500); 29 Jan 2008 10:44:45 -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 84784 invoked by uid 99); 29 Jan 2008 10:44:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2008 02:44:45 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2008 10:44:26 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D311C714159 for ; Tue, 29 Jan 2008 02:44:33 -0800 (PST) Message-ID: <18677135.1201603473861.JavaMail.jira@brutus> Date: Tue, 29 Jan 2008 02:44:33 -0800 (PST) From: "Nektarios K. Papadopoulos (JIRA)" To: dev@felix.apache.org Subject: [jira] Created: (FELIX-473) ClassCastException in org.apache.felix.shell ShellServiceImpl getCommandReference MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org ClassCastException in org.apache.felix.shell ShellServiceImpl getCommandReference --------------------------------------------------------------------------------- Key: FELIX-473 URL: https://issues.apache.org/jira/browse/FELIX-473 Project: Felix Issue Type: Bug Reporter: Nektarios K. Papadopoulos Priority: Minor The implementation is obviously wrong, since m_commandNameMap contains Command object, not ServiceReference ones. The bug is inherited from Oscar, but the resolution would have been cleaner back then, since the ServiceReference was readily available in the (now abandoned) CommandRecord objects the Map used to hold. Nevertheless, the solution is to iterate through the Map.Entry's of the m_commandRefMap entrySet and compare the command names one by one. Apparently no one ever uses this method, so the complexity/performance-penalty of the suggested solution is not an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.