+1
I think this default connection factory would have to support distributed transactions, as that's the behavior the client would expect.
On 2011-12-14, at 00:52, Reza Rahman wrote:
> It's a good idea.
>
> On 12/8/2011 11:32 AM, Nigel Deakin wrote:
>> The following issue was raised by community member "arjan tijms"
>> http://java.net/jira/browse/JMS_SPEC-63
>>
>> S/he writes:
>> ---------------------------------------------
>> In a Java EE environment a JMS provider is mandatory present and can
>> be used without the user having to configure or setup anything.
>>
>> Some implementations (e.g. JBoss AS), provide by default a JMS
>> connection factory for this platform provided JMS provider
>> ({{java:/ConnectionFactory}} and {{java:JmsXA}}), yet in other
>> implementations (e.g. GlassFish) users have to create a connection
>> factory themselves.
>>
>> I would like to propose to formally introduce the concept of a
>> _platform default JMS connection factory_ and make this available
>> under some portable JNDI name (e.g. {{java:/JmsConnectionFactory}}).
>> The exact configuration of this factory should be an implementation
>> detail, but the spirit of the specification should be that it must not
>> be purposely crippled and should be principally intended for
>> production use.
>>
>> Besides shielding users from having to create a connection factory, an
>> additional benefit might be that other platform JMS facilities that
>> otherwise would need an explicit reference to a connection factory,
>> could default to this standard connection factory.
>> ---------------------------------------------
>>
>> I think this is a good idea. In addition to simplifying deployment it
>> might also make it useful in conjunction with the proposed simplified
>> API, since it would make it easier to define default behaviour when
>> MessagingContext objects were injected.
>>
>> (I think both Ruediger and John suggested this as well)
>>
>> Any comments? This would probably need to be put into the Java EE
>> platform spec, so I'll ask what the Java EE spec leads think as well.
>>
>> Nigel
>>
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1873 / Virus Database: 2102/4674 - Release Date: 12/11/11
>>
>>
>