Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [ejb-dev] How can we best make the EJB30 tests that use Corba optional but still require other non-Corba tests to be run?

Scott,

I can confirm that #1 (remove calls to PortableRemoteObject#narrow) will fail for Open Liberty, so #2 would be the preferred solution.

-Brian


Inactive hide details for Scott Marlow ---02/24/2021 02:58:43 PM---https://urldefense.proofpoint.com/v2/url?u=https-3A__github.Scott Marlow ---02/24/2021 02:58:43 PM---https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_jakartaee-2Dtck_issue

From: Scott Marlow <smarlow@xxxxxxxxxx>
To: ejb developer discussions <ejb-dev@xxxxxxxxxxx>, Cheng Fang <cfang@xxxxxxxxxx>, David Blevins <dblevins@xxxxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 02/24/2021 02:58 PM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] [ejb-dev] How can we best make the EJB30 tests that use Corba optional but still require other non-Corba tests to be run?
Sent by: "jakartaee-tck-dev" <jakartaee-tck-dev-bounces@xxxxxxxxxxx>




https://github.com/eclipse-ee4j/jakartaee-tck/issues/621 is for removing the TCK calls to PortableRemoteObject#narrow or make those calls optional (perhaps similar to https://github.com/eclipse-ee4j/jakartaee-tck/pull/620 which could use some

https://github.com/eclipse-ee4j/jakartaee-tck/issues/621 is for removing the TCK calls to PortableRemoteObject#narrow or make those calls optional (perhaps similar to https://github.com/eclipse-ee4j/jakartaee-tck/pull/620 which could use some more reviews :-)

I think the two possible changes could be something like:

1.  Remove all calls to PortableRemoteObject#narrow and encourage implementations to test the result.
2.  Or keep the call to PortableRemoteObject#narrow but ensure that implementations that do not support Corba can set a system property `ExcludeCorba` (to `true`) to avoid the reference to the PortableRemoteObject class.

Please share your thoughts on which approach is better/safer #1 or #2.  Or maybe you have a #3?

Scott

On 2/17/21 1:27 PM, Scott Marlow wrote:

      Hi Cheng,

      On 2/17/21 12:25 PM, Cheng Fang wrote:

          Hi Scott,

          Many corba tests are mixed with other tests so I can see it's difficult to tear them apart. I like the idea of having a system property to include or exclude them in test execution. Most likely the sysprop will be configured in the target appserver, and maybe also on appclient side.

          But not all tests can be controlled this way. Some tests have class-level or field-level annotations that reference orb classes. In this case, we'll probably need to move part of it into some separate test client that is executed by implementations that fully support corba.
      Thanks, this is very helpful to read here! 

Back to the top