Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ejb-dev] R: New release for Jakarta EE 12?
Hi, Angelo,

I think it's a good idea to standardize the HTTP protocol for EJB. But I think it should be an extension to remote EJBs, not in the EJB spec. Reasons:
  • is that we strategically decided to not evolve EJB spec with new features
  • with this new protocol in remote EJB, any Platform implementation would be forced to implement it (unless remote EJBs are removed from the Platform). For WildFly it's not a big deal, it's already there, but all other implementations would have a big blocker or delay with implementing full EE 12 Platform.
The second point is especially concerning if we make this protocol a mandatory part of EE 12. Therefore I suggest that, if you and the WildFly/JBoss team want to standardize the protocol, let's create a separate specification. It could be part of the Jakarta RPC, which would extend the scope and adopt this HTTP protocol along the gRPC protocol, or it could be a completely new specification.

However, even though I think it's a good idea, good luck with getting enough people to participate in the creation of such a standard. We at OmniFish were thinking about implementing the WildFly protocol in GlassFish, there's some demand for it from people who migrate their old apps to Docker, but we don't have enough demand to justify the investment yet. So it's currently very low on our priority list. And we would be definitely against adding the protocol into the EE Platform.


All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Wed, Apr 16, 2025 at 10:18 AM Angelo Rubini via ejb-dev <ejb-dev@xxxxxxxxxxx> wrote:
hello everyone,
 it's all clear, there is the idea of ​​evolving ejb in @Service CDI and also of having a first implementation of jakarta rpc, but to date:
 both @Service and jakarta rpc are still stuck and do not have a reference implementation. 
I was referring to the case of the wildfly specification,
 because it reminds me of when j2ee had ejb entities and everyone used hibernate and from hibernate the jpa specification was born. 
I thought that history could be repeated for this too. In wildfly you can use all the features of ejb (download stub, distributed transaction over rmi, security etc etc) 
all through http/http2.

Having this powerful feature would also allow you to go to customers,
 and show how to have distributed transactions ejb style but on http/http2 protocol which is much friendlier in cloud contexts,
Regards
Angelo Rubini
Da: ejb-dev <ejb-dev-bounces@xxxxxxxxxxx> per conto di Reza Rahman via ejb-dev <ejb-dev@xxxxxxxxxxx>
Inviato: martedì 15 aprile 2025 23:32
A: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Cc: Reza Rahman <reza_rahman@xxxxxxxx>
Oggetto: Re: [ejb-dev] R: New release for Jakarta EE 12?
 

For those with a serious interest in RPC, gRPC and Jakarta RPC (https://projects.eclipse.org/projects/ee4j.rpc) would be great areas to focus on. It would also have much greater marketing value as opposed to EJB.

On 4/15/2025 5:18 PM, Tracy Burroughs via ejb-dev wrote:

I agree that the Jakarta EE community has been actively working to replace all EJB capabilities with feature in other specifications, such as the CDI spec, transactions spec (@transactional), and even concurrency spec (timers).  With that direction from the community, any feature under consideration for EJB would be better targeted at a different specification.

I would prefer that the 4.1 release plan only address the requirements that are coming from the Jakarta EE 12 Platform specification, which would be
- remove Java Security Manager language
- Java SE 17 or higher.

 

From: ejb-dev <ejb-dev-bounces@xxxxxxxxxxx> On Behalf Of Arjan Tijms via ejb-dev
Sent: Tuesday, April 15, 2025 11:46 AM
To: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>; Edward Burns <Edward.Burns@xxxxxxxxxxxxx>; Reza Rahman <Reza.Rahman@xxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [ejb-dev] R: New release for Jakarta EE 12?

 

Hi, As we need to move away from EJB in order to make the project more consistent, is it really wise to add a new feature? I'm thinking about the signal we're sending out with this. On the one hand we're deprecating usage of the

Hi,

 

As we need to move away from EJB in order to make the project more consistent, is it really wise to add a new feature? I'm thinking about the signal we're sending out with this. On the one hand we're deprecating usage of the EJB, and at the same time we're adding something new to it.

 

Would it not be better to implement the same feature using something that depends on CDI? 

 

Kind regards,

Arjan Tijms

 

 

 

On Tue, 15 Apr 2025 at 11:08, Tomasz Adamski via ejb-dev <ejb-dev@xxxxxxxxxxx> wrote:

Hi David,

 

I have created a draft plan PR for Enterprise Beans Jakarta EE12 release but I cannot create a new release on the project page: https://projects.eclipse.org/projects/ee4j.ejb. Would you be able to create such a release or point me to someone who can help me with this?

 

Regards,

Tomek

 

On Mon, Apr 14, 2025 at 11:27 PM Tomasz Adamski <tadamski@xxxxxxxxxx> wrote:

Hi Angelo,

 

I'm the lead for the Enterprise Beans subsystem in WildFly/JBoss EAP.

 

I have created a PR (https://github.com/jakartaee/specifications/pull/826) with Enterprise Bean Jakarta E12 release draft plan.

 

Regards,

Tomek

 

On Thu, Apr 10, 2025 at 9:10 PM Angelo Rubini via ejb-dev <ejb-dev@xxxxxxxxxxx> wrote:

Hi All,

 

why not think about standardizing this implementation present in wildfly?  like this:

 

·       Ejb Over http/Http2

The client libraries that support EJB, Naming and Transactions over HTTP - wildfly/wildfly-http-client
    •  
·      Distributed EJB Transaction over http/http2

Discover how to implement a distributed transaction solution using Jakara EE Jakarta Enterprise Beans (EJB) in this in-depth guide.
    •  

Regards

Angelo Rubini

 

Da: ejb-dev <ejb-dev-bounces@xxxxxxxxxxx> per conto di Jared Anderson via ejb-dev <ejb-dev@xxxxxxxxxxx>
Inviato: mercoledì 9 aprile 2025 22:29
A: ejb-dev@xxxxxxxxxxx <ejb-dev@xxxxxxxxxxx>; Edward Burns <Edward.Burns@xxxxxxxxxxxxx>
Cc: Jared Anderson <jhanders@xxxxxxxxxx>
Oggetto: Re: [ejb-dev] New release for Jakarta EE 12?

 

Community members,

 

I am writing this email to your community now that the April 15 deadline is fast approaching.  As of now, a release plan for a next release of your component has not been created or an indication put in the  opened issue in my original email to state that you do not plan a release that could be considered for Jakarta EE 12.

 

It was brought to my attention that people may not realize what is being asked to be done when creating a release plan.  There is information in the issue provided on the how, but the main point of having a release plan is that we are looking to know that you are planning to do something and whether you are looking at doing a minor release or a major release depending on the types of changes.  What is in the release plan that you create can change over time, but at least there is an indication that you are working to make a new release even if you don't know what all will be in it yet.  We are not asking for all issues to be created and code, tests, implementation or specs to be updated in order to make a release plan.  If you look at the release plans created so far, you will find that some of them are quite vague.  They are just saying yes we plan on doing a new version of the component.  A release plan also gives an indication to those not in the Jakarta community that work is happening in the specification that they can look forward to and possibly suggest changes.  If you need help with making your release plan, please reach out to Ed or me on slack or email.

 

Enterprise Beans  was identified as a component that requires a new release in order to remove Java SecurityManager language from the specification at this location. 

 

If there are no other things to be added to a release plan for Enterprise Beans, that is ok.  It can just be a very minor release to update the specification to remove SecurityManager references.

 

Thanks,

 

Jared Anderson

Jakarta EE 12 Release Co-coordinator

From: Jared Anderson <jhanders@xxxxxxxxxx>
Sent: Wednesday, February 26, 2025 3:55 PM
To: ejb-dev@xxxxxxxxxxx <ejb-dev@xxxxxxxxxxx>; Edward Burns <Edward.Burns@xxxxxxxxxxxxx>
Subject: New release for Jakarta EE 12?

 

Community members,

 

Executive Summary

 

1. See issue #153.

      a. If you don't plan to have a new version for your specification in EE 12, just close the issue.

      b. If you plan to have a new version, use the issue to create a release plan by April 15, 2025.

2. See this dashboard where the component release plan issues are tracked.

 

 

Details

 

On Monday I opened issue #153 in your repository to request your community to consider a new release of your component for Jakarta EE 12 by creating a new release plan.  The issue contains a lot of details that explain what to do to create a release plan.   You can use the issue to document initial thoughts and reference other issues in your repository as you work out what you want to include in a release plan.  

 

A dashboard in GitHub was created to track the status of the release plan issues.  The dashboard, located here, contains both a Board and Table view of the release plan issues.  What is being asked of each community is to decide on if you plan to have a new release to be considered for EE 12 or not.  If not, closing the issue will move it to the final column on the dashboard.  If you are planning to have a new version of your component for EE 12, please follow the instructions in the issue by April 15, 2025 in order to get your issue moved to the second column for your mentor to look at the issue and get it ready for a plan ballot.  You will see that your issue in the board includes the name of the mentor that was assigned to your component in EE 11.

 

Thanks,

 

Jared Anderson and Ed Burns

Jakarta EE 12 Release Co-coordinators

 

 

_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev


 

--

Regards,

Tomek


 

--

Regards,

Tomek

_______________________________________________
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

Back to the top