I'm also not a native speaker, so those of you who are, please chime in...
In particular, in the 2 examples from Stefan's last email (and I do see similar statements throughout the spec), should "may" be replaced with "can" (the interceptor methods *are* optional)?
thanks, -marina
Stefan Heldt wrote: > Marina, > > as long as there are two choices of which one is mandatory, rewording is ok for me. I was just giving a hint that there are other occurrences of "may be defined" where no one of the given choices is mandatory. > > Examples for the latter case: > 4.9.3: "The PostConstruct, PreDestroy, PrePassivate, and PostActivate lifecycle callback > interceptor methods may be defined for session beans." > > 7.3: "Interceptor methods may be defined for business methods of sessions beans and for the message listener > methods of message-driven beans." > > Maybe this seems natural to you and it was more a hint to myself as I'm not a native speaker... > > Regards > Stefan! > > -----Ursprüngliche Nachricht----- > Von: Marina Vatkina [mailto:marina.vatkina@oracle.com] > Gesendet: Donnerstag, 4. August 2011 03:38 > An: marina.vatkina@oracle.com > Cc: jsr345-experts@ejb-spec.java.net > Betreff: [jsr345-experts] Re: Question about (EJB_SPEC-20) Application Exceptions as part of a throws clause > > Looks like some hidden characters from my working doc cause mail truncation :(. > > What I was asking about - do you think all of them should be reworded? > If not, I'd rather not make it inconsistent... > > thanks, > -marina > > Marina Vatkina wrote: > >> Stefan, >> >> Here is another (similar) case of a "may be defined": >> >> "Lifecycle callback interceptor methods may be defined directly on the >> bean class or on a separate interceptor class ..." >> > > >