Antonio,
Perhaps the name "default connection factory" is misleading. It's not so much a default connection factory as a built-in
connection factory, which may be used by any Java EE application to connect to the application server's built-in JMS
provider. A large proportion (probably the majority) of JMS applications in Java EE use the built-in JMS provider so
this is intended to be a genuinely useful feature for real applications.
I may be misunderstanding your comment, but are you asking for a JMS provider to have a single built-in queue, and a
single built-in topic? This might be something which the novice developer could use when making their first tentative
experiments to learn JMS. However this would be of no use for anything more than a throw-away training exercise, since
the moment you deployed more than one application their messages would start getting mixed up. I think that's too
narrow a use case to be worth attempting to require as a standard feature.
Nigel
On 07/11/2012 16:07, Antonio Goncalves wrote:
> Nigel, sorry if this has already been debated in the JMS 2.0 EG, but why can't we also have a default Queue and a
> default Topic ? In development phase I would love to write something like this :
>
> @Stateless
> public class JavaEESender {
> @Inject private JMSContext context;
> *_at_Inject private Queue inboundQueue;*
>
> public void sendMessage(String msg) {
> try {
> context.createProducer().send(inboundQueue, msg);
> } catch (JMSRuntimeException ex){
> Logger.getLogger(getClass().getName()).log(Level.SEVERE, null, ex);
> }
> }
> }
> I know_at_JMSDestinationDefinition exists, but I like the idea of being able to go even further with the defaults (the beauty of programming by exception). Something like this should be doable :
>
> @Stateless
> public class JavaEESender {
> @Inject private JMSContext context;
> *_at_Inject private Queue inboundQueue;*
> *_at_Inject private PersistenceContext em;*
>
> public void sendMessage(String msg) {
> try {
> context.createProducer().send(inboundQueue, msg);
> *em.persist*(new MyEntity(msg));
> } catch (JMSRuntimeException ex){
> Logger.getLogger(getClass().getName()).log(Level.SEVERE, null, ex);
> }
> }
> }
> Antonio
>
>
> On Wed, Nov 7, 2012 at 12:27 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> On 06/11/2012 18:32, Werner Keil wrote:
>> Things like "Mobile JMS" certainly could benefit even the newly revived ME/Embedded side, e.g. for M2M specific
>> Messaging protocols, or my old Agorava (JSR 357) idea of using JMS to send Social Messages like Twitter
>>
>> However, if CDI is becoming more portable and usable by SE with 2.0, maybe JMS 2.0 should also try to open itself
>> up, but I am not sure, if that's gonna happen with its 2.0 release yet
>
> In JMS 2.0 we've specified
> @Inject private JMSContext context;
> as a required feature in a Java EE container only.
>
> This is @TransactionScoped if there's a JTA transaction, @RequestScoped if not.
>
> JMS 2.0 does not require this to be supported in a Java SE environment. Not does it define how it might work in
> Java SE (I see finding an appropriate scope to use in Java SE as the main issue).
>
> Nigel
>
>
>> Cheers,
>>
>> --
>>
>> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead| Java Godfather
>>
>> Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
>>
>> Skype werner.keil | Google+ gplus.to/wernerkeil <http://gplus.to/wernerkeil>
>>
>> * DevoXX: November 13 2012, Antwerp, Belgium. Werner Keil, JCP EC Member and Agorava Committer, will present
>> "Java Social JSR, it's alive"
>>
>> * Eclipse DemoCamp: November 21 2012, Copenhagen, Denmark. Werner Keil, Eclipse UOMo Lead and Mærsk Build Manager
>> will present "Eclipse M2M and Standards for the IoT"
>>
>> * Eclipse DemoCamp: November 26 2012, Berlin, Germany. Werner Keil, Eclipse UOMo Lead and Mærsk Build Manager
>> will present "Eclipse M2M and Standards for the IoT"
>>
>> * Eclipse DemoCamp: November 30 2012, Vienna, Austria. Werner Keil, Eclipse UOMo Lead and Mærsk Build Manager
>> will present "Triple-E class Continuous Delivery with Hudson, Maven, Kokki and PyDev"
>>
>> On Tue, Nov 6, 2012 at 7:27 PM, Antonio Goncalves <antonio.goncalves_at_gmail.com
>> <mailto:antonio.goncalves_at_gmail.com>> wrote:
>>
>> SE support would help all those JSRs that don't want to rely on CDI (embedded in a EE container) such as JMS.
>>
>>
>> On Tue, Nov 6, 2012 at 7:23 PM, Werner Keil <werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>> wrote:
>>
>> Well, if it's SE support it may not hurt EE as much, if there was a way to get this or 330 into SE 8 (at
>> least in some "Profile") it would be phantastic, knowing, the SE 8 "bag" has almost closed, and most of
>> these useful additions may require the Jigsaw mess sorted out with Java 9 first
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>
>>
>>
>>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>