Line 3 was replaced by line 3 |
- __XtC Views about EJB 3.0 Specification__ |
+ __XtC Views about the EJB 3.0 Specification__ |
Line 5 was replaced by line 5 |
- A lively and stimulating discussion resulted. The attendees were split roughly evenly between those who described themselves as broadly positive and those broadly sceptical about EJB but both sides contibuted good ideas to the effort. |
+ The attendees were split roughly evenly between those who described themselves as broadly positive and those broadly sceptical about EJB but both sides contibuted to a very stimulating and useful discussion. |
At line 6 added 1 line. |
+ At the end of the evening, we took a vote on the many ideas discussed, to determine which three ideas had the widest support from the group. The three winners, in order of most-votes first, were: |
At line 7 added 1 line. |
+ * EJB 3 should make use of the Inversion of Control (aka "Parameterize from Above") pattern. This approach minimizes coupling between components that use each other and coupling between components and their container. It also greatly facilitates unit testing. |
At line 8 added 1 line. |
+ * A separate JSR should be launched to provide a test container for beans. This could, for example, provide a hook to call setRollbackOnly to facilitate tests for transactionality. |
At line 9 added 13 lines. |
+ * EJB 3 should provide a standard (portable) way to generate primary keys |
+ |
+ The first point is a significant departure from current EJB practice, but could provide clear benefits, as evidenced by its use in both the Spring Framework and Pico Container projects. |
+ |
+ Other ideas that enjoyed significant support were: |
+ |
+ * Eliminate RMI "pollution" in remote interfaces |
+ * Provide a standard way to invalidate cached entity beans |
+ * Allow polymorphic finder access across multiple types of CMP entity beans |
+ |
+ There is still a long wait before we have EJB 3, but these ideas are a good start. Thanks to all for participating. |
+ |
+ |
Line 12 was replaced by line 28 |
- [Here is the blurb written in advance of the event:] |
+ Here is the blurb written in advance of the event: |
At line 42 added 2 lines. |
+ ---- |
+ |
At line 43 added 4 lines. |
+ |
+ (Sorry, I didn't see these before the evening so they weren't discussed then but have given answers below. Please note that the answers are entirely my own and do not represent the expert group's or anyone else's official opinion. |
+ -Scott C.) |
+ |
At line 44 added 3 lines. |
+ |
+ No, I believe EJB-QL should and will stay alive and well. It has a fundamentally different job to do than SQL, even though I'm sure it will continue to be influenced by it. And the specification always provides backwards compatibility in any case. |
+ |
At line 46 added 4 lines. |
+ Have you looked at the changes to entity beans that came in version 2.0 of the EJB spec? Local interfaces have made a big difference in this area, so I suspect you already have what you are looking for. |
+ |
+ ---- |
+ |