Re: [ee4j-community] Tomitribe commitment to EE4J

[Adam Bien <abien@xxxxxxxxxxxxx>]

> On 16. Oct 2017, at 12:53, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
> 
> Hi
> 
> On Sun, Oct 15, 2017 at 6:06 PM, Adam Bien <abien@xxxxxxxxxxxxx> wrote:
> 
> +1 to move @Transactional to concurrency spec. However: @Asynchronous should also define in which (Managed)ExecutorService the bean is going to be executed.
> 
> Did you mean "+1 to move @ Asynchronous to concurrency spec."? ;)

Yes, sorry for that.
> 
> But indeed, one of the enhancements that would be at the top of my list would be to specify the thread pool and/or service. Don't specifying anything would then give you the default pool/service.
> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
>  
> >
> >
> > In JSR 375 we (EG) unfortunately did not go into any aspects of modern rest security, which is a real shame.
> >
> > Yes and no. There are no specific authentication mechanisms provided such as OAuth2 or JWT, but the spec was really careful to make sure it does work well with REST endpoints. The RI specifically tests for this. See https://github.com/javaee/security-soteria/tree/master/test/app-jaxrs
> >
> > With the primitives that were put in place it's easy to do something like this:
> >
> > http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
> >
> >
> > 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.
> >
> > I'm not so sure if it really fell onto a trap of any kind.
> >
> > There were simply many issues to be addressed and only so much time and resources available. The artefacts that were specified were basically the low hanging fruit and addressed basic gaps in the existing specs.
> >
> > 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.
> >
> > Absolutely, and in my mind that was always the idea basically. It's certainly what we had in mind for Payara.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> > 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
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> > 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
> 
> _______________________________________________
> 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