[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-community] Tomitribe commitment to EE4J
|
I think explicit deprecation can mitigate the issue of duplicates. At some point, you do need to make some tradeoffs to move forward. And moving forward the platform to finally leave EJB behind is definitely worth a few tradeoffs. Can't tell you how many times the EJB acronym has stopped a customer from further considering Java EE as a whole.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 10/14/17 5:44 PM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
> On Oct 14, 2017, at 11:24 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
> > 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.
I'm not entirely sure. I have very mixed feelings about simply moving annotations around. @Transactional is at least a different name than @TransactionAttribute.
I repeatedly mistakenly import JAX-RS's @Produces when I meant to use CDI's @Produces and don't notice till deploy time. If I'm sleepy it takes me a while to put it together because imports are collapsed and hidden in the way IntelliJ is configured by default.
Many people frequently import the Java EE @ManagedBean when they mean to import the JSF @ManagedBean.
The concern I'd have is we could easily poison the well of EE by moving annotations around and improving them in a new package leaving an increasingly large number of confusing traps for people fall into, get frustrated with and drive them away. Doing this because we don't like the EJB package feels like EJB creating one more mess for us. A mess that only people in the know will understand.
-David
_______________________________________________
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
