Re: Loading providers from META-INF/services: spec too vague or J2SE 5 bug ?

Simone,

Here's what the provider for the JMXMP protocol from the JSR 160 
Reference Implementation does:

public class ClientProvider implements JMXConnectorProvider {

     public JMXConnector newJMXConnector(JMXServiceURL serviceURL,
                                         Map environment)
             throws IOException {
         if (!serviceURL.getProtocol().equals("jmxmp")) {
             throw new MalformedURLException("Protocol not jmxmp: " +
                                             serviceURL.getProtocol());
         }
         return new JMXMPConnector(serviceURL, environment);
     }
}

If all the providers listed in META-INF/services in your jar follow this 
convention, then the JMXConnectorFactory code will invoke each one's 
newJMXConnector method in turn until one of them has a matching 
protocol.  It will interpret the MalformedURLException from each of the 
previous ones as meaning that it should continue looking.

Does that answer the question?

Regards,
Éamonn McManus   JMX Spec Lead   +33 476 188 352


Bordet, Simone wrote:
> Hi,
> 
> I have implemented the loading of JMXConnector[Server]Provider
> implementations from META-INF/services.
> I have few doubts :)
> 
> MX4J's mx4j-tools.jar has now 7 providers in the files in the
> META-INF/services directory.
> 
> If I try to instantiate the MX4J soap connector in J2SE 5, it happens
> that the first provider listed in
> META-INF/services/javax.management.remote.JMXConnector[Server]Provider
> is returned, no matter if it is really the soap one or not.
> 
> Now, the spec does not say that service providers should follow a naming
> pattern such as:
> 
> <package>.<decoded protocol>.[Client|Server]Provider
> 
> (where <decoded protocol> converts for example "soap+ssl" in
> "soap.ssl").
> It can be any class name.
> 
> Now I think there must be a way to check that the provider found in the
> provider list under META-INF/services is really a provider for the
> chosen protocol, otherwise
> 
> service:jmx:invalid-protocol:///
> 
> cannot be recognized as a non supported protocol.
> 
> A solution would be to specify that the service provider sticks to the
> naming convention; JSR 160 implementations just check that the provider
> class ends with "<decoded protocol>.[Client|Server]Provider before
> trying to instantiate it.
> 
> Another solution, more expensive, is to instantiate the
> JMXConnector[Server] and provide a getAddress() method (not present in
> JMXConnector), to match the protocol.
> 
> I have modified MX4J to follow the naming pattern, but this is something
> that is probably to be clarified by JSR 255.
> 
> Am I missing something, or misunderstood the service provider mechanism
> ?
> 
> Simon
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&opclick
> _______________________________________________
> Mx4j-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mx4j-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click