Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Deprecating EJB in Favor of CDI Services

Indeed good to move it here ;)


To sum up, we'd like to completely deprecate EJB and have CDI compatible replacements in place for most or the most useful things, including a few related concepts.

This includes:

1. @Pooled
2. @Asynchronous
3. @Timer / @Scheduled
4. @RolesAllowed / @DenyAll, etc support (technically not EJB, but EJB is the only one that supports those now)

Possibly:

4. Passivation control (?)
5. JPA Extended Persistence Context

Possibly not (?)

6. @Remote / RMI support

Most of these would be at home in the security spec. @Pooled might go to the CDI spec as well, but the CDI EG has indicated it wants to focus more on the bean model itself, and less on actual services.

@RolesAllowed and friends is (of course) best at home in Java EE Security.

Speaking for OmniFaces I can say that donating our existing @Asynchronous and @Pooled implementations to the Concurrency spec is no problem.

Though I work for Payara, I can't officially speak for them, but I would not be surprised if we would like to take up some of the other work for this migration as well (but this is my opinion and doesn't necessarily reflect that of Payara).

Kind regards,
Arjan Tijms












On Mon, Oct 16, 2017 at 4:52 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:

Moved to hopefully correctly named thread as requested.

On 10/16/17 5:19 PM, Jean-Louis Monteiro wrote:
Hi,

What about moving this interesting discussion into a dedicated thread?

Jean-Louis


On Mon, Oct 16, 2017 at 2:19 PM, Adam Bien <abien@xxxxxxxxxxxxx> wrote:
Why not  both: @MaxConcurrency and @PooledScoped?

But you are right: @MaxConcurrency is more important.

> On 15. Oct 2017, at 20:08, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
> I think @MaxConcurrency is by far more valuable than @PoolScoped and can belong in the concurrency utilities. The primary use case for @PoolScoped is for very heavy weight resources/objects that are not otherwise pooled - which means not needed for common cases such as database and JMS resources.
>
> 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 3:31 PM (GMT-05:00)
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
>
> Do instance pools still provide a real performance gain? I know Adam Bien did an informal test on Payara and the results where positive for EJBs, but I don't think the results are too reliable.
>
> WildFly disabled pools by default for some time ane the EJB spec doesn't even mandate a pool to exist. I doubt it's a really useful feature. An @MaxConcurrency would be more useful IMO that the pool itself (so different scopes can be used) while serving a similar purpose. And that again falls on the Concurrency Utilities side.
>
> Thoughts?
>
>
> Regards,
>
> Guillermo González de Aguero
>
> El sáb., 14 de octubre de 2017 21:07, reza_rahman <reza_rahman@xxxxxxxxx> escribió:
> Personally I think @Pooled/@PoolScoped is best in CDI. The remainder of the EJB functionality can be pretty cleanly rmed out between Java EE Concurrency and JMS/JCA.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: arjan tijms <arjan.tijms@xxxxxxxxx>
> Date: 10/14/17 2:24 PM (GMT-05:00)
> To: ee4j-community@xxxxxxxxxxx
> Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
>
> Hi,
>
> 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.
>
> As expressed previously on the Java EE spec list, I strongly support that too. In order to have a more consistent programming model to offer the user, these, and a few others should be re-implemented based on CDI and Interceptors.
>
> I think this can best be done in a similar way as @Transactional was done; basically have the EJB name and semantics, but add a few extra features and/or take away some existing pain points.
>
> At OmniFaces we started prototyping this a while ago. The intend was for those implementations to be a base proposal for inclusion in Java EE 8, but that never happened.
>
> See: https://github.com/omnifaces/omniservices/tree/develop/src/main/java/org/omnifaces/services
>
> Also note that we took a couple of steps to align JSF more with CDI in JSF 2.3, and that alignment story is far from done.
>
> Java EE Security as a new spec has been based fully on CDI from the start.
>
>
>  The former EJB should just be services that could be applied to any CDI bean.
>
> By that do you mean that you'd like to see @Asynchronous to remain in the EJB spec, but in a CDI version?
>
> Since @Transactional moved to JTA, I think it might be a better idea to move @Asynchronous to the Concurrency spec. Not sure about @Pooled though, but @Schedule and @Lock probably should be best at home in the Concurrency spec as well.
>
>
> 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



_______________________________________________
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