Sorry for the delayed response. I didn't get notification from JIRA for some reason.
In the presence of a module system, it is possible to have more than one provider configured in the system. See the scenario below where we see the problem:
Each jar is a module (say OSGi bundle).
m1.jar depends on BV_1.0.jar
m2.jar depends on BV_1.1.jar
TCL have both BV_1.0.jar and BV_2.0.jar
m2.jar calls BV.getValidator() or the equivalent factory method.
Since m2.jar depends on BV_1.1.jar, it uses BV 1.1 API. BV uses TCL while using ServiceLoader to find a provider. ServiceLoader upon finding META-INF/services of BV_1.0.jar, tries to load it and throws a ServiceConfigurationError since the loaded class does not implement the interface requested by user. ServiceLoader actually allows it to be used to try the next available provider. Check the documentation of java.util.ServiceLoader.iterator(). Instead of trying the next available provider, BV returns immediately. It does not attempt to recover from situations where it can. That's the bug IMO. If you want to call it an RFE, I am fine too as long as you address it.
Can you tell me why you think trying the next provider is actually a bad thing? What would have gone wrong in such a case?
Thanks,
Sahoo
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Sorry for the delayed response. I didn't get notification from JIRA for some reason.
In the presence of a module system, it is possible to have more than one provider configured in the system. See the scenario below where we see the problem:
Each jar is a module (say OSGi bundle).
m1.jar depends on BV_1.0.jar
m2.jar depends on BV_1.1.jar
TCL have both BV_1.0.jar and BV_2.0.jar
m2.jar calls BV.getValidator() or the equivalent factory method.
Since m2.jar depends on BV_1.1.jar, it uses BV 1.1 API. BV uses TCL while using ServiceLoader to find a provider. ServiceLoader upon finding META-INF/services of BV_1.0.jar, tries to load it and throws a ServiceConfigurationError since the loaded class does not implement the interface requested by user. ServiceLoader actually allows it to be used to try the next available provider. Check the documentation of java.util.ServiceLoader.iterator(). Instead of trying the next available provider, BV returns immediately. It does not attempt to recover from situations where it can. That's the bug IMO. If you want to call it an RFE, I am fine too as long as you address it.
Can you tell me why you think trying the next provider is actually a bad thing? What would have gone wrong in such a case?
Thanks,
Sahoo