[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ejb-dev] [VOTE] Handling of PortableRemoteObject.narrow
|
David, thanks for
clarifying that. In no way did I mean to suggest there would be a
namespace change for javax.rmi.PortableRemoteObject, nor do I think we
should do that.
Cool. Wasn't sure so erred on the side of being explicit.
Agree with your reasoning behind the A vote.
-David
From:
David
Blevins <dblevins@xxxxxxxxxxxxx>To:
ejb
developer discussions <ejb-dev@xxxxxxxxxxx>Date:
03/03/2021
04:20 PMSubject:
[EXTERNAL]
Re: [ejb-dev] [VOTE] Handling of PortableRemoteObject.narrowSent
by: "ejb-dev"
<ejb-dev-bounces@xxxxxxxxxxx> 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 Blevinshttp://twitter.com/dblevins http://www.tomitribe.com310-633-3852On Mar 3, 2021, at 2:13 PM, Tracy Burroughs
<tkb@xxxxxxxxxx>
wrote: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 PM Subject: [EXTERNAL]
[ejb-dev] [VOTE] Handling of PortableRemoteObject.narrow Sent 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@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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature