Reza,
I would refer to section 5.5.7 of JSR-299 which only refers to the
InjectionPoint metadata object as being available for @Dependent beans.
This is not a bug.
John
On Wed, Sep 7, 2011 at 12:02 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> John,
>
> FYI, for most of our CDI based work in Resin, we found CDI producers fine
> for the end user, but very limiting for the purposes of a Java EE product
> vendor. That's why we pretty much don't use it at all and for the most part
> use CanDI internal APIs or the portable extensions SPI. Starting to write a
> possible GlassFish RI for this, personally I would not look at CDI producers
> for too long. For example, I think they are too simplistic even to implement
> a JPA entity manager proxy, let alone EJB-like features.
>
> That being said, can you please elaborate the issue of not having access to
> the injection point for a producer method (spec wise, this is supposed to
> work fine)? Can you give me a specific code example? Is this just a Weld bug
> or something in the spec? For one thing, we could get it fixed in the CDI
> spec and/or Weld. Generally, the CDI 1.1/Weld lead has been very responsive.
>
> Cheers,
> Reza
>
>
>
> On 9/6/2011 7:55 PM, John D. Ament wrote:
>
> 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.
>> 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
>>>
>>> John
>>>
>>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3867 - Release Date: 08/30/11
> Internal Virus Database is out of date.
>
>
>