Skip to main content

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

Even if we could find a way to remove the need for PortableRemoteObject.narrow form 9.1 I think we need to find a way to provide the class and methods. If we do not it means application code written to use it as recommended for Jakarta EE 9 and before will not work on 9.1 without redevelopment. I expect that to go from Jakarta EE 9 to 9.1 I wouldn’t have to change any code just upgrade my Java version to 11. This wouldn’t just affect the CORBA based EJB implementations, but all of them given the long standing recommendations on writing portable code.

Alasdair

On Feb 25, 2021, at 3:25 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

David,
I'll let others chime in from a technical perspective, but I have a couple of concerns with this request...

>  If we've determined that our implementations that chose to optionally support CORBA still need PortableRemoteObject.narrow than we have two paths:

Not sure that I follow this reasoning.  Why couldn't PortableRemoteObject be lumped with CORBA and be optional as well?  Your two options are to keep PRO.narrow as required, or remove it.  I don't understand why it couldn't be optional, just like CORBA is.

>  B. PortableRemoteObject.narrow is removed, required for no one, and failures can be fixed in the servers that use CORBA

I do not agree with this approach for Jakarta EE 9.1.  We have decided that 9.1 was only going to affect the Platform Spec to clear up the Java SE 8 vs 11 usage, and to clear up this CORBA optional usage.  Removing PRO.narrow is too much for the 9.1 release.  Wouldn't this affect the EJB spec as well as the Platform spec?  And, would it also affect the APIs?  As your statement states, the affected servers would need to be modified to resolve the missing PRO.narrow requirement.  I think that is asking too much.


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

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)




From:        David Blevins <dblevins@xxxxxxxxxxxxx>
To:        ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Date:        02/25/2021 14:07
Subject:        [EXTERNAL] Re: [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:        "ejb-dev" <ejb-dev-bounces@xxxxxxxxxxx>




Trimming out the TCK list as we have spec-level decision to make here with regards to PortableRemoteObject#narrow.

Our original status in EE prior to EJB 2.0 was that CORBA was optional and PortableRemoteObject.narrow was required.  Specifically, servers could support CORBA or not, but users were strictly told they must always use PortableRemoteObject.narrow regardless.  The reason this was required was for application portability concerns; if an app didn't make the call, it couldn't be ported to a server that used CORBA.

If we've determined that our implementations that chose to optionally support CORBA still need PortableRemoteObject.narrow than we have two paths:

A. PortableRemoteObject.narrow must remain a requirement for everyone, regardless if CORBA is or is not supported
B. PortableRemoteObject.narrow is removed, required for no one, and failures can be fixed in the servers that use CORBA

Now, in EJB 3.0 we did introduce new style remote interfaces and successfully removed the need for PortableRemoteObject.narrow.

Tracy, is it possible you can work with the team and see how that was accomplished and if there is some possibility to leverage that to also eliminate the need for PortableRemoteObject.narrow in EJB 1.1 style interfaces?

If that can't be made to work, we have no real choice but to leave PortableRemoteObject.narrow a requirement.  The complicated factor is it has been removed from the JVM.  We would need to make all servers ship that API and the TCK signature tests fail if it isn't present.


--
David Blevins
https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_dblevins&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=IJzzMAanVrANYDmPacE-6DXTCr95ALE-noQiT4C_mys&s=XDLWVU-mGeo5eEyHfiZaleHd3NYrAegTlN9m9V9Mczk&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tomitribe.com&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=IJzzMAanVrANYDmPacE-6DXTCr95ALE-noQiT4C_mys&s=80Bp5jMflzD3Vjk4OBi6ieNzM02V4JzsPfmetfq2mzo&e=


> On Feb 24, 2021, at 9:53 PM, Tracy Burroughs <tkb@xxxxxxxxxx> wrote:
>
> I can confirm that #1 (remove calls to PortableRemoteObject#narrow) will fail for Open Liberty, so #2 would be preferred.
>
>
> -- Tracy Burroughs (tkb@xxxxxxxxxx)
> -- WebSphere Application Server Development
> -- IBM Rochester,  Dept WG8A    H315/050-2
> -- 2800 37th Street NW, Rochester MN 55901-4441
>
>
>
>
> From:        Scott Marlow <smarlow@xxxxxxxxxx>
> To:        ejb developer discussions <ejb-dev@xxxxxxxxxxx>, Cheng Fang <cfang@xxxxxxxxxx>, David Blevins <dblevins@xxxxxxxxxxxxx>
> Cc:        Rohit Jain <rohit.ku.jain@xxxxxxxxxx>, jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
> Date:        02/24/2021 02:58 PM
> Subject:        [EXTERNAL] Re: [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:        "ejb-dev" <ejb-dev-bounces@xxxxxxxxxxx>
>
>
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_jakartaee-2Dtck_issues_621is&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=IJzzMAanVrANYDmPacE-6DXTCr95ALE-noQiT4C_mys&s=ZPn4RpXKvovk47tlyVPyB0lHvpbpZvK4tYcs3u9gCm4&e= for removing the TCK calls to PortableRemoteObject#narrow or make those calls optional (perhaps similar to https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_jakartaee-2Dtck_pull_620which&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=IJzzMAanVrANYDmPacE-6DXTCr95ALE-noQiT4C_mys&s=YEBj3BeTqTvlkPOasuBlvvTLVsscLt1FLfLpijcEcWI&e= 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!  
>
> On Tue, Feb 16, 2021 at 3:22 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dee4j_jakartaee-2Dtck_blob_master_src_com_sun_ts_tests_ejb30_common_annotation_resource_ResourceBeanBase.java-23L405&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=IJzzMAanVrANYDmPacE-6DXTCr95ALE-noQiT4C_mys&s=CB0ezrJy4FVU4QwjF-p36Nr7vCOIEWoLdk8nlSXddTo&e=
> _______________________________________________
> 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
> _______________________________________________
> 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




_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev


Back to the top