users@javaee-spec.java.net

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

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
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;
    *_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);
        }
    }}

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 {

    *_at_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_at_oracle.com>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;
> *_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 @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>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_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>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>
>
>


-- 
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>





35F.gif
(image/gif attachment: 35F.gif)

329.gif
(image/gif attachment: 329.gif)

347.gif
(image/gif attachment: 347.gif)