Skip to main content

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

  • From: Antonio Goncalves <antonio.goncalves@...>
  • To: "users@..." <users@...>
  • Subject: [javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations
  • Date: Thu, 8 Nov 2012 12:34:58 +0100

Thanks for your clarification about the factory.

Nigel, that's exactly what I'm talking about : a single built-in queue, and a single built-in topic. But I disagree with the idea of being useful just for learning JMS or playing with it. CDI Alternatives will fill the gap. Imagine this code in development :

@Stateless
public class JavaEESender {
    @Inject private JMSContext context;
    @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); } }
}
This uses the default built-in queue, perfect for development and tests. But in production you can have an alternative to the default Queue :
@Alternative
public class JMSResourceProducer {
    @Produces @Resource(name = "jms/MyProductionQueue")
    private Queue inboundQueue;
}
Then, with just a beans.xml you can switch to your production queue without changing the JavaEESender code. A default built-in queue or topic makes life easier at development but is still valuable at production thanks to Alternative. That's why I am in favor of having all the possible defaults in EE (factories, queues, topics, persistence context....)

Antonio 


On Thu, Nov 8, 2012 at 11:59 AM, Nigel Deakin <nigel.deakin@...> wrote:
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;
    @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 @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;
    @Inject private Queue inboundQueue;
    @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@...> 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

* 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@...> 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@...> 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 | TwitterLinkedInParis JUG | Devoxx France






--
Antonio Goncalves
Software architect and Java Champion

Web site | TwitterLinkedInParis JUG | Devoxx France



--
Antonio Goncalves
Software architect and Java Champion

Web site | TwitterLinkedInParis JUG | Devoxx France


[javaee-spec users] [jsr342-experts] Re: Re: custom injection annotations

(continued)

[javaee-spec users] [jsr342-experts] Re: Re: custom injection annotations

Yoon Kyung Koo 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Bill Shannon 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Pete Muir 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Antonio Goncalves 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Werner Keil 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Antonio Goncalves 11/06/2012

[javaee-spec users] [jsr342-experts] Re: custom injection annotations

Werner Keil 11/06/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Nigel Deakin 11/07/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Antonio Goncalves 11/07/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Nigel Deakin 11/08/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Antonio Goncalves 11/08/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Bill Shannon 11/08/2012

[javaee-spec users] Re: [jsr342-experts] Re: custom injection annotations

Pete Muir 11/09/2012
 
 
Close
loading
Please Confirm
Close