From: <reza_rahman_at_lycos.com>
Date: Thu, 19 Jan 2012 16:01:33 +0000 (GMT)
I can do it. Mind if I lump this together with a request for defaults of JDBC and JavaMail resources as well?
I'll use both the alias and JIRA. As per the new JCP rules, we should be utilizing issue trackers.
It would be great if you created a JIRA issue that I can follow-up on. I think it gives the request more credence.
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