Re: [ee4j-community] Tomitribe commitment to EE4J

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Hi Guillermo!

> On Oct 14, 2017, at 1:55 AM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
> 
> 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.

I personally wouldn't be advocating continued use of "EJB", but yes ensuring things like the TimerService are separate and standalone.  Let's call them services vs components.  They should be usable in CDI (or other places).  There isn't a strict need to tie them to EJB specifically.  You should be able to use @Schedule on a CDI bean.

In terms of deprecating EJB, I'm not sure any work needs to be done :)  Its reputation has deprecated it fairly well.  The brunt of the work I see is separating out the good parts.  This will be a lot of TCK and spec work to be honest.

> 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.

On adapting the JMS API, I think it's worth a look at least.  Writing and standardizing new JCA resource adapters is also a fine option.  I think we have options since the annotation-based reforms were made for JCA resource adapters/MDB containers in Java EE 7.

> 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.

There's a handful of things that prevented that vendor participation.  IP flow has been a major one, to be honest and transparent.  The person/organization who starts the JSR owns all the IP of all ideas submitted, which effectively means each vendor who participates is transferring ownership of any IP submitted on the JSR list to the lead.  The resulting JSR IP then has to be licensed back to the vendor, usually for a fee.  10 years of transferring all your best ideas to your competition puts you in a bad spot legally and commercially.

Hence JSR-375 eventually only ever attracted independents.

This is all being fixed right here and now with EE4J and is an aspect worth understanding and celebrating.  With that understanding it puts a new level of appreciation for what Oracle is doing by donating all the IP collected under this model to Eclipse.  That's simply a side note as I think Oracle takes it on the chin a bit too much sometimes.  This move is bold and generous and levels the playing field in a way most people don't understand or appreciate.

The bottom line is we will see a new era of EE where vendors will be able to participate fully, without the same legal and commercial restrictions.

> 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.

I never understood the library issue to be honest.  The Java 8 JVM, without the JCE extensions which are illegal or restricted in some countries, can do HMAC-SHA256 and RSA-SHA256 which is enough for any real-world JWT usage.

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

That's a great start.


-David