| Thanks, Tracy.
Note to all, no part of the vote involves a javax to jakarta namespace change on javax.rmi. PortableRemoteObject. We can legally ship it unmodified. We would only need to do a namespace change if we felt we wanted to develop the API further.
-- David Blevins 310-633-3852
I vote Option A.
I expect there will be far more old EJB 2.x applications migrated to EJB
4.0 then there will be new EJB 4.0 applications written using the 2.x APIs.
When migrating an application, it seems easier to just change the
package names from `javax` to `jakarta`, perhaps with a bytecode transformer,
then to also need to go remove calls to PortableRemoteObject.narrow().
Also a bit confusing that sometimes you would need to remove it for
EJB 4.0 and sometimes not (as it would only depending on the Jakarta EE
level).
-- Tracy Burroughs (tkb@xxxxxxxxxx)
-- WebSphere Application Server Development
-- IBM Rochester, Dept WG8A H315/050-2
-- 2800 37th Street NW, Rochester MN 55901-4441
From:
David
Blevins <dblevins@xxxxxxxxxxxxx>To:
ejb
developer discussions <ejb-dev@xxxxxxxxxxx>Date:
03/01/2021
09:50 PMSubject:
[EXTERNAL]
[ejb-dev] [VOTE] Handling of PortableRemoteObject.narrowSent
by: "ejb-dev"
<ejb-dev-bounces@xxxxxxxxxxx>
Here's the vote as promised last
week. I think I can predict the outcome based on recent conversation,
but as we had some miscommunication here an explicit choice / request for
input from everyone would be very good.
As noted in the discussion, the javax.rmi.PortableRemoteObject class has
been removed from the JDK so there is some explicit action needed from
us to guarantee the portability of applications on JDK 11.
A. PortableRemoteObject.narrow must remain a requirement for users and
servers that support EJB 2.x remote interfaces, which is part of the Enterprise
Beans 2.x API optional group. Signature tests will be added to the
TCK to verify servers that implement the Enterprise Beans 2.x API optional
group are compliant. No specification changes in the Platform or
Enterprise Beans specs would be needed for this approach.
B. PortableRemoteObject.narrow is removed, required for no one, and servers
deal with this under the covers as they do for EJB 3.0 remote interfaces.
The section of the Platform spec that states PortableRemoteObject.narrow
will be updated for Jakarta EE 9.1 Enterprise Beans spec would be
updated at some later date to reflect this is no longer needed. The
PortableRemoteObject.narrow calls in the TCK would be removed.
Both options are orthogonal to if a server does or does not support COBRA.
Let's aim to keep this open for 72 hours so this can be definitively wrapped
up Friday morning.
--
David Blevins
https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_dblevins&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Rrimsmr-EIrvaO6Qlu_Afg&m=6slJKbM18lB73UI5H7jk7ZdOTQrn0wAg786AJ7AqkDo&s=5L8sXg2imhg4pRZvmPorNGWrVltYjmWufRD1FjMLVRg&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tomitribe.com&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Rrimsmr-EIrvaO6Qlu_Afg&m=6slJKbM18lB73UI5H7jk7ZdOTQrn0wAg786AJ7AqkDo&s=GZOTSybf3NMdDARnWm-eIcVdVY8ALEaXqBJpepzikQs&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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
|
