[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-community] Tomitribe commitment to EE4J
|
I would absolutely agree co-leading is a good choice, even if it is two vendors.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 10/13/17 4:15 PM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
How about we co-lead and invite the Guardians and everyone to help?
I personally see the setup of the Config API where Emily (IBM) and Mark (Independent) as a rather ideal setup that shows a marriage between vendor and independent. To be honest I think things brings more excellence out of people and makes a strongly positive statement about our new direction for EE4J which aims to be less controlled by a single player.
As well for things like JAX-RS or Security, there is more than one person volunteering very politely with "if no one else will, we'll step up". Let's take them both. Two leads increases our chances that momentum stays strong, which is critical in this first year.
This pattern feels like the future.
--
David Blevins
310-633-3852
This is a sort of tricky issue as I want to confirm with the rest of the Java EE Guardians community before I personally commit to anything. My ultimate position will be shaped by those discussions.
I feel strongly about helping move forward or lead the work to finally deprecate EJB in favor of more modern CDI centric services. I believe not doing this work has held back Java EE for a long time and will continue to do so if left unaddressed. I would like to see this work done by CY 2018. If I committed to doing this, I need to make sure the important role that the Java EE Guardians play in the ecosystem is not placed in jeopardy. It is not an easy balance to accomplish.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 10/13/17 2:49 PM (GMT-05:00)
Subject: [ee4j-community] Tomitribe commitment to EE4J
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
--
David Blevins
310-633-3852
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
