Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] What is the expected change for EJB tests that are using org.omg.CORBA.ORB?

Scott,
Two things come to mind with this approach...

1)  The Distributed Interop aspects of RMI/IIOP were removed from Jakarta EE 9.  That was the Chapter 10 of the EJB 3.2 Spec.  So, we shouldn't be calling this non-support as "optional".  Granted, some implementations may still use RMI/IIOP to support remote EJBs within their own implementations, but that is not prescribed.

2) Adding a flag still has a large ripple effect across the test suite (another one of David's point).  We're trying to find a way to make this testing "consumable" in the short timeframe we have left, and not accidentally exclude required tests.

Currently, there are test packages demarcated with the "corba" and "rmiiiop" properties.  David has correctly pointed out that not running the "corba" tests removes a large number of tests that should still be part of the Jakarta EE test effort.  Scott Marlow was looking at the "rmiiiop" set of tests this morning and these seem to be better defined.  So, maybe the "rmiiiop" tests should not be part of the Jakarta EE 9 test requirement?  And, leave the "corba" tests in place (albeit with the caveat of possibly providing a non-null ORB for now)?

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        Scott Stark <starksm64@xxxxxxxxx>
To:        jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date:        10/15/2020 12:29
Subject:        [EXTERNAL] Re: [jakartaee-tck-dev] What is the expected change for EJB tests that are using org.omg.CORBA.ORB?
Sent by:        jakartaee-tck-dev-bounces@xxxxxxxxxxx




It does not make sense to require a non-null org.omg.CORBA.ORB be injected into a bean if the implementation does not support CORBA. It seems like the minimal change would be to add a flag to indicate if the optional RMI/IIOP tests are supported and update the testOrb() and related tests in https://github.com/eclipse-ee4j/jakartaee-tck/blob/517e144458d66df2a4621ee91a0961c735d26d4b/src/com/sun/ts/tests/ejb30/common/annotation/resource/ResourceBeanBase.java#L405

to avoid the injected ORB if the flag is false.


On Wed, Oct 14, 2020 at 10:39 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

> 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



Back to the top