[
https://issues.apache.org/jira/browse/GERONIMO-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847294#action_12847294
]
Rick McGuire commented on GERONIMO-5178:
----------------------------------------
Unfortunately, there has been no guidance on any of the specifications on how
this should be handled. Most of the spec implementations would fail
immediately if there was a classloading or instantiation failure when
processing any of the META-INF/services files it located, so that's how I ended
up coding the ProviderLocator.getServices() call. We end up with multiple
levels of log points in this whole stack, so I suspect throwing the exception
is the appropriate way to handle this.
> 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.
