Reza,
Thanks. I have logged
http://java.net/jira/browse/JAVAEE_SPEC-2 .
(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.)
Incidentally, I also logged these issues for EJB 3.2 back in November on behalf of the JMS expert group
http://java.net/jira/browse/EJB_SPEC-41
http://java.net/jira/browse/EJB_SPEC-42
http://java.net/jira/browse/EJB_SPEC-43
http://java.net/jira/browse/EJB_SPEC-44
(These all are dependencies of the corresponding issues in the JMS issue tracker)
Nigel
On 19/01/2012 16:01, reza_rahman_at_lycos.com wrote:
> 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.
>
>
> Jan 18, 2012 05:17:14 AM, jsr343-experts_at_jms-spec.java.net <mailto:jsr343-experts_at_jms-spec.java.net> wrote:
>
> 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
>