I didn't propose a static method. I just proposed a factory similar to what Jdbc uses. You use the class loader to load the class and use it non statically. Just like Jdbc.
> On Mar 17, 2015, at 06:19, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
>
> (Note: moving this discussion to jsr368-experts_at_jms-spec.java.net)
>
>> On 16/03/2015 19:46, Clebert Suconic wrote:
>> You would have an interface for that:
>> ;
>> Lets find a better name for such Driver, JMSDriver
>>
>> interface JMSDriver
>> {
>> ConnectionFactory newConnectionFactory(String connectionProperties);
>> }
>>
>> A tool would be able to use
>>
>> JMSDriver dirver = Class.forName("MyProvider");
>>
>> ConnectionFactory factory =
>> driver.newConnectionFactory(connectionString / URI / something we all
>> agree upon);
>>
>> if we found a good a set of standard properties that would work for
>> everybody it would be great. That may be tricky as for instance we
>> support TCP, UDP.. etc.
>>
>> But just having the className and a typed string would be already a
>> big improvement. Right now admin type guys need to write plugins on
>> their admins for Oracle HornetQ Apache... etc...
>
> So if we ignore the issue of URL and/or properties for a moment, the options so far are
>
> 1. Static method on a provider-specific factory class: (Clebert's suggestion)
>
> ConnectionFactory factory = com.oracle.MyProviderDriver.newConnectionFactory(args)
>
> 2. Constructor on a the provider-specific connection factory class:
>
> ConnectionFactory factory = new com.oracle.MyProviderConnectionFactory(args);
>
> 3. No-arg constructor on a provider-specific connection factory class:
>
> ConnectionFactory factory = new com.oracle.MyProviderConnectionFactory();
> factory.setFoo(value); // javabean properties
>
> Option (1) introduces another level of provider-specific factory, but it does allow the provider to choose the connection factory implementation class depending on the specified properties. Do you see that as a requirement?
>
> Nigel
>
>
>