I’m a bit late to this fast-moving thread (and not caught up yet). This is a general brain dump regarding this thread up to this point.
1) Keep in mind that it is probably 5-6 months before EE4J is an established project with its first release available. As a part of that, the “expert groups” need to be set up, which implies a process for defining how expert group members are defined. We also need to define an EE4J release process where specs can evolve. In other words, we have to walk before we run :-)
2) Switching specifically to this topic, I think the over-arching goal is to get to one enterprise component model to simplify Java EE altogether. Explaining the intricacies of CDI vs EJB complicates the platform. In that context, I love this discussion. However, we need to execute on 1) before we execute on this.
2) Not that anyone is advocating this, but I do worry that simply taking the remaining EJB functionality and pushing it into the CDI spec just complicates the CDI spec. We’ve spent years trying to simplify and decompose the EJB spec. For example, when I see “@Monitored”, I naturally wonder if that should be moved to the MicroProfile Metrics spec.
3) We are going to constantly have this push and pull of moving quickly with pent-up desired features and retaining backwards compatibility within EE4J. Perhaps this is a good area to prove out how we do this. Or, is there lower-hanging fruit?
4) As I think Kevin brought up earlier, perhaps this should be covered in the existing EJB & CDI email aliases while we figure out 1) here first.
I have clients that still use EJB remoting as well. I suspect the vendors will continue to support these folks even if we ever manage to fully remove EJB from Java EE. I have to say though that I have seen these clients to be a dying breed. Most have moved to REST these days. Is it really worth carrying around the harrowingly complex EJB remoting implementation forward just to satisfy a tiny portion of the overall Java EE target audience?
Could you please elaborate your XML/CDI point a bit more? I can try to guess what the problem is, but it's best to better understand first.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- Date: 10/16/17 1:45 PM (GMT-05:00) Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
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
_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community
|