Jeremy,
Jeremy Bauer wrote:
> Marina,
>
> Any word from the JCA spec lead?
We were all busy with JavaOne ;).
>
> 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?
To *claim* support for @Remote, the vendor would need to pass all tests
that are relevant to the remote rules, including interop tests.
>
>
> 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.
We should definitely look at such options. But any one of them would
need to define the closure of all relevant APIs that need to be
supported as well. It's on my todo list, but it's not straight forward.
Best,
-marina
>
> -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
> >
>
>