Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 2219 invoked from network); 19 Mar 2010 03:01:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Mar 2010 03:01:50 -0000 Received: (qmail 82034 invoked by uid 500); 19 Mar 2010 03:01:49 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 81866 invoked by uid 500); 19 Mar 2010 03:01:49 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 81859 invoked by uid 99); 19 Mar 2010 03:01:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Mar 2010 03:01:48 +0000 X-ASF-Spam-Status: No, hits=-1063.8 required=10.0 tests=ALL_TRUSTED,AWL 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 03:01:47 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id BA99B234C4AF for ; Fri, 19 Mar 2010 03:01:27 +0000 (UTC) Message-ID: <659793978.356311268967687763.JavaMail.jira@brutus.apache.org> Date: Fri, 19 Mar 2010 03:01:27 +0000 (UTC) From: "Donald Woods (JIRA)" To: dev@geronimo.apache.org Subject: [jira] Commented: (GERONIMO-5178) Inconsistent handling of META-INF/services files by different Geronmo specs. In-Reply-To: <1002464328.176531268227407116.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/GERONIMO-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847212#action_12847212 ] Donald Woods commented on GERONIMO-5178: ---------------------------------------- General question on discovering Providers. In the JPA2 spec api, we now have something like - try { // add each one to our list List serviceProviders = ProviderLocator.getServices(PersistenceProvider.class.getName(), this.getClass(), cl); for (Object o : serviceProviders) { providers.add((PersistenceProvider)o); } } catch (ClassNotFoundException e) { . . . Since multiple providers can be listed in one services file, should the failure/exception to load one cause none of them to be returned? Should we silently eat or log the exceptions and just return null if we fail to load any of the configured providers? > Inconsistent handling of META-INF/services files by different Geronmo specs. > ----------------------------------------------------------------------------- > > Key: GERONIMO-5178 > URL: https://issues.apache.org/jira/browse/GERONIMO-5178 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Affects Versions: 3.0 > Reporter: Rick McGuire > Assignee: Rick McGuire > Fix For: 3.0 > > > A number of the Geronimo specs use the provider resolution pattern defined by the ServiceLoader class in Java 6 to resolve different provider classes. In this pattern, a file with a given class name in the META-INF/services directory can define one or more provider classes for a given source interface name. As implemented by the ServiceLoader class, these files can contain multiple lines with pure comment lines and line comments on lines that define classes, as well as multiple providers defined per file. Thus a file like this would be considered valiid: > # A set of provider classes for the blah.blah interface > org.apache.geronimo.foo.BlahImpl # The default first one > org.apache.geronimo.bar.BlahImpl # The secondary fall back. > The different spec projects that use these files parse them under different assumptions: > - Some unilaterally take the first line without any comment processing at all or recognition that there might be multiple providers defined per file. > - Some projects allow for pure comment lines but don't parse for comments on a definition line. > - Not all projects are opening these files assuming a utf-8 encoding. > This could best be solved by refactoring the code to use some common methods. This refactoring will also allow OSGi-awareness to be added to the service file lookups. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.