| Re: [jakartaee-tck-dev] What is the expected change for EJB tests that are using org.omg.CORBA.ORB? |
>
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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev