(If you want to make other proposals at the same time, that's fine
by me. I think JDBC and JavaMail may be slightly different in that
the Java EE spec doesn't require a database or a mail server to be
built-in to the application server in the way that it requires a JMS
provider to be.)
I
passed this feature request to the Java EE platform spec leads
some time ago. Would anyone here on the Java EE EG like
to pursue it?
(I didn't log this in the Java EE issue tracker (http://java.net/jira/browse/JAVAEE_SPEC)
as it has only one issue in it
which suggests it isn't being actively used.)
As I understand it, JMS support in Java EE requires support for
JTA (XA) transactions (there are CTS tests which fail if
they don't, for example there's one which sends a message in a
UserTransaction, rolls back the UserTransaction, and
checks that a message is redelivered). So I think any connection
factory required by Java EE would need to support JTA
transactions.
(I do know that some vendors do allow "Java SE-style"
connections to be used in a resource adapter, even though this
seems to violate EJB spec section 13.3.5 "use of JMS APIs in
Transactions" and would probably not pass CTS. I think our
separate discussions on the behaviour of createSession() for http://java.net/jira/browse/JMS_SPEC-45
need to cater for
this case.)
Nigel
On 17/01/2012 20:49, Rüdiger zu Dohna wrote:
> +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