The Public Draft documents and the javadoc had been submitted to the JCP
today.
I uploaded the updated version of the Core doc to the java.net spec
downloads. It includes minor edits as compared with the v4, and the
page115 changes described below (note that the changes on that page
include all the bullets). The updated version of the Optional chapters
in the java.net spec downloads is a renamed file with no other changes
to it.
You can still continue reviewing the spec documents - we have until
03/06/2013 to submit the Proposed Final Draft.
Best,
-marina
On 1/9/13 1:30 AM, Marina Vatkina wrote:
> As I had 1 more day to submit everything to the JCP, and I stumbled
> upon the outdated javadoc for @Local/_at_Remote (see
> http://java.net/jira/browse/EJB_SPEC-81), I decided to use this extra
> time to fix the javadoc and further improve the corresponding rules in
> the spec.
>
> The complete javadocs (and updated the above JIRA with the new texts),
> and the single page from the spec with the updated rules (p115 - the
> updated text starts with "The following rules apply" at the top of the
> page and go till the "Otherwise" bullet) are uploaded to the download
> area (http://java.net/projects/ejb-spec/downloads).
>
> Please review.
>
> thanks,
> -marina
>
> On 1/8/13 11:40 AM, Marina Vatkina wrote:
>> 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
>>>
>>>
>>>
>>
>