Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ejb-dev] [VOTE] Handling of PortableRemoteObject.narrow

On Mar 3, 2021, at 2:35 PM, Tracy Burroughs <tkb@xxxxxxxxxx> wrote:

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 PM
Subject:        [EXTERNAL] Re: [ejb-dev] [VOTE] Handling of PortableRemoteObject.narrow
Sent 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 Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On 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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top