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

I see. So basically the work that Oracle specification leads did not want to do in JAX-RS? I have to admit I never really understood why they resisted that work so much. There is a certain type of REST client for which this is a very good fit...

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/16/17 2:01 PM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services

MicroProfile is working on a typesafe REST client which I suspect could cover @Remote and SOAP usecases in the long run.

El lun., 16 de octubre de 2017 19:45, Rudy De Busscher <rdebusscher@xxxxxxxxx> escribió:
Deprecating @Remote 
-> I have a large client with a custom ERP system which uses this. He won't like this!

Another thing which is missing
-> define interceptors in XML on some or all EJB.  There are techniques to do this in CDI but nothing defined in the spec.

regards
Rudy


On 16 October 2017 at 19:29, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
What exact EJB features do you miss?

Remember that you can use stereotypes to group annotations. You can create an @Service annotation that means @Transactional and @PoolScoped at the same time (similar to @Stateless). Does that mitigate your concern?


Regards,

Guillermo González de Agüero



El lun., 16 de octubre de 2017 19:13, John Hogan <jhogan515@xxxxxxxxx> escribió:
As long as there are canned equivalents to ejb features that we enjoy today ....  Sounds like I'm in the minority here, but I find many features provided by ejb to be extremely useful, ... and would rather not have to cobble together all the things with a bunch of cdi annotation.  Otherwise, a lot of common commonly used functionality is lost, things become harder to implement and easier to get wrong.  First do no harm ...

On Mon, Oct 16, 2017 at 12:48 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Also, there are some EJB aspects present on CDI (special treatment of session beans). Would it make sense to so an EJB MR and move them there?


El lun., 16 de octubre de 2017 18:28, Thomas Andraschko <tandraschko@xxxxxxxxxx> escribió:
A BIG +1
There are already some Servlet and JSF parts which should NOT be in CDI specs! We should not do the same again.


Am Montag, 16. Oktober 2017 schrieb Adam Bien :


> On 16. Oct 2017, at 17:03, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
> 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)

5. Forcing app server to gather metrics (e.g @Monitorable).
6. Introducing a standard Stereotype with @Pooled, @MaxConcurrency and @Monitorable

>
> Possibly:
>
> 4. Passivation control (?)
Indeed: hence all @SessionScoped requires Serializable it would be nice to know when it happens.
> 5. JPA Extended Persistence Context
This should work with @SessionScoped already.
>
> Possibly not (?)
>
> 6. @Remote / RMI support

+1 I would deprecate, better remove,  both.
>
> 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

cheers,

adam
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> 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
>
>
> _______________________________________________
> 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

_______________________________________________
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