| Re: [ee4j-community] Tomitribe commitment to EE4J |
|
I’m very keen to move forward JMS. MDBs are still key for enterprise development and therefore so is JCA/JMS. Also the onMessage interface is basically a functional interface so formal Lambda support
would be good along with good integration to CDI beans. From: ee4j-community-bounces@xxxxxxxxxxx [mailto:ee4j-community-bounces@xxxxxxxxxxx]
On Behalf Of David Blevins It goes without saying, Tomitribe is 100% committed to the success of Java EE's future as EE4J and very excited about what we can all achieve together. We've had discussions within the Tribe about where we might like to contribute or potentially lead. 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. The former EJB should just be services that could be applied to any CDI bean. We've also presented ideas for passing
Java 8 functions to things like the TimerService. Long-term, timers could be clustered. We expect we might be entirely alone in that passion. If not speak up. JMS: We (JMS 2.1 EG) got very nearly finished with annotation-based JMS API. It would be a shame to not deliver that work and there is more than one Triber passionate about this topic. There is also potential synergy with Reactive style
models here that are worth exploring. On this topic in particular we would like community feedback on interest. Are we the only thinks this work is worth finishing or that this API could support some of our more modern asynchronous/reactive approaches? Security: We have a number of people interested in security. This year we showed at JavaOne an API Gateway that supports JWT, HTTP Signatures and also did a security talk and the MicroProfile JWT specification we believe is perhaps the
best specification in the MicroProfile. In JSR 375 we (EG) unfortunately did not go into any aspects of modern rest security, which is a real shame. 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. 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. 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 310-633-3852 |