I meant something instantiating it...
but really I'm just proposing to do whatever javax.sql is doing. I
remember you would get an instance of the driver and you would call
the method on that instance.
So you would need an empty constructor.
The advantage I see is for people writing generic tools. It's actually
the role of the guy who asked me about this.. he's writing tooling to
configure ConnectionFactories for external VMs on a generic faction.
having this standardized would help those kind of tools
On Tue, Mar 17, 2015 at 10:29 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> On 17/03/2015 12:21, Clebert wrote:
>>
>> 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.
>>
>
> You proposed
>
>>>> JMSDriver dirver = Class.forName("MyProvider");
>>>> ConnectionFactory factory = driver.newConnectionFactory(connectionString
>>>> / URI / something we all agree upon);
>
>
> which means newConnectionFactory has to be a static method.
>
> All the methods on javax.sql.DriverManager are static.
>
> I'm not saying this is a bad thing, but I'd like to understand why we need
> to introduce another level of provider-specific factory. The main benefit I
> can see is that allows the provider to choose the connection factory
> implementation class depending on the specified properties. Is that a
> requirement?
>
> Nigel
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com