Note that because CDI is not integrated with the deployment process, the
@Resource references in *all* alternatives are processed during deployment,
which probably isn't what you want or expect.
Integrating CDI more fully with the deployment process is something we're
investigating as part of investigating expanded use of @Stereotype.
Unfortunately, it's turning out to be more difficult than we expected. We may
not be able to solve this problem in this release.
Antonio Goncalves wrote on 11/08/2012 03:34 AM:
> 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
> <mailto: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
>> <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>
>
>
>
>
> --
> 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>