Right. It becomes quite difficult to understand what is supported where
(whether it's called "on demand" or EJB Lite+, or doesn't have a name).
The other problem is the "supported" part - to be called supported, the
corresponding feature needs to pass TCK. And we don't have TCK a la
carte mode to test each feature separately.
I'll look into the JCA spec and check with the JCA spec lead about their
experience (and how TCK supports it).
-marina
asbriglio_at_cesi.fr wrote:
> Hi,
> I agree you should clarify this point.
> But In my opinion, there is a risk for the portability if there is no
> distinction between a strict EJB 3.2 Lite implementation and an
> improved implementation. I try to explain myself:
> If an implementation can support EJB 3.2Lite and other features: it’s
> no more an EJB 3.2 Lite implementation neither a full EJB
> implementation. The risk is a multiplication of implementations with
> only a common part of features (EJB 3.2 Lite) plus different features
> regarding the full EJB API. This could be a problem if we have to
> change of implementation (ok we don’t do this every day) or to choose
> an implementation.
> May be you have name those intermediate implementations that support
> EJB 3.2 Lite + some others features from the full EJB API, say EJB API
> “on demand”, would that be only for the certification of an
> implementation
> Regards,
> Alex
>