Mark Hapner wrote:
> The threading restrictions, JNI restrictions, etc. that EJB 1.1 imposes
> define are an important part of the EJB Component/Container contract on
> which EJB portability is based.
>
> Some EJB vendors may provide access to Java features that go beyond the
> minimum set of Java permissions defined by EJB 1.1 and J2EE specs;
> however, no EJB vendor is required to support EJBs that require more
> than the specified minimum permissions.
>
You seem to be saying two contradictory things here. Restrictions imposed
by the spec are very different from non-required features. While portability
is compromised in both cases, the similarity ends there.
If the spec truly intends that EJB's cannot manage threads or use synchronization,
then a vendor that supports this is not in compliance. In addition, if the spec
also intends that classes called by an EJB are subject to the same restrictions
as the EJB's, then it should say that also (which means, as pointed out in other
posts, that EJB's can't call methods on String, Vector, HashMap or several
other standard Java library classes).
On the other hand, if the spec describes a feature and marks it as optional
(like Entity Beans in EJB 1.0), then vendors who support it according to the
spec, and those who don't support it are compliant.
Optional features are a pragmatic compromise that address the lowest common
denominator problem. For example, there's general agreement that Entity Beans
are a good idea, but some vendors object during the spec creation process,
because they won't be able to implement them on time. The consensus is that
the feature isn't crucial enough to require in the short run, but significant
enough to document a baseline API for inclusion in the longer term.
I, for one, would be perfectly content seeing thread management, synchronization,
file I/O, sockets, and JNI access specified as *optional* features. I support Arkin's
argument that the container/server should expose the thread management API.
If this approach is taken, the spec should document the relevant caveats that are
associated with using these optional features. For example, any file I/O performed
by an EJB is *not* subject to transaction rollback. Caveats and disclaimers are
a standard part of contracts in the real world. An insurance company doesn't
prohibit cigarette smoking. Instead, it has policies for smokers and policies for
non-smokers. The rate for the former is higher, but if a smoker buys a non-smoker
policy and vlolates the restriction, then the insurance company is not obligated to
pay the face value when the policy holder dies.
Charlie
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
