Re: [ejb-dev] Corba, EJB + Platform TCK example of separating tests that

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> On Jan 14, 2021, at 1:25 PM, Tracy Burroughs <tkb@xxxxxxxxxx> wrote:
> 
> open-liberty also passes those tests on Java 11.

Great to know.  That definitely leans things towards keeping those references and marking them as optional.

> "java:comp/ORB" is one aspect of this, but exactly what other tests are we referring to?  In general, I didn't think EJB 3 tests would address CORBA other than "java:comp/ORB".

There are some slightly varied versions of the "java:comp/ORB" JNDI lookup that have TCK tests and remaining PortableRemoteObject.narrow calls/requirements.  These both pre-dated the requirement to support the actual IIOP protocol and interoperability with other servers.  

The "java:comp/ORB" variants are basically accessing the ORB not through JNDI, but instead either through EJBContext.lookup() or @Resource dependency injection.  Those three sets of tests are basically copy/tweaked versions of the JNDI tests.  We can potentially keep this functionality, but mark it optional so those who do not support CORBA can sill pass the TCK on Java 11.

The PortableRemoteObject.narrow is tricker for us to deal with at the spec and implementation level.  Even if you support CORBA in your platform, the class is missing from Java 11 and to my knowledge the `javax.rmi` package has not been open sourced anywhere.

As one of the platforms that does use CORBA, would you be willing to see if your 2.x remote EJB calls can work without a `PortableRemoteObject.narrow` call by the app?  If this is working for everyone, the best course of action might be to simply delete it from the spec or say "no longer required and will not work on Java 11 or after" (i.e. you can do it for as long as you're on Java 8)

> If CORBA does remain in Jakarta EE 9.1 as optional, then that also allows the EJB 2.x API tests to continue running, for those implementations that support this already optional API group.  Perhaps that is one of the reasons for keeping CORBA in Jakarta EE 9.1?

Right, there are some interesting levels to this topic.  We've basically had two sets of CORBA requirements:

 - EJB 1.x: Requirements that allow a vendor to use CORBA under the covers: the underlying protocol is not guaranteed to be CORBA

 - EJB 2x, 3x: Requirements that force vendors to support CORBA IIOP as the protocol itself and do interop with other servers

For EE 9 we eliminated the second set and the open question is what to do with the first set.  Even if both sets were completely eliminated and fully deleted from the spec, it would not stop a server from using CORBA as their underlying EJB 2.x protocol (i.e. there is no rule that says, "you can implement any protocol you want for EJB 2.x, but CORBA").

Though we call them "EJB 2.x" interfaces they were actually introduced in 1.x and you could use any protocol you wanted there.  That's still the case.

So in essence it boils down to a simple question of do we want to handle the remaining CORBA requirements.

If you do support CORBA:

 - Keeping them, marking them optional or removing them will not affect those who ship CORBA ORBs.  You're fine.

If you do not support COBRA:

 - Keeping them forces you to ship an ORB you're not actually using to support Java 11.
 - Marking them optional or removing them would be fine for you.

I'm personally ok with optional or removing them.  Each has a different impact on the TCK; easier to remove them, slightly more work to carve them out from other tests so they can be optional.  There are also backwards incompatibility concerns: less if we mark them optional, more if we remove them.

What do others think?


-David