[
https://issues.apache.org/jira/browse/DISCOVERY-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017852#comment-13017852
]
Simone Tripodi commented on DISCOVERY-17:
-----------------------------------------
Thanks for your help and hints Joerg, I'm playing with this silly test:
{code}
@Test
public void findImplementationsViaService() {
Enumeration<? extends Log> logImplementations =
Service.providers(Log.class);
while (logImplementations.hasMoreElements()) {
Log log = logImplementations.nextElement();
System.out.println(log);
}
}
{code}
what is print is just
{code}
org.apache.commons.logging.impl.NoOpLog@1b016632
{code}
switching to the proposed implementation instead, behavior looks like more
consistent:
{code}
null
null
org.apache.commons.logging.impl.NoOpLog@78dc6a77
{code}
{{Jdk14Logger}} and {{LogKitLogger}} need a constructor argument to be built;
indeed, modifying the "test" in the following way:
{code}
@Test
public void findImplementationsViaService() {
Enumeration<? extends Log> logImplementations = Service.providers(new
SPInterface<Log>(Log.class,
new Class<?>[]{ String.class },
new Object[]{ getClass().getName() }),
null);
while (logImplementations.hasMoreElements()) {
Log log = logImplementations.nextElement();
System.out.println(log);
}
}
{code}
I got the following output:
{code}
org.apache.commons.logging.impl.Jdk14Logger@d8d9850
org.apache.commons.logging.impl.LogKitLogger@502cb49d
org.apache.commons.logging.impl.NoOpLog@70cb6009
{code}
I would say that there are no more doubts at that point, current implementation
is broken, WDYT? Thanks in advance!
> Enumeration returned by Service.providers has a broken behavior
> ---------------------------------------------------------------
>
> Key: DISCOVERY-17
> URL: https://issues.apache.org/jira/browse/DISCOVERY-17
> Project: Commons Discovery
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Simone Tripodi
> Assignee: Simone Tripodi
> Fix For: 0.5
>
> Attachments: org.apache.commons.logging.Log
>
> Original Estimate: 20m
> Remaining Estimate: 20m
>
> I find the current Enumeration behavior broken, but please tell me if I'm
> wrong!!!
> This is the actual current behavior:
> {code}
> return new Enumeration<S>() {
> private S object = getNextClassInstance();
> public boolean hasMoreElements() {
> return object != null;
> }
> public S nextElement() {
> if (object == null) {
> throw new NoSuchElementException();
> }
> S obj = object;
> object = getNextClassInstance();
> return obj;
> }
> private S getNextClassInstance() {
> while (services.hasNext()) {
> ResourceClass<S> info = services.nextResourceClass();
> try {
> return spi.newInstance(info.loadClass());
> } catch (Exception e) {
> // ignore
> } catch (UnsatisfiedLinkError ule) {
> // ignore
> } catch (ExceptionInInitializerError eiie) {
> // ignore
> }
> }
> return null;
> }
> };
> {code}
> but it should be
> {code}
> return new Enumeration<S>() {
> public boolean hasMoreElements() {
> return services.hasNext();
> }
> public S nextElement() {
> ResourceClass<S> info = services.nextResourceClass();
> try {
> return spi.newInstance(info.loadClass());
> } catch (Exception e) {
> // ignore
> } catch (UnsatisfiedLinkError ule) {
> // ignore
> } catch (ExceptionInInitializerError eiie) {
> // ignore
> }
> return null;
> }
> };
> {code}
> I think there's no need to comment both codes, please tell me why the first
> one should be right :P
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
