ServiceLoader should honor vetoed extension implementations
-----------------------------------------------------------
Key: ARQ-320
URL:
https://jira.jboss.org/browse/ARQ-320
Project: Arquillian
Issue Type: Feature Request
Affects Versions: 1.0.0.Alpha4
Reporter: Dan Allen
Fix For: 1.0.0.Beta1
The current ServiceLoader implementation makes it difficult (if not impossible) to extend
an SPI implementation and have it take precedence over an implementation already on the
classpath. In other words, it discourages being able to use an implementation as a library
dependency.
The reason this happens is because the original implementation provides a ServiceLoader
activation file under META-INF/services. This conflicts with the activation file used by
the extended implementation in the case that Arquillian is looking for exactly one
implementation. The only way to work around this at the moment is to copy all of the
classes required by the original implementation into your own project, extend (or modify)
the original implementation class, and package those classes with a service activation
file. In effect, you have removed the original activation file and replaced it with your
own.
Clearly what is missing is a mechanism to veto the original implementation. You know you
which implementation you want and which one you don't want. So, in the activation file
you simply mark the original implementation as vetoed (to reverse the effect of it being
specified as an implementation). An implementation class would be vetoed by prefixing it
with a ! symbol.
!org.jboss.arquillian.container.jbossas.remote_6.JBossASRemoteContainer
com.acme.arquillian.container.jbossas.remote_6.AcmeJBossASRemoteContainer
While this may seem very specific as you are referencing an implementation class,
that's the whole point because your Java code is extending that class. It's about
library reuse, so you don't have to import the entire package just to exclude the
activation file.
Frankly, I feel like this is a critical missing piece in the JDK ServiceLoader model in
general. It's like providing a light switch that only turns on, not off. Or a radio
button with only one option. Once you press it, you can't unpress it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira