[
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?
|
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!
Hi,
Currently the only way to make Corba tests optional is
to move the Corba tests into separate (test client)
packages. This is looking to be a likely longer path
approach (messy/fragile/likely-to-break-something).
At this point, I think the quicker/easy to make changes
would be:
1. Introduce a new way to ignore the Corba tests that
are contained with other tests, so that we do not have
to refactor a lot of EJB abstract classes. Perhaps via
a system property setting that causes the Corba using
tests to just return.
2. Remove use of Corba which doesn't (best) meet the
Platform requirement to have Corba be optional.
I'm leaning toward trying to explore #1 but am open to
suggestions? I'm not yet sure of where the system
property would be set exactly and by whom. I'm
expecting that code like ResourceBeanBase#testOrb() [1]
could return immediately if the (not yet named) system
property indicates that Corba tests should be excluded.
Other ideas?
Scott
[1] https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/ejb30/common/annotation/resource/ResourceBeanBase.java#L405
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev