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? 

On 10/15/20 2:15 PM, David Blevins wrote:
On Oct 15, 2020, at 10:29 AM, Scott Stark <starksm64@xxxxxxxxx <mailto:starksm64@xxxxxxxxx>> wrote:
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 <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.
Not sure if we're proposing the same thing or something slightly different.  I'll yank the orb references from this particular test in a PR so we have something to pick apart.
IMO, in order to meet the EE 9 schedule, we need to wrap this up this week.
Worse case, we will ship the tests as is with the org.omg.CORBA.ORB references and default those tests to run. 

Scott




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

    > On Oct 14, 2020, at 4:18 PM, Scott Marlow <smarlow@xxxxxxxxxx
    <mailto: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
    <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 <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
    <https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev>

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto: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