geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Donald Woods (JIRA)" <>
Subject [jira] Commented: (GERONIMO-5178) Inconsistent handling of META-INF/services files by different Geronmo specs.
Date Wed, 10 Mar 2010 16:35:27 GMT


Donald Woods commented on GERONIMO-5178:

Rick, please ping me before changing the jpa_2.0_spec code, as we've had some long discussions
about how this should be handled over in OpenJPA (we currently allow multiple providers to
be specified as allowed by the Java ServiceLoader spec) and have some legacy behaviors we
need to support (like allowing users to override the provider via properties.)  There are
also some tie-ins with Apache Aries JPA support and we need the Spec API to continue support
for Java SE 5 users and not rely on any Java SE 6 only APIs/behaviors.

> Inconsistent handling of META-INF/services files by different Geronmo specs. 
> -----------------------------------------------------------------------------
>                 Key: GERONIMO-5178
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      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
> # A set of provider classes for the blah.blah interface
>  # The default first one 
>  # 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
> - 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.

View raw message