Marina,
My input:
# XXX marked items:
* getContextData is pretty clear to me -- anything that was put in by an
interceptor pretty much (page 68 and 126).
* If I understand it correctly, I don't think the SessionBean interface
bean meta-data restrictions apply to Interceptor life-cycle call-backs
(page 70).
* I don't see a good reason session synchronization methods should be
limited to one (page 70).
* I think if there are multiple @Remove methods, their retainIfException
values can be different. I don't think this needs further clarification
(page 73).
* I think local and no-interface beans should be accessible
cross-application vis their global JNDI name (pages 77 and 398).
* I think we should support PostConstruct method callbacks as business
methods (page 86).
* wasCancelCalled should not be invoked if there is no asynch method
(pages 87 and 94).
* To me “common bean state” in the context of stateless session beans
means any instance variable value that can be used across method
invocations. I don't think this needs further clarification (page 89).
* We can pick either EJBException or NoSuchEJBException for bad
singletons. I guess NoSuchEJBException would be more consistent with
stateless and stateful (page 98).
* Transactions should be completed before the last AroundInvoke
interceptor method completes (page 157).
* I don't understand the reasons for the restrictions on what singleton
callback can be transactional (I think i should be enabled for both
super-classes and interceptors). I also don't see why XML DDs values
should not be applied to them (pages 166 and 169).
* The module name stuff seems pretty clear to me (page 256).
* Not sure what the issue with ejb-ref/mapped name is. Any decision we
make is fine. In practice I think most people will use global JNDI names
now anyways (page 259).
* The dayOfMonth syntax is pretty clear to me. We don't go higher than
5th. The expression rules also seem pretty clear, but I guess we cam
always add more text (pages 321 and 325).
* The getTimers method is pretty clear to me, but we can certainly add
more text, especially in the Javadoc (page 329).
* I think there isn't an issue to having both @Schedule and @Timeout on
one method (page 330).
* We can clarify the timeout method XML DD semantics. It seems fine to
me (page 330).
* I think it's fine to have a no-arg method for a
programmatically-created timer (page 334).
* The non-interface view text seems fine (page 339).
* The packaging text could use some re-working (page 342).
* We support multiple ejb-jars in a war and mixing and matching with
WEB-INF/lib and WEB-INF/classes (page 397).
* If I understand this correctly, I don't think an EJB-JAR in a WAR
needs a manifest entry (page 400).
* I think WARs with EJBs get referenced the same way as EJB-JARs (page 401).
* The JNDI requirements seem pretty clear to me (page 410).
* The embedded container text seems pretty clear to me (page 421).
# EJB Lite/Embedded Container/Web Profile:
I prefer the status quo flexible approach. It gives Web Profile/Embedded
container vendors broad latitude on what to include. At best, we can put
in text mandating that vendors throw a NotSupporedException for any
feature that they do not support in their environment.
Cheers,
Reza
On 7/5/2011 7:02 PM, Marina Vatkina wrote:
> Dear Experts,
>
> Before we go any further on the discussions of the spec improvements,
> we need to close on several issues with the current version:
>
> 1. Vote on the optionality of the Entity Beans and JAX-RPC based Web
> Service Endpoints (and the split of the spec into 2 parts, but the
> split is the secondary issue). I have only 3 votes (positive) so far.
>
> 2. Close on the items marked by Linda as XXX in the drafts.
>
> 3. Define *deterministic* rules in the EJB spec about EJB Lite vs. EJB
> Full list of features in regards to the EJB support in a Web Profile
> container. In addition to be very flexible (contrary to the regular
> Java EE approach, and the expectations of the EJB TCK), the current
> wording in the spec does not make it clear a) what is expected and
> what is not in the Web Profile, and b) if we keep it flexible, how a
> user (at deployment and/or runtime) can determine if a specific
> feature outside EJB Lite is available/supported.
>
> The same applies to the Embeddable EJB Container.
>
> Thank you,
> -marina
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3746 - Release Date: 07/05/11
>
>