Marina,
Any word from the JCA spec lead?
I agree that certification of an EJB lite + feature x,y,z implementation
would be difficult if the TCK cannot be easily segmented to test
individual capabilities beyond EJB lite. If I understand correctly, at
the moment, a vendor can certify as Web Profile compliant and if they
choose, provide additional EJB features such as @Remote?
This discussion also seems to have implications for defining a custom
profile. Going back to the original JCA/JMS/MDB example, let's say we
have a messaging scenario where inbound and outbound messages are to be
processed in a lightweight bus infrastructure. Theoretically, a "message
bus profile" could be defined for this scenario. Assuming this profile
only wants to include MDB related function from the EJB spec, it would be
beneficial if there was a way for the profile to only require (and
certify) that function (and dependent function) from the EJB spec. In
general, the ability to certify features at a more granular level would
enhance the ability to create more purposed, lightweight profiles.
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 10/01/2012 04:18 PM
Subject: [jsr345-experts] Re: EJB lite subset
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
>