Thanks Jeremy.
On 1/8/13 10:03 AM, Jeremy Bauer wrote:
> Thanks, Marina.
>
> Regarding 3). The new wording is much better. Using the Local or
> Remote annotation **with an empty value* *on an interface of the bean
> class would provide more clarity, but maybe this is/can be assumed
> since a value should not be provided?
Yes. This is what I thought.
>
> A few more minor comments -
>
> 4) Section 5.4.6, pg131 - The compatibility note indicates that the
> MDC is available via dependency injection, but makes no mention that
> the context could also be looked up via java:comp/EJBContext.
Hmmm... It is the same as in the corresponding section of the session
beans and 4.3.2Dependency Injection. And java:comp/EJBContext is
mentioned only in its own section currently.
If you feel that the spec needs to mention the lookup in all 3 places
(and any other that you can think of), please file a JIRA.
>
> 5) Section 11.5.1.1 pg259 - bullet 3, "Stateles annotation" (missing
> an s)
Thanks.
>
> 6) pg356 - the formatting of the the doc in the header in the xsd is a
> bit off
Will try to fix - this is how the file was imported by the framemaker.
Thanks again for the review.
-marina
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Cc: Jeremy Bauer/Rochester/IBM_at_IBMUS
> Date: 01/07/2013 09:43 PM
> Subject: [ejb-spec users] [jsr345-experts] Re: Re: Public Draft doc
> candidates uploaded to the project area for review
> ------------------------------------------------------------------------
>
>
>
> Hi Jeremy,
>
> Thanks for reviewing the spec.
>
> On 1/7/13 12:50 PM, Jeremy Bauer wrote:
> Hi Marina,
>
> No comments on the optional doc. Had a few comments on core pd4 thus
> far. I'm still reading through the core updates so I may have a more
> comments. If so, I'll get them to you by tomorrow AM.
>
> 1) The text in 4.6.1 was updated to state that an SFSB can be removed
> when CDI context ends. It would also be useful to update the Figure 5
> (Life Cycle of a Stateful Session Bean Instance).
>
> Good point. There is not much space available, but I can add "or CDI
> context destroyed" in-between "Remove method/or timeout" lines.
>
>
> 2) The footnote [27] on p90 is the only use of the term "failover" in
> the spec. I assume it means what we think it means, but it seems out
> of place to use the terminology without introducing it. I would say
> either the footnote should be removed, or a section should be
> introduced to explain the meaning of the term (and state that it's not
> required, and that configuration is beyond the scope of the spec), and
> then the footnote should say something like "If the container supports
> failover, disabling passivation of a stateful session bean might
> prevent that functionality from working.". Also, the current text
> also has a typo: "that is failover" -> "that if failover".
>
> Thanks. This was a request from an internal Java EE architecture
> review. I'll follow up on it.
>
> 3) In section 4.7, I think would be clearer with the following
> clarifications :
>
> * The bean class must implement the interface or the interface must
> be designated as a local or remote business interface of the bean
> by means of the Local or Remote annotation or in the deployment
> descriptor. The following rules apply:
> o The following interfaces are excluded when determining whether
> the bean class has business interfaces: java.io.Serializable;
> java.io.Externalizable; any of the interfaces defined by the
> javax.ejb package.
> o If a bean class has more than one interface—excluding the
> interfaces listed above—and at least one interface of the bean
> class is explicitly designated as a business interface of the
> bean by means of the Local or Remote annotation **with a
> non-empty value**on the bean class or **the Local or Remote
> annotations with an empty value on an* *interface **on
> implements clause of the bean class* *or in the deployment
> descriptor, or if the bean exposes a no-interface view, all
> business interfaces must be explicitly designated as such.
>
>
> How about this for the 2nd bullet:
>
>
> If a bean class has more than one interface—excluding the interfaces
> listed above—*all* business interfaces must be explicitly designated
> as such if any of the following is true:
> * the bean exposes a no-interface view
> * *any* interface of the bean class is explicitly designated as a
> business interface of the bean by either of the following means:
> * the Local or Remote annotation with a non-empty value on the
> bean class
> * the Local or Remote annotation on an interface of the bean class
> * in the deployment descriptor
>
>
> thanks,
> -marina
>
> * Otherwise:
> o If the bean class is annotated with the Remote annotation
> **with an empty value**, all such interfaces are assumed to be
> remote business interfaces of the bean.
> o If the bean class is annotated with the Local annotation
> **with an empty value**, or if the bean class is annotated
> with neither the Local nor the Remote annotation, all such
> interfaces are assumed to be local business interfaces of the
> bean.
>
>
> Even with that, the second bullet is quite dense, and it's not
> entirely clear whether class-level @Local/_at_Remote with non-empty value
> (or a business-local/remote in XML) should prevent the implements
> clause from being searched or not, or whether or not empty class-level
> @Local should override or conflict with interface-level @Local/_at_Remote.
>
> -Jeremy
>
>
>
> From: Marina Vatkina _<marina.vatkina_at_oracle.com>_
> <mailto:marina.vatkina_at_oracle.com>
> To: _jsr345-experts_at_ejb-spec.java.net_
> <mailto:jsr345-experts_at_ejb-spec.java.net>,
> Date: 01/07/2013 02:13 PM
> Subject: [ejb-spec users] [jsr345-experts] Re: Public Draft doc
> candidates uploaded to the project area for review
> ------------------------------------------------------------------------
>
>
>
> Experts,
>
> If I don't hear otherwise, I'll push the specs to the JCP by the COB
> tomorrow.
>
> -marina
>
> On 12/28/12 6:47 PM, Marina Vatkina wrote:
> > Experts,
> >
> > Please review ASAP so that I can submit the docs to the JCP on-time.
> > I'll upload the javadoc when I figure out why it's not being built in
> > my workspace.
> >
> > *Core document:
> >
> _http://java.net/projects/ejb-spec/downloads/download/ejb-3_2-core-pd-4.pdf*_
> >
> > Major changes since pd-3 (the complete list is in A.5, the change-bars
> > reflect changes since EDR):
> > - Removed restrictions on javax.ejb.Timer and javax.ejb.TimerHandle
> > access (and removed restriction on cancelling timers returned by
> > getAllTimers method)
> > - EJBContainer class now implements the java.lang.AutoCloseable
> interface
> > - Added references to the CDI spec and rules on constructors and
> > removal of the CDI-enabled beans
> > - Removed requirements for the container provider to publish the
> > java:comp/uniqueMDBName name (it will be a new API in the Connector
> spec)
> > - Updated XML Schema definition to the latest version
> > - Restored references to entity beans in Ch 10, 11, and 12 as
> > separating the rules added an unnecessary complexity (see changes to
> > the Optional Doc). Added footnotes that component contract and client
> > view of entity beans are described in the EJB Optional Features
> document.
> >
> > *Optional document:
> >
> _http://java.net/projects/ejb-spec/downloads/download/ejb-3_2-optional-prd-candidate.pdf*_
> >
> > Major changes since EDR (the complete list is in A.3, the change-bars
> > reflect changes since EDR):
> > - Replaced section numbers with the section titles when referencing
> > EJB Core Contracts and Requirements document.
> > - Removed text from Ch 9 and 10 that was exactly the same as in the
> > EJB Core Contracts and Requirements document.
> > - Removed most of the text from Ch 11 as it was an unnecessary
> > duplication of the corresponding chapter in the EJB Core Contracts and
> > Requirements document. Left only section “Mapping Objects Returned by
> > Entity Bean Finder Methods to IDL”
> > - Removed completely chapters “Enterprise Bean Environment” and
> > “Security Management” as it was an unnecessary duplication of the
> > corresponding chapters in the EJB Core Contracts and Requirements
> > document.
> >
> > Have a Happy New Year!
> > -marina
>
>
>