I guess for JSR 375 it's too early to tell which requirements will be
implemented in the end, but if Password Aliasing (
https://blogs.oracle.com/theaquarium/entry/jsr_375_java_ee_security) makes
it, then at least passwords should be equally protected here (for 2.1 we
can assume 375 as prerequisite from all we know)
Werner
On Tue, Mar 17, 2015 at 6:06 PM, Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> On 17/03/2015 15:16, Clebert Suconic wrote:
>
>> Why don't we just do what people have been doing with JDBC Driver for 10+
>> years.
>>
>> jdbc.Driver driver = Class.forInstance("class_name").newInstance(); //
>>
>
> The method on Class is forName, not newInstance, and returns an instance
> of Class, not an instance of the driver.
>
> whatever the API here
>> driver.getConnectionFactory();
>>
>> or maybe we could do something new, and have this new class
>> substituting the connection factory?
>>
>
> That is similar to what I was proposing:
>
> javax.jms.ConnectionFactory factory = Class.forName("com.vendor.
> ConnectionFactory").newInstance();
> javax.jms.Connection = factory.createConnection();
>
> which is equivalent to
>
> javax.jms.ConnectionFactory factory = new com.vendor.ConnectionFactory();
> javax.jms.Connection = factory.createConnection();
>
> The former usage has the advantage of avoiding compile-time dependencies
> on the JMS provider, but applications could use either.
>
> This leaves open the question of how you specify properties such as URL,
> user, password etc, which, if we're on the same page so far, would be the
> next thing to consider.
>
> Nigel
>