Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Tomitribe commitment to EE4J
If we create alternatives and deprecate the EJB ones, of course we must make the former equivalent to the new ones, the way JSF @ManagedBeans used to work.

EJBs might be deprecated and finally pruned once we have alternatives. I expect good community reception for that news.

Perhaps an option would be to create an "EJB CDI Profile" that just defines how CDI should be used to provide the basic EJB services. Servers would be able to just provide it for compatibility. Most modern application just use the basic annotations, without making use of "legacy" features JNDI or XML descriptors and a CDI implementation would be relative simple.

Btw, lots of good ideas are emerging in this "Tomitribe commitment to EE4J" thread. What do you think about creating a new thread to discuss all of this with some more visibility?


Regards,

Guillermo González de Agüero

El dom., 15 oct. 2017 a las 9:10, <ondrej.mihalyi@xxxxxxxxx> escribió:

Hi,

 

  • I hear you, and this has been a concern indeed. There are more examples like the @RequestScoped etc annotations in CDI and JSF. With the above I didn't mean though to necessarily use the same names, but at least the semantically equivalent service that these annotations stand for. 

 

I would avoid introducing new annotations unless absolutely necessary. From usability perspective, developers don’t care about package names, they just want things to work. So it’s important to make the annotations, which now work only in EJBs, work also in any CDI bean. The exact same annotations, even if inside package with ejb in it's name.

 

It's a good idea to deprecated EJB-specific annotations like @Stateless or @Stateful once there’s an alternative. But I wouldn't introduce new annotations for timers – deprecation doesn’t remove old annotations and IDEs will keep suggesting them in imports, which is very confusing already for annotations like Singleton, ManagedBean, etc as mentioned by David earlier.

 

Ondro

 

Od: arjan tijms
Odesláno:neděle 15. října 2017 0:39
Komu: EE4J community discussions
Předmět: Re: [ee4j-community] Tomitribe commitment to EE4J

 

Hi,

 

On Sat, Oct 14, 2017 at 10:44 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

> 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 hear you, and this has been a concern indeed. There are more examples like the @RequestScoped etc annotations in CDI and JSF. With the above I didn't mean though to necessarily use the same names, but at least the semantically equivalent service that these annotations stand for. 

 

Probably we should not introduce annotations with the same name before deprecating the similarly named old one. At least I've added the deprecated annotation to the JSF ones for JSF 2.3, so the IDE should warn about them.

 

 

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.

 

True, but as mentioned deprecation of the older ones should help with that in cases where they actually are similar things. JAX-RS' @Produces is something totally different from CDI's one, so that's quite an unfortunate situation.

 

Many people frequently import the Java EE @ManagedBean when they mean to import the JSF @ManagedBean.

 

People should not want to import JSF's @ManagedBean ;) It's very much deprecated :P

 

 

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.

 

Totally pruning EJB would probably be the solution for that particular problem.

 

Kind regards,

Arjan Tijms

 

 

 



-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

 

 

_______________________________________________
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