Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Tomitribe commitment to EE4J

Do instance pools still provide a real performance gain? I know Adam Bien did an informal test on Payara and the results where positive for EJBs, but I don't think the results are too reliable. 

WildFly disabled pools by default for some time ane the EJB spec doesn't even mandate a pool to exist. I doubt it's a really useful feature. An @MaxConcurrency would be more useful IMO that the pool itself (so different scopes can be used) while serving a similar purpose. And that again falls on the Concurrency Utilities side.



Guillermo González de Aguero

El sáb., 14 de octubre de 2017 21:07, reza_rahman <reza_rahman@xxxxxxxxx> escribió:
Personally I think @Pooled/@PoolScoped is best in CDI. The remainder of the EJB functionality can be pretty cleanly rmed out between Java EE Concurrency and JMS/JCA.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 10/14/17 2:24 PM (GMT-05:00)
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J

We tend to be passionate about topics we perceive as abandoned.  Before we sign ourselves up for any crusades, we would like community feedback to see if there are other's who might share our passions.
EJB: We believe CDI is the future and all things should align to it.  We (Java EE EG, EJB EG) started work on aligning EJB to CDI in the form of breaking apart the EJB spec into smaller specifications like Interceptors specification and @Transaction specification, but we did not finish.  There is some work left pulling things like @Schedule, @Asynchronous, or @Lock(READ) out.

As expressed previously on the Java EE spec list, I strongly support that too. In order to have a more consistent programming model to offer the user, these, and a few others should be re-implemented based on CDI and Interceptors.

I think this can best be done in a similar way as @Transactional was done; basically have the EJB name and semantics, but add a few extra features and/or take away some existing pain points.

At OmniFaces we started prototyping this a while ago. The intend was for those implementations to be a base proposal for inclusion in Java EE 8, but that never happened.

Also note that we took a couple of steps to align JSF more with CDI in JSF 2.3, and that alignment story is far from done.

Java EE Security as a new spec has been based fully on CDI from the start.

 The former EJB should just be services that could be applied to any CDI bean.

By that do you mean that you'd like to see @Asynchronous to remain in the EJB spec, but in a CDI version? 

Since @Transactional moved to JTA, I think it might be a better idea to move @Asynchronous to the Concurrency spec. Not sure about @Pooled though, but @Schedule and @Lock probably should be best at home in the Concurrency spec as well.

In JSR 375 we (EG) unfortunately did not go into any aspects of modern rest security, which is a real shame.

Yes and no. There are no specific authentication mechanisms provided such as OAuth2 or JWT, but the spec was really careful to make sure it does work well with REST endpoints. The RI specifically tests for this. See

With the primitives that were put in place it's easy to do something like this:

The specification is a step forward, but does fall into the same trap that Java EE security has always "solved" the via Java layer abstractions and doesn't address wire level interoperability.

I'm not so sure if it really fell onto a trap of any kind.

There were simply many issues to be addressed and only so much time and resources available. The artefacts that were specified were basically the low hanging fruit and addressed basic gaps in the existing specs.
What was done in the MicroProfile JWT specification should get merged in some way with EE4J security.  Microservices should be able to portably communicate the caller via JWTs.

Absolutely, and in my mind that was always the idea basically. It's certainly what we had in mind for Payara.

Kind regards,
Arjan Tijms

There is some internal tribe interest in participating in JCA, JPA and JAX-RS.  For JPA, there are thoughts about what a Java 8 stream based API for JPA might look like.

On the topic of RIs, we would want the ability to chose the RI for anything we might lead.  Before any "that's the way it is" might be used as an argument, we'd point out that we are changing almost everything about EE and its process.  We'd want to see this up for discussion.

David Blevins
ee4j-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top