You're welcome, David.
I'll check with Cheng Fang and Tomek Adamski about when CORBA/IIOP is the underlying protocol as it's getting too far out of my personal knowledge. Most of our tests there the test apps are using PortableRemoteObject.narrow, although I did a quick experimentation with changing a bunch to a simple cast and it looks fine.
That's encouraging. Thanks, Brian.
We eliminated the need for PortableRemoteObject.narrow when we added the simpler EJB 3.x remote views, so there's good hope everyone has the capability to support CORBA/IIOP without a call to PortableRemoteObject.narrow.
If we can get strong "we don't need this" confirmation from everyone, best option is probably to inform users "you don't need to do that" and either mark it optional or eliminate it.
-David
Thank you, Brian! That's very helpful!
If we made the call to PortableRemoteObject.narrow optional for EJB 2.x interfaces, can you confirm if your stack would still function when CORBA/IIOP is the underlying protocol?
-- David Blevins 310-633-3852
Responding to your earlier question about whether servers would use the proposed new optional tests: WildFly intends to run these tests. It's not certain at this point that we would be EE 9.1 complaint at the time the platform is released, but we would expect to run these tests.
Thank you so much, Hussain!
So it looks like our choices for that one are leave it required, make it optional or remove it. We still should get feedback/confirmation if platforms that use CORBA can run without it. I suspect they can as we eliminated the PortableRemoteObject.narrow call from the EJB 3 style remote interfaces which everyone supports.
I'll need to confirm with our EJB lead in case there's some corner case but I believe EJB 2.x apps should work in WildFly without needing to use PortableRemoteObject.narrow. We have tests doing that.
Either way we should investigate releasing it as a standalone package so that people upgrading from Java 8 to 11 have a way to get those apps to run.
The interesting question: what specification project should we use?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jan 14, 2021, at 7:22 PM, <Hussain.NM@xxxxxxxxxxxxx> <Hussain.NM@xxxxxxxxxxxxx> wrote:
>
>
>
> FYI, javax.rmi package is donated to eclipse-ee4j/orb project
>
>
>
> https://github.com/eclipse-ee4j/orb/tree/master/omgapi/src/main/java/javax/rmi
>
>
>
> Thanks
>
> Hussain
>
>
>
> -----Original Message-----
> From: ejb-dev <ejb-dev-bounces@xxxxxxxxxxx> On Behalf Of David Blevins
> Sent: Friday, January 15, 2021 3:35 AM
> To: Tracy Burroughs <tkb@xxxxxxxxxx>
> Cc: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
> Subject: Re: [ejb-dev] Corba, EJB + Platform TCK example of separating tests that use Jakarta XML Binding into (new) separate tests...
>
>
>
> [External]
>
>
>
>
>
> > On Jan 14, 2021, at 1:25 PM, Tracy Burroughs <tkb@xxxxxxxxxx> wrote:
>
> >
>
> > open-liberty also passes those tests on Java 11.
>
>
>
> Great to know. That definitely leans things towards keeping those references and marking them as optional.
>
>
>
> > "java:comp/ORB" is one aspect of this, but exactly what other tests are we referring to? In general, I didn't think EJB 3 tests would address CORBA other than "java:comp/ORB".
>
>
>
> There are some slightly varied versions of the "java:comp/ORB" JNDI lookup that have TCK tests and remaining PortableRemoteObject.narrow calls/requirements. These both pre-dated the requirement to support the actual IIOP protocol and interoperability with other servers.
>
>
>
> The "java:comp/ORB" variants are basically accessing the ORB not through JNDI, but instead either through EJBContext.lookup() or @Resource dependency injection. Those three sets of tests are basically copy/tweaked versions of the JNDI tests. We can potentially keep this functionality, but mark it optional so those who do not support CORBA can sill pass the TCK on Java 11.
>
>
>
> The PortableRemoteObject.narrow is tricker for us to deal with at the spec and implementation level. Even if you support CORBA in your platform, the class is missing from Java 11 and to my knowledge the `javax.rmi` package has not been open sourced anywhere.
>
>
>
> As one of the platforms that does use CORBA, would you be willing to see if your 2.x remote EJB calls can work without a `PortableRemoteObject.narrow` call by the app? If this is working for everyone, the best course of action might be to simply delete it from the spec or say "no longer required and will not work on Java 11 or after" (i.e. you can do it for as long as you're on Java 8)
>
>
>
> > If CORBA does remain in Jakarta EE 9.1 as optional, then that also allows the EJB 2.x API tests to continue running, for those implementations that support this already optional API group. Perhaps that is one of the reasons for keeping CORBA in Jakarta EE 9.1?
>
>
>
> Right, there are some interesting levels to this topic. We've basically had two sets of CORBA requirements:
>
>
>
> - EJB 1.x: Requirements that allow a vendor to use CORBA under the covers: the underlying protocol is not guaranteed to be CORBA
>
>
>
> - EJB 2x, 3x: Requirements that force vendors to support CORBA IIOP as the protocol itself and do interop with other servers
>
>
>
> For EE 9 we eliminated the second set and the open question is what to do with the first set. Even if both sets were completely eliminated and fully deleted from the spec, it would not stop a server from using CORBA as their underlying EJB 2.x protocol (i.e. there is no rule that says, "you can implement any protocol you want for EJB 2.x, but CORBA").
>
>
>
> Though we call them "EJB 2.x" interfaces they were actually introduced in 1.x and you could use any protocol you wanted there. That's still the case.
>
>
>
> So in essence it boils down to a simple question of do we want to handle the remaining CORBA requirements.
>
>
>
> If you do support CORBA:
>
>
>
> - Keeping them, marking them optional or removing them will not affect those who ship CORBA ORBs. You're fine.
>
>
>
> If you do not support COBRA:
>
>
>
> - Keeping them forces you to ship an ORB you're not actually using to support Java 11.
>
> - Marking them optional or removing them would be fine for you.
>
>
>
> I'm personally ok with optional or removing them. Each has a different impact on the TCK; easier to remove them, slightly more work to carve them out from other tests so they can be optional. There are also backwards incompatibility concerns: less if we mark them optional, more if we remove them.
>
>
>
> What do others think?
>
>
>
>
>
> -David
>
>
>
> _______________________________________________
>
> ejb-dev mailing list
>
> ejb-dev@xxxxxxxxxxx
>
> To unsubscribe from this list, visit https://apc01.safelinks.protection.outlook.com/?url="">
>
> This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
-- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat
_______________________________________________ ejb-dev mailing list ejb-dev@xxxxxxxxxxxTo 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
-- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat
_______________________________________________ ejb-dev mailing list ejb-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
|
