|Re: [ee4j-community] Tomitribe commitment to EE4J|
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 smartphoneHi,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 https://github.com/javaee/security-soteria/tree/master/test/app-jaxrsWith 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 TijmsThere 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.
ee4j-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top