> 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?
On 17/03/2015 14:51, Clebert Suconic wrote:
> I meant something instantiating it...
Sorry, I don't follow. With javax.sql.DriverManager, the application calls a static method on the class, not an instance.
> 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.
OK. But javax.sql.DriverManager is a factory for connections.
JMS *already* has a factory for connections (javax.jms.ConnectionFactory).
So you seem to be proposing a factory for connection factories. I'm trying to understand why this is necessary. As I
mentioned earlier, the main benefit I can see is that allows a given JMS provider to choose the connection factory
implementation class depending on the specified parameters. Is that a requirement?
Nigel