Issue Details (XML | Word | Printable)

Key: EJB_SPEC-17
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: marina vatkina
Reporter: reza_rahman
Votes: 17
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
ejb-spec

Prune EJB 2 backwards compatibility

Created: 08/Jul/11 06:59 PM   Updated: 28/Jul/13 03:25 PM
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Time Tracking:
Not Specified

Issue Links:
Dependency
 

Tags:
Participants: arjan tijms, exabrial, marina vatkina and reza_rahman


 Description  « Hide

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.



exabrial added a comment - 10/Oct/11 02:46 AM

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


marina vatkina added a comment - 10/Oct/11 09:18 PM

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.


arjan tijms added a comment - 01/Dec/11 09:56 PM

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?


marina vatkina made changes - 06/Nov/12 04:12 AM
Field Original Value New Value
Link This issue depends on JAVAEE_SPEC-16 [ JAVAEE_SPEC-16 ]
marina vatkina added a comment - 08/Feb/13 10:37 PM

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


marina vatkina made changes - 08/Feb/13 10:37 PM
Fix Version/s Future version [ 15771 ]
Fix Version/s 3.2 [ 14833 ]
marina vatkina made changes - 05/Apr/13 12:12 AM
Assignee marina vatkina [ mvatkina ]
arjan tijms added a comment - 28/Jul/13 03:25 PM

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.