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
> <mailto: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 <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3867 - Release Date: 08/30/11
> Internal Virus Database is out of date.
>