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

+1. I also think modularity in CDI is key. CDI seems to bring in too many dependencies so if we can break that up at the spec level, that would be great.

/Dimitris

On 14/10/2017 20:38, Anatole Tresch wrote:
Hi David/all

I am looking forward to bring things forward. Reading your mail, modularity for me is the absolute top issue. Modularity in APIs automatically enables modularity in the runtime. we might think on mechanisms as well how a deployment can declare its required  capabilities and check for the capabilities provided by the runtime in a unified way eg leveraging java 9 modularity?
Using CDI as the main wiring mechanism makes sense for me. EJBs should be implemented based on and managed in CDI only. Though the coupling produced by RMI based comminications does not match my views.
So I am happy to join the work here and hopefully my few cents may be useful😊

J Anatole

Am 13.10.2017 20:49 schrieb "David Blevins" <dblevins@xxxxxxxxxxxxx>:
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





_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community

Back to the top