Here are a few minor annotation/api changes we'll be making as we
approach the Beta :
1. @javax.ejb.Init
The spec originally defined this as Init(String[] value() default {}).
The value() attribute was intended to disambiguate the case where a
stateful session bean LocalHome or RemoteHome has multiple create
methods that match the signature of the @Init method. That's a rare
enough case and would be handled by using Init(String value() default
"") so the spec will change to that instead.
Our implementation never implemented any of the Init.value() semantics
so the version in the current glassfish/ejb-api workspace is simply
@Init {}.
2. @Remote / @Local usage on bean-class
Our current implementation assumes that @Remote / @Local has at least
one class value when used on the bean-class. However, the intention in
the spec was for no-arg @Remote/_at_Local to work if there is only a single
potential business interface in the implements clause. This behavior
isn't particularly useful for @Local since the developer can already do :
@Stateless
public class FooBean implements Foo { ... }
If Foo is not itself annotated with @Local or @Remote it assumed to be
@Local anyway, so using :
@Stateless
@Local
public class FooBean implements Foo { ... }
is more work, not less.
The clarification is useful for the Remote case, though :
@Remote
@Stateless
public class FooBean implements Foo { ... }
is/looks better than :
@Remote( { Foo.class } )
@Stateless
public class FooBean implements Foo { ... }
Note that the standard interface exclusion types rules apply here as
well, so
@Remote
@Stateful
public class FooBean implements javax.ejb.SessionSynchronization, Foo {
... }
is OK, since anything in { javax.ejb.*, java.io.Serializable,
java.io.Externalizable } is
ignored.
3. Exception behavior for javax.ejb.EJBContext.lookup(String name)
The spec never clarified the exception behavior for EJBContext.lookup()
in the event that the given name doesn't match an entry within the ejb
component's environment. lookup() will be required to throw a runtime
exception (java.lang.IllegalStateException) in that case. Our current
implementation throws EJBException so it will have to be changed.