Re: [ejb-dev] How can we best make the EJB30 tests that use Corba option

[Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx>]

> On Feb 25, 2021, at 4:39 PM, David Blevins <david.blevins@xxxxxxxxx> wrote:
> 
>> On Feb 25, 2021, at 1:03 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>> 
>>> In January everyone was asked to confirm that their runtimes could live without it in Java 11 so we could confidently proceed with saying it was no longer required.
>> 
>> I didn't think we (Open Liberty) had agreed to this.  Every time I have talked to Tracy about this, the use of PRO.narrow was a requirement.  But, maybe something got lost in translation, or something.  I do know we indicated that we worked around the requirement by using the open-source version of PRO.narrow.  That's documented in our Platform meeting minutes.  But, I do not remember indicating that we could live with removing it from the Spec.
> 
> It looks like there was some confusion.  I did directly ask Tracy on this list and see now I misremembered getting a response:
> 
> - https://www.eclipse.org/lists/ejb-dev/msg00159.html
> 
> I know both GlassFish and OpenLiberty planned to ship all CORBA classes including javax.rmi, but the specific answer I was looking for and asked for was "will remote calls work on your platforms without users making that call."
> 
> It's ok.  With all this CORBA stuff communicating is the exception and miscommunicating is the status quo.
> 
> The can of worms is open and we now have to make a choice:
> 
>  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 servers deal with this under the covers as they do for EJB 3.0 remote interfaces
> 
> I'm fine with either option.  B has the perk that the class will be guaranteed to be there and old apps will deploy on any new Java 11 server.  It does mean we need to add signature tests for it in the TCK and require everyone to ship it.
> 

I’m a little confused because your description of B seems a better fit for option A so I’m wondering if I’ve totally misunderstood your point, or if you mixed up A and B in the previous paragraph.

> We're either looking at spec work for A or TCK work for B.  If we chose A we can address this in the platform as we planned and update the EJB spec later.
> 
> I'd like to leave this open for discussion for a bit and then call a formal vote Monday.
> 
> 
> -David
> 
> 
> 
> _______________________________________________
> ejb-dev mailing list
> ejb-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev