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.
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 :)
Have a nice weekend.
Sent from my iPhone
On Oct 21, 2011, at 7:39 PM, Reza Rahman <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
Version: 2012.0.1831 / Virus Database: 2092/4565 - Release Date: 10/21/11