[EJB_SPEC-17] Prune EJB 2 backwards compatibility Created: 08/Jul/11  Updated: 28/Jul/13

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Type: New Feature Priority: Major
Reporter: reza_rahman Assignee: marina vatkina
Resolution: Unresolved Votes: 17
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVAEE_SPEC-16 Prune CORBA interoperability Open

 Description   

It has been more than five years since EJB 3/Java EE 5 was finalized. In terms of the technology industry, that's almost a life-time. At this point, I don't think it is sensible to continue to support the flawed EJB 2 development model. Pruning it in EJB 3.2 would significantly simplify the EJB specification/implementations going forward.



 Comments   
Comment by exabrial [ 10/Oct/11 ]

I couldn't agree more. CORBA and EJB2 should both be pruned. Jettisoning the deadweight would also lower the bar to getting a container certified EJB3.2

Comment by marina vatkina [ 10/Oct/11 ]

Nothing will change for EJB 3.2 certification even if we mark them as proposed optional. See the Java EE Platform spec for the details of the pruning process.

Comment by arjan tijms [ 01/Dec/11 ]

Would it be at least an option to move all text covering EJB2 material in the EJB3 spec to an appendix or even better to a separate document?

There is currently a rather large portion of the EJB3 spec still devoted to EJB2. It's intertwined with the main text, which IMO makes it unnecessarily hard for 'normal developers' to use the spec as a fallback reference guide.

Nothing will change for EJB 3.2 certification even if we mark them as proposed optional. See the Java EE Platform spec for the details of the pruning process.

What about in addition to EJB Lite defining another subset of full EJB called EJB Legacy Free, that excluded EJB2 and Corba?

Comment by marina vatkina [ 08/Feb/13 ]

Can't prune EJB 3.2 without pruning interop, and the latter is not happening in EE7

Comment by arjan tijms [ 28/Jul/13 ]

There is currently a rather large portion of the EJB3 spec still devoted to EJB2. It's intertwined with the main text, which IMO makes it unnecessarily hard for 'normal developers' to use the spec as a fallback reference guide.

I remarked this quite a while ago, but as a (rather late) example of this.

17.3.2 Method Permissions says the following:

Method permissions are defined as a binary relation from the set of security roles to the set of methods of the business interfaces, home interfaces, component interfaces, no-interface view, and/or web service endpoints of session and entity beans, including all their superinterfaces (including the methods of the EJBHome and EJBObject interfaces and/or EJBLocalHome and EJBLocalObject interfaces). The method permissions relation includes the pair (R, M) if and only if the security role R is allowed to invoke the method M.

This is rather wordy to anyone who doesn't even know (and wants to know) about anything related to EJB 2. E.g. the average person who started using EJB in version 3.

Without the EJB 2 references, the text could be:

Method permissions are defined as a binary relation from the set of security roles to the set of methods of the business interfaces, no-interface view, and/or web service endpoints of session beans, including all their superinterfaces. The method permissions relation includes the pair (R, M) if and only if the security role R is allowed to invoke the method M.

IMHO the latter makes it much easier to understand the theory that's being discussed. Note that this text is just one example. Large parts of the spec are (IMHO) unnecessary complicated to read because of all those EJB 2 references. For EJB 3 developers those are really not applicable and the reader has to mentally filter this noise away.

Generated at Tue Jun 02 15:36:38 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.