Charlie Alfred wrote:
>
> 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.
> >
>
See section 6.2 of the J2EE Platform specification for a detailed
discussion of the Java programming restrictions for J2EE components.
An EJB implementation consists of the EJB class and any other
application classes it calls - there are no Java programming
restrictions that apply only to the EJB class itself. Classes furnished
by the container such as JNDI providers, JDBC drivers, remote procedure
subs/skeletons, etc. are not subject to these constraints.
> 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".
===========================================================================
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".
