Reza,
I'm still working on notes from today's meeting. I believe the idea is that
CDI will own the definition of the scope, but the behavior will be tied to
the underlying impl (in this case, I'm not sure who would own that part.
Rick Hightower seems to be the owner).
I did research my original issue with this, that came up with implementing
CDI capabilities for JCR. Taking @RequestScoped as an example, you don't
have access to an injection point from within a producer method. I'm not
sure if there is a portable way to modify the injection point to support
this. This was also an issue with the earlier versions of Seam JMS, since
the first versions of weld allowed this to happen, but it didn't work right.
John
On Tue, Sep 6, 2011 at 6:38 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> John,
>
> That's definitely good news. @TransactionScoped has far broader
> implications than just JMS. We should definitely double-check on the actual
> priority/progress of this though. It does seem contrary to the opinion
> expressed here: http://java.net/projects/ejb-**spec/lists/jsr345-experts/*
> *archive/2011-06/message/22<http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2011-06/message/22>.
> It would be interesting to see how they tackle the issue of transaction
> manager look-up non-portability...
>
> I doubt a generic @TransactionScoped would suffice for the purposes of JMS
> 2 though (with or without producers/disposers). For example, in order to
> maintain JMS object inter-dependencies, you'd still have to ensure that
> related objects are created/destroyed in the correct order (with object
> destruction order being the real tricky part). In order to ensure that, what
> is really needed is a custom scope that binds objects to the transaction and
> is aware of the hierarchy/relationships between the objects in the
> transactional context I think.
>
> I really think the best bet for us is to define the scope/features that we
> really need for JMS 2 and see how well that fits (or does not fit) into
> standard scopes/features defined in CDI/EJB (as long as things are generally
> congruent).
>
> That being said, if you can think of a solution to these issues by sticking
> strictly to CDI standard scopes/producers+disposers, that would definitely
> be a good thing. Similarly, we should explore (ideally via a quick and dirty
> prototype) if it is best to use qualifiers vs. plain annotations. If
> qualifiers inhibit usability in this case, perhaps it is best to forgo them?
>
> Look forward to chatting more on Monday...
>
> Cheers,
> Reza
>
>
> On 9/6/2011 3:33 PM, John D. Ament wrote:
>
>> Nigel, Reza,
>>
>> As a follow up to today's call, I can confirm that it is currently
>> proposed to add a TransactionScope to the CDI spec.
>> https://issues.jboss.org/**browse/CDI-121<https://issues.jboss.org/browse/CDI-121>
>>
>> John
>>
>