Thank you Jean-Louis.
Jean-Louis MONTEIRO wrote:
> Hi,
>
> I mainly focused on changes (red change bars).
> 4.3.14 Transaction Context of Session Bean Methods
> --> the first sentence is very long and too difficult to understand.
> Is it possible to rephrase it or to split it?
>
> From 4.3.4, I can read life-cycle methods (PostConstruct for instance)
> of SLSB always execute in an unspecified transaction context. Only
> Singleton and Stateful support transaction attributes (8.6.5
> Unspecified transaction is also mentioned for SLSB)
> Whereas from 4.3.14, it suggests it's possible.
I'll look into it and send the new text for review.
>
> Am I wrong?
>
> 7.1 There is a type iterceptors --> interceptors
thanks.
>
> BTW, there is a typo p23: Davd should be David ;-)
Thanks! It's actually a copy-and-paste error :( (David, can you ask jcp
people to fix your name in the EG list?).
>
> Hope it helps
Of course. Thanks again,
-marina
> Jean-Louis
>
> 2012/1/11 Marina Vatkina <marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>>
>
> Hi Antonio,
>
>
> Antonio Goncalves wrote:
>
> Hi all,
>
> Here are a few comments/questions (mostly about Interceptor
> and Transaction specification) :
>
> * Will interceptors still be inside the EJB spec or will there
> be a seperate spec ? It feels like JPA 1.0 when it was bundled
> with EJBs. Now that interceptors can be applied to managed
> beans, couldn't it be move to the Java EE spec instead of the
> EJB (like the Managed Bean and Transaction support)?
>
>
> There is a note (still marked XXX to be filled in if there is an
> update to the Interceptors spec) under 1.5:
>
> "The Interceptors document defines the contracts and requirements
> for the use and implementation of interceptors. These contracts,
> while required by the core EJB specification, are described in a
> way that is independent of EJB in order to faciliate their use by
> other enterprise Java technologies. Future revisions to the
> Interceptors specification[38] will be undertaken independently of
> EJB [XXX To be confirmed]."
>
> Should I remove the text in []?
>
>
> * Chapter 6 (Persistence) is blank and just refers to the JPA
> specification. Why don't we do the same for interceptors and
> support for transaction ? They could be left "blank" and just
> refer the seperate interceptor and transaction spec.
>
>
> Transactions chapter will probably stay as the new annotations
> will be different, with the ref to the JTA spec, and may be some
> generic text replaced with the pointers to that spec. But the
> interceptors chapter might be a good idea as you are not the first
> one looking for the clarity in this area.
>
> What do others think?
>
> thanks,
> -marina
>
>
> Antonio
>
>
>
> On Tue, Jan 3, 2012 at 21:54, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>
> <mailto:marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>>> wrote:
>
> Happy New Year everybody!
>
> This is a friendly reminder that I'm still waiting for the
> reviews.
>
> Best,
> -marina
>
>
> Marina Vatkina wrote:
>
> Experts,
>
> I uploaded EDR versions of both books of the EJB 3.2 spec.
> Please review the changes before the books go to the
> JCP site
> for an official submission. If you don't have any comments,
> please let me know if you are ok with the EDR in its
> current
> state.
>
> The books have the change bars (the Optional Chapters
> changes
> are very minor) and all the changes are listed in the
> Revision
> History sections.
>
> Other than all the cleanups and clarifications (thank
> you very
> much to everybody who helped with this activity), the
> following had been added to/changed in the spec (the
> corresponding parts of the revision history are
> prepended with
> *New:*) :
>
> * Added asynchronous session bean invocations and
> non-persistent EJB Timer Service support to EJB 3.2 Lite.
> * Removed restriction to obtain the current class loader;
> changed ‘must not’ to ‘should exercises caution’ when using
> the Java I/O package.
> * Added support for the lifecycle callback interceptor
> methods
> of stateful session beans to execute in a transaction
> context
> determined by the bean’s transaction management type
> and any
> applicable transaction attribute.
>
> Have a nice reading!
>
> -marina
>
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org>
>
>