On 22/10/2011 01:54, Clebert Suconic wrote:
> Maybe that's a crazy idea. What if we took a totally new approach?
> Why do we still need connections sessions consumers and producers?
>
> What if we only had producers and consumers?
>
> You could maybe have producer extending AbstractSession and have commit, rollback... Etc
>
> The issue with annotations would be gone if we take an approach like that.
Not a crazy idea at all, if we take the decision that we don't need to cater for every possible use case via injection.
If we decided to focus this feature entirely on Java EE we would simplify things significantly:
1. We could combine connection and session, since there is always a 1:1 relationship between the two in Java EE
2. It would remove the need to support creating a producer and a consumer from the same session, since this is only
needed in Java SE when we want both to participate in the same local transaction (see example 13 in that doc).
3. It would avoid the need to support multiple message consumers on the same session, since the only reason I can think
of for needing this is in SE when we want to define separate message listeners for each consumer.
Perhaps its worth continuing the brainstorming on what a Java EE-only API might look like.
When I tried to think of a genuine Java EE use case which required explicit management of the relationships between
injected objects, the only example I could think of was the request/reply example (example 14). We could either decide
that this was not a use case we needed to support, or that we would devise some new API explicitly to support it.
Here are a couple of Java EE possibilities we could explore:
A. Keep all the existing interfaces, but only allow MessageConsumer and MessageProducer and Message objects to be
injected. Don't allow Connections and Sessions to be injected. Leave it to the container to decide whether
producers/consumers use the same session/connection or not.
B. Define completely new, simpler, consumer and producer interfaces which didn't require a connection or producer but
which could be created directly from the connection factory and destination objects. We would then define annotations to
allow them to be injected. (One advantage of completely new interfaces is we could define them to throw unchecked
exceptions rather than JMSException)
I think the important thing when designing either is that we identify the use cases that the new API is deliberately not
attempting to support in order to keep things simple.
>
>
> Consider this a brain storm please. Don't flame me if that's a crazy idea. Especially that I'm writing this in a
> Friday through the iPhone while drinking some wine :)
>
I'm brainstorming as well...
Nigel
> Have a nice weekend.
> Sent from my iPhone
>
> On Oct 21, 2011, at 7:39 PM, Reza Rahman <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> wrote:
>
>> It's a point I made before. If we leave things be on this for JMS 2, it gives projects/products like Seam 3 JMS and
>> Resin room to evolve further to bring about proven/mature solutions that real-world customers use successfully in
>> significant numbers. Currently, Seam 3 JMS is still in beta and Resin has a design and no implementation yet. I think
>> that's the real underlying problem we have rather than any fundamental usability issue with what we need to do.
>>
>>
>> On 10/21/2011 7:48 AM, Nigel Deakin wrote:
>>> On 21/10/2011 03:12, Reza Rahman wrote:
>>>> Not to put too negative of a spin on this, but I don't think it would be terrible for non-standard solutions in
>>>> this problem space to evolve a bit more.
>>>
>>> There are rather too many negatives in that sentence for me to understand what you mean. Can you say a bit more?
>>>
>>> Nigel
>>>
>>>>
>>>> That being said, we should still give this an honest try I think...
>>>>
>>>> On 10/19/2011 7:24 AM, Nigel Deakin wrote:
>>>>> Dear All,
>>>>>
>>>>> It's time for an update on progress on proposals to allow the injection of JMS objects into Java EE and Java SE
>>>>> applications.
>>>>>
>>>>> The last update you had from me on his subject was on 7th September, when I circulated minutes from a call I had
>>>>> with EG members Reza (Rahman) and John (Ament) to discuss John's AtInject proposals which were circulated earlier.
>>>>>
>>>>> Since then Reza, John and I have had one or two further calls and extensive email correspondence. I wrote a new
>>>>> document, based on the ideas in John's, which attempted to define a set of annotations which could be used to
>>>>> inject JMS objects into applications. An updated version of this document is attached to this message. It lists a
>>>>> fairly complete set of possible annotations to inject almost all JMS objects, but it leaves a number of important
>>>>> issues unresolved, and until we can resolve these issues this document is simply a statement of desire rather than
>>>>> a realistic practical proposal.
>>>>>
>>>>> The unresolved issues are listed in the document, but in summary, the main ones are
>>>>> * The relationship between injected objects
>>>>> * Avoiding repetition on annotations
>>>>> * Injected objects cannot be local variables
>>>>> * Scope of injected variables
>>>>> * Java SE support
>>>>>
>>>>> It is important to appreciate that if we can't resolve these issues then we will probably need to abandon the
>>>>> document and start again.
>>>>>
>>>>> When I was at JavaOne earlier this month Reza and I had a meeting with Pete Muir, spec lead for CDI (Contexts and
>>>>> Dependency Injection). He offered to work with us to see whether it would be possible to achieve what we wanted in
>>>>> a reasonably standard manner using CDI - either the existing version or a future version.
>>>>>
>>>>> Since it's been a few weeks since I gave the full expert group (and user list) an update on this, please do feel
>>>>> free to ask questions about the attached document, make comments, or raise issues. Also, if you think you have
>>>>> ideas on how to resolve the unresolved issues please say so!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Nigel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> No virus found in this message.
>>>>> Checked by AVG -www.avg.com
>>>>> Version: 2012.0.1831 / Virus Database: 2092/4562 - Release Date: 10/19/11
>>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>> Version: 2012.0.1831 / Virus Database: 2092/4565 - Release Date: 10/21/11
>>>
>>