ok thanks for the reply.
But if you want to leave the choice of the rmi protocol to the application server provider,
perhaps it is the case that the full platform certification obliges the various providers
to have distributed and transactional remote calls and that
they support all types of propagation attributes of a inbound and outbound transaction:
REQUIRED,REQUIRED_NEW,MANDATORY,SUPPORT AND NOT_SUPPORT).
It is strange to have AS that are full platform certified like openliberty,
but which then do not fully support transactional remote calls see
(https://www.ibm.com/docs/en/was-liberty/zos?topic=liberty- using-enterprise-javabeans-remote-interfaces)
What do you think?
Regards,
Angelo
Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Ivar Grimstad via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: martedì 24 ottobre 2023 11:52
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Help - The future of jakarta ejb vs RMI-IIOP
Hi,
The Jakarta EE Specification Committee has passed a resolution to not allow optional features in the Platform specification.
Since CORBA, IIOP, and IDL are optional features today, we have two choices:
1. Make them required
2. Remove them
Since they are optional today, I don't see them being made required again, so removal is the likely thing to happen.
That said, even if a feature is no longer part of the platform does not mean that it goes away automatically from all implementations. Remember they are optional today, so it is likely only a subset of implementations supporting it.
I guess that the implementations supporting these features today will continue to do so at least for a while. But that is a question for the vendor providing the implementation you are using.
Ivar
Hi Ivar,
my doubt, arises from the fact that one of the great features of jakarta ee is remote transactional
calls distributed between multiple ejbs
(based on rmi-iiop, both Glassfish(sun orb) and Openliberty(yoko orb) use iiop for remote and transaction
calls between ejbs).
If the plan is want to remove rmi-iiop(corba) from jakarta ee(version 11),
how will ensure and continue to use distributed transactional remote calls (inbound and outbound)
between multiple ejbs?
The jakarta ee 11 plan is, remove all spec marked optional and in this slide the removed items in list are:
https://speakerdeck.com/ivargrimstad/prepare-for-jakarta-ee-11?slide=19 it's correct?
Thanks
Angelo
Hi Angelo,
Thanks for your interest in Jakarta EE!
1. The removal of Managed Beans does not relate to CORBA/RMI-IIOP. It is just about the removal of the component model that CDI supersedes. Managed Beans was deprecated in Jakarta EE 10, so this removal follows that.
If you think more clarification is needed, I suggest bringing it up with the Jakarta EE Platform project.
Hope this helps!
Ivar
Hi All,
if it is planned to remove corba&rmi-iiop from jakarta ee 11,
how will the ejb components make remote and transactional calls distributed between
both inbound and outbound ejbs?
In the slide(
https://speakerdeck.com/ivargrimstad/prepare-for-jakarta-ee-11-af58e464-eeb9-49d7-a7ae-8c39749455f3?slide=17)
presented at EclipseCon 2023,
it is highlighted how Managed Beans 2.0 will be removed and replaced by CDI.
How do you remove corba&rmi-iiop without knowing what it will be replaced with,
to continue having remote transactions calls between distributed ejbs ?
To date there are still many software that use,
work and continue to be developed by having remote calls between EJBs with distributed transactions....
Thanks
Angelo Rubini
On 2023-08-03, Ed wrote:
Executive Summary
At the platform project weekly
meeting on 2023-07-25, we put a stake in the ground to say that all Jakarta EE 11 component specs should be ready to start their release review by 2024-01-30 at the latest.
Details
Now that we have received the plans, and the plans have been approved by the Specification Committee, it is time to get started working toward a release. To deliver Jakarta EE 11 on time, we would like all component
specifications to be ready for release review by 2024-01-30. Please don't hesitate to let us know at the earliest time if this deadline is not achievable.
This date was picked to give component specs that are heavily exposed to the Java SE 21 release sufficient time after that release to tie up all their SE 21 exposures.
If you can get your spec done before 2024-01-30, please do.
Thanks,
Ed
Nearly 90 days have elapsed. How’s it going? I hope you are all making progress toward getting your specs ready for release review. I want to bring your attention to the new Spec versioning, change, and deprecation process:
Jakarta EE Specification Versioning, Change, and Deprecation Process | The Eclipse Foundation. Please consider this as you author your spec updates for EE 11.
Thanks,
Ed
| Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse
Foundation - Community. Code. Collaboration.
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse Foundation
- Community. Code. Collaboration.
|
