Re: [jakartaee-tck-dev] What is the expected change for EJB tests that a

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> On Oct 14, 2020, at 4:18 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
> 
> Hi David,
> 
> The reason for this email is to ask for a high level description of the change that you intend to work on, to update tests that use org.omg.CORBA.ORB classes.
> 
> Would we move all tests that actually use the org.omg.CORBA.ORB class to  new separate EJB tests?

Let's use a concrete example.

 - https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/ejb30/bb/session/stateless/annotation/resource/ResourceFieldBean.java

This section verifies that a @Stateless EJB can use the @Resource annotation and have injected all injectable types defined across all the Jakarta EE specifications.  This ties together the following specs:

 - Jakarta Annotations (where @Resource itself is defined)
 - Jakarta Mail
 - Jakarta Transactions
 - Jakarta Messaging
 - Jakarta Connectors

It also tests injection of non-Jakarta things:

 - String
 - URL
 - JDBC
 - org.omg.ORB

There are four separate test sections that have an identical bean and a few dozen tests with it.

This test looks like it's an EJB test and it sort of is, but it's actually primarily testing Jakarta Annotations.  The reason you don't see similar ORB references in the Jakarta Annotations-related tests for Servlet for example is because ... well ... there are no Jakarta Annotations (@Resource) tests for Servlets.

There isn't even a dedicated section anywhere in the TCK for Jakarta Annotations.  There are just tests like the one above sprinkled throughout the sections dedicated to other APIs.

It does not work to eliminate this test because if we do we essentially eliminate Jakarta Annotations from out TCK.  It does not work to mark this test "corba" and as that would effectively put Jakarta Annotations into the same bucket as interop; Jakarta Annotations is required period and should not be something you can shut off and still get certified.

The only truly correct thing is to remove the ORB reference from that test and leave the rest as-is.

If we have great concerns about this due to timeline, the only other option is to leave the tests as-is and and still in required state with no ability to shut it off and just tell everyone "sorry, you have to live with that for now, we'll clean this later."

This test is like a house special pizza and the ORB reference is like mushrooms on that pizza.  We either need pick off the mushrooms or just eat the pizza as-is.

This is just one concrete example, there are others like it.

> I think it is too late to remove use of org.omg.CORBA.ORB in 9.0, which does seem like a change that is too big to make with little time left in the EE 9 schedule.  Also, other implementations could be impacted by such a change.
> 
> We previously marked tests that use org.omg.CORBA.ORB as Corba tests (see [1]), and default to not running those tests.  However, as you pointed out the EJB tests that use org.omg.CORBA.ORB are not really Corba tests.  If so, perhaps we should enable those tests by default again.

Tests like the above should in no way be marked as optional and we cannot accept a server as certified if it does not pass the above test. @Resource injection is too critical to be in any way optional.  We've also already voted for and passed the Jakarta Annotations specification so we are ethically bound to respect its presence in the TCK.

The most pragmatic, best worst option I can imagine is we remove the com.sun.ts.tests.rmiiiop tests as planned and leave all other tests, not marking them optional in any way even if they have an ORB reference.  We then come back later and remove the ORB references.

A scenario to truly fear is that we allow servers to be certified against a TCK where large portions of "pizza with everything on it" tests are removed.  We then pick the mushrooms off and put the tests back and now they find there are massive amounts of new tests they can't pass and large compatibility issues we have to deal with.


-David