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

On second thoughts I should take a step back...

David - you started this thread, are you encouraged enough to initiate discussions on the CDI and EJB aliases? I know we've both gone down those roads before but maybe we can hope that something has changed now?

If you would rather I start it, I am happy to do so. Frankly I fully expect that we will be moving early implementation work somewhere outside of those venues as well as EE4J. Thankfully, I think we already have multiple such places. I think we have lost enough time on some of this work. As long as you and others are prepared to do so, I would rather get started what we can as soon as possible. Arjan - just wanted to check if we can use OmniFaces for this. You'll excuse my ignorance, but do you have a user forum of sorts for OmniFaces? If not OmniFaces, I can suggest another spot that was purposely created to house just such work.

Hopefully we will get to move the work to EE4J soon enough.

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

-------- Original message --------
From: reza_rahman <reza_rahman@xxxxxxxxx>
Date: 10/16/17 6:15 PM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services

OK, I'll try and shift the discussion to those groups. I think most people that have chimed in are already signed up to these or would be willing to do so.

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

-------- Original message --------
From: Kevin Sutter <sutter@xxxxxxxxxx>
Date: 10/16/17 3:15 PM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services

Reza,
No, MicroProfile would not be the proper place to discuss this topic.  MicroProfile utilizes CDI, but we don't direct it's content.  And, as far as how soon EE4J will be ready to house this type of discussion and work?  Well, you've seen it's been taking weeks just to get the top-level EE4J project created.  The Charter is up for vote on the 23rd.  After that, there will be a few initial Java EE projects moved over to test the waters and the processes.  Projects like JPA and JSON-B will be first (per Dmitry's post), followed by a handful of others.  The EJB project will be sometime after that.  And, whether CDI ever moves to Eclipse is an open question.

But, why not have these discussions on the existing expert group forums?  Until EE4J is firmly established, the existing mechanisms do exist and can be utilized.
https://javaee.groups.io/g/ejb-spec
http://lists.jboss.org/pipermail/cdi-dev/

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter

ee4j-community-bounces@xxxxxxxxxxx wrote on 10/16/2017 01:21:22 PM:

> From: reza_rahman <reza_rahman@xxxxxxxxx>

> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Date: 10/16/2017 01:21 PM
> Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
> Sent by: ee4j-community-bounces@xxxxxxxxxxx
>
> I agree I think we've discussed this topic enough for now. At some
> point in time we will need to figure out how to get the right people
> in one spot to discuss this.

>
> Turning this somewhat around though, how soon before EE4J becomes
> solidified enough to handle this sort of work? Until then, we can of
> course move some of the work ahead elsewhere such as simple GitHub
> project backed by a Google Group. It seems to me MicroProfile would
> not really be the right forum for this work? Or would it?

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

>
> -------- Original message --------

> From: Kevin Sutter <sutter@xxxxxxxxxx>
> Date: 10/16/17 2:09 PM (GMT-05:00)
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
>
> Hate to be a buzz killer, but is this the proper forum for
> discussing the future of EJB and/or CDI?  At least at this level of
> detail?  This discussion seems like it should be discussed with the
> EJB and/or CDI Expert Group members (and I know that not all of
> these members are subscribed to ee4j-community).  I would agree that
> the general discussions of how to move these existing efforts to
> Eclipse are worthwhile topics for this community.  But, the
> specifics being discussed in this thread seem to be a bit deep for
> the ee4j-community.  And, we're missing thoughts and ideas from the
> existing EJB/CDI expert group teams.
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Java EE architect
> e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)    
> LinkedIn:
https://www.linkedin.com/in/kevinwsutter
>
> ee4j-community-bounces@xxxxxxxxxxx wrote on 10/16/2017 12:49:11 PM:
>
> > From: reza_rahman <reza_rahman@xxxxxxxxx>
> > To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> > Date: 10/16/2017 12:51 PM
> > Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
> > Sent by: ee4j-community-bounces@xxxxxxxxxxx
> >
> > Would Adam's built-in stereotype option help? We could have a
> > slightly better named @Service annotations that basically does what
> > @Stateless does today?
> >
> > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> >
> > -------- Original message --------
> > From: John Hogan <jhogan515@xxxxxxxxx>
> > Date: 10/16/17 1:13 PM (GMT-05:00)
> > To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> > Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
> >
> > 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 EESecurity.
> > >
> > > 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 ourpassions.
> > >> > 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
> fromthe 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://urldefense.proofpoint.com/v2/url?
> >
> u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> >
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=0oODPnBPIlcsIzPxkHFpabWCaDXVv_W0dKdnqROZL2o&s=jadgTCiPgTq28s1GJMCloe4P9EgDP0YQoXh94r6_UBk&e=
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>
https://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=l90yu3KKB6CrVTRGeA3NXN9BklsdCYg-
> JZiBh3otgUM&s=QnTDHdTPU1QJIo5Ayopi9oA3bTfUNkPNXj0EBR3_STQ&e=


Back to the top