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

My view has long been to completely depreciate EJB. It should have been done as of Java EE 7.

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

-------- Original message --------
From: Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>
Date: 10/14/17 4:55 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J

Hi,

I totally support the idea of EJB services moving to CDI, and I want to participate on that when work begins. Is your idea to totally deprecate EJBs or do you advocate for maintaining things like TimerService from them? I believe the EJB brand should be abandoned as lots of people still associate them with a dark past.

On JMS, at least the CDI alignment work should be released IMO, as it's needed for EJB decoupling. Onwards, do you (you and your team) expect JMS to be adaptable to the new cloud messaging? Payara has done some JCA resource adapters for them [1]. I wonder if JMS could handle the new systems. Perhaps with the new more open process, some representatives of those libraries would like to participate there.

Wrt Security, I'm pretty happy we now have a solid foundation that is user approachable, which didn't exist before. I personally missed some more vendor participation there, which again I expect to change with a more open process and maybe even co-leading as you suggested.

One thing I recall was discussed as problematic when talking about JSR 375 and JWT was that the GlassFish cannot depend on any non-RI or non Java library (I don't know the exact terms). Making JWT easy to use would require an external library and that was going to be a problem for Soteria.  I imagine we will be able to change even those rules, which will accelerate some things a bit.

Btw, there's already a good example of JSR375+JWT available at [2].


Regards,

Guillermo González de Agüero
[2] https://github.com/javaee-samples/javaee8-samples/tree/master/security/jwt

El vie., 13 oct. 2017 a las 20:49, David Blevins (<dblevins@xxxxxxxxxxxxx>) escribió:
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




_______________________________________________
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