Scratch anything I said earlier.. I was *old* fashioned and sorry
about that. I didn't mean to generate noise.
All I was trying to do was to do whatever JDBC is doing.
I just talked to Wildfly guys.. and the way to do it is through ServiceLoader.
So, we have a trend here about ServiceLoaders... so that would be +1 on that.
On Tue, Mar 17, 2015 at 1:10 PM, John D. Ament <john.d.ament_at_gmail.com> wrote:
> Changing to users again...
>
>
>
> On Tue, Mar 17, 2015 at 10:38 AM Nigel Deakin <nigel.deakin_at_oracle.com>
> wrote:
>>
>> On 17/03/2015 12:31, John D. Ament wrote:
>> > I think using a service loader approach would be the best, and most
>> > consistent option.
>> >
>> > ConnectionFactory cf = JMS.newConnectionFactory(map);
>> >
>> > or
>> >
>> > ConnectionFactory cf = JMS.newConnectionFactory();
>> >
>> > Where JMS is a new class added by the EG, similar to provider classes in
>> > WebSocket, JPA, BeanValidation etc.
>> >
>> > John
>>
>> Who implements the "JMS" class? Does each JMS provider have to supply its
>> own implementation?
>>
>
> The JMS provider implements it. The most common approach is a service
> loader, leveraged by CDI, Bean Val, WebSocket. Less common is a factory
> like EJBContainer. JPA has their own thing entirely based on a custom file
> entry.
>
>>
>> If it is implemented by the JMS provider, how how does the application
>> choose which whose implementation of the "JMS"
>> class it wishes to use, bearing in mind that the same application must be
>> able to use multiple JMS providers?
>>
>
> ServiceLoaders. If you have multiple impls on the path, an option like
> JPA's is possible, or adding a map of options to look for would help.
>
>>
>> If the same implementation is expected to work for each JMS provider, then
>> how does the implementation know how to
>> instantiate a given ConnectionFactory?
>
>
> They're generally no args constructors with init methods.
>
>>
>>
>> Nigel
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com