Sending my replies as an attachment in the hope to bypass my mail client
weird truncations... If this doesn't work, will send them one-by-one...
-marina
This is part 3 (and hopefully the last one, as I do not know why my mail is being truncated all the time).
<...>
> * The getTimers method is pretty clear to me, but we can certainly add
> more text, especially in the Javadoc (page 329).
Yes. Modified the spec to say 'all', but left XXX to fix the javadoc
> * I think there isn't an issue to having both @Schedule and @Timeout
> on one method (page 330).
Yes. New text:
"The timeout callback method for the programmatically-created timers can
also be associated with the automatically-created timers."
> * We can clarify the timeout method XML DD semantics. It seems fine to
> me (page 330).
New text in the footnote:
"To preserve backward compatibility, a timeout-method that does not
include a method-param element for the javax.ejb.Timer parameter may be
used to match either a timeout method signature with or without a Timer
parameter, if there is only one method with the specified name. If
methods with the specified name are overloaded, a timeout-method element
with an empty method-params element will be used to explicitly refer to
a the no-arg timeout method."
> * I think it's fine to have a no-arg method for a
> programmatically-created timer (page 334).
Yes. Noted.
> * The non-interface view text seems fine (page 339).
Thanks. Removed the XXX.
> * The packaging text could use some re-working (page 342).
Yes :(. Any suggestions?
> * We support multiple ejb-jars in a war and mixing and matching with
> WEB-INF/lib and WEB-INF/classes (page 397).
Right. Added a note:
"A .war file may contain enterprise bean classes in a combination of classes within the WEB-INF/classes directory and one or more jar files within the WEB-INF/lib directory."
> * If I understand this correctly, I don't think an EJB-JAR in a WAR
> needs a manifest entry (page 400).
I agree. Should I just remove both XXX comments?
> * I think WARs with EJBs get referenced the same way as EJB-JARs (page
> 401).
A Java SE client won't find classes if they are part of a .war file...
> * The JNDI requirements seem pretty clear to me (page 410).
I made it explicit, that this section applies to both profiles (which is important for TCK testing).
> * The embedded container text seems pretty clear to me (page 421).
The problem is with the rules about the should/must/are/etc. words in the spec. Only "must" is a requirement. If this bootstrapping process is not a must, what will be a portable way to do so?
>
> # 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.
Let's start a separate discussion on that.
Thanks,
-marina
>
> 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
>>
>>
>>
>>
>