[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ejb-dev] How can we best make the EJB30 tests that use Corba optional but still require other non-Corba tests to be run?
|
> On Feb 25, 2021, at 4:18 PM, Brian Stansberry <brian.stansberry@xxxxxxxxxx> wrote:
>
>
>
> On Thu, Feb 25, 2021 at 4:43 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> > On Feb 25, 2021, at 2:06 PM, Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:
> >
> >> A. PortableRemoteObject.narrow must remain a requirement for everyone, regardless if CORBA is or is not supported
>
> To clarify, it's a requirement for everyone who supports the Jakarta Enterprise Beans 2.x API group, yes?
Correct and very important distinction. For others reading, be sure to not confuse optional support for EJB 2.x interfaces with optional support for CORBA. These two features are independent. If we are to keep the PortableRemoteObject.narrow, that requirement is currently tied to EJB 2.x remote interface support -- it is not tied to CORBA support, which as mentioned, was originally optional and now returning to optional status.
I asked Scott Marlow on slack to see how we are currently grouping those tests. Ideally there would be some way to group these new signature tests with any EJB 2.x remote interface tests. Ideally we don't get confused and incorrectly tie use of PortableRemoteObject.narrow to any CORBA-related TCK flags. I'll move that question to the jakartaee-tck dev list for more visibility.
Given all the complexity I'm starting to lean towards option A and keeping PortablRemoteObject.narrow as part of the EJB 2.x remote view requirements. It just seems to make less and less sense to try and avoid it. Users who don't want it can use EJB 3.0 views. Servers who don't want it can already be free of the requirement by not implementing EJB 2.x remote views.
The only downside is if you want to support EJB 2.x remote views you need to ship an additional API to run on Java 11. Presumably you're doing that because you deliberately want to support older apps, so this is not contrary to your goals.
Regardless, this is very good discussion.
-David
