On 8 Nov 2012, at 19:54, Bill Shannon wrote:
> 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.
I think the problem comes when we try to support a CDI notion (e.g. stereotypes, alternatives) when CDI is not enabled in an application. Were we to restrict the scope of the extension to these concepts to just being available when CDI is available, I think we will have a lot more success.
So IOW if you put @Alternative on a class with a resource definition and CDI is not enabled, we work as today. If you put it on the class when CDI is enabled, then the alternative is applied.
I think this is going to be a better path to explore - and I think it's achievable.
>
> 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;
>>
>> @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_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;
>>>
>>> @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_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 | Twitter | LinkedIn | Paris JUG | Devoxx France
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>