EJB 3 Q4 2007
This document outlines the strategy and direction of EJB 3 for 2007 quarter 4 (and beyond).
Overall Goal
The overall goal doesn't change:
What we need is an implementation which is easily maintainable, robust and fast.
But it's important to note that we want it in that order.
Maintainable
The code must become better maintainable, so we must improve on readability.
One aspect of this is the unit tests. The unit tests are too large and unwieldy. In most of them we try to test to much at the same time.
In every unit test we should document the intention of the test. So that when we have regression or failures we can ascertain whether the test is incorrect or any refactoring is off.
On the code base itself I want to see more comment. Not comment in the form of 'this code does...', but why is this code here. This could be a reference to the specification, Jira or a descriptive reason.
Better match up between the code and the specifications. If the specifications says that a bean can have one remote interface, I want to see a matching Container.getRemoteInterface method.
Note that example of resolving references from Q3 is still under debate. Scott and Adrian want to have more MC involvement.
Robust
More precondition checks, either with assertion or IllegalArgumentException.
Use assertions for checks that have no relation to the end user. And only use methods on an object if the object is immutable. For example checking that the length of a String parameter isn't 0 in a constructor.
We're working with a couple of developers on the same code and just assume the other guys are morons when they start using your code.
For all checks that are in place make a reference back to why this check is there. A message "Could not resolve beanClass method from proxy call" will get me nowhere. (Again use the moron assumption.)
For end user exceptions a reference to the spec or Jira will do.
Even more checks on invariants (keep an eye on the state), so we know what is available when in classes. Do an assertion in Container.getRemoteInterface that makes sure the container should know this by now.
Fast
ToDo
Don't let yourself be tempted into going after this yet.
Separation of Concern / Better OO Design
The use of our meta-model
How do we use our meta-model? For example ResourceHandler uses both XML and annotations. We should structure a flow of data where one dataset leads to one other dataset and not use a mix and match. See also InterceptorFactory (EJBTHREE-896).
Progress is being made here by unifying the meta data and getting a set of deployers which do the transition from a meta data model to a runtime model. The question that remains is how the runtime model interacts with meta data.
Component Based Development
We need to stop building stuff for the monolithic JBoss Application Server and start making components which are reusable (at least in AS 4.2, 5.0 and Embedded). The components must also be ready to be brewed into goji berry juice, so everything must be build with Maven2.
For this reason projects/ejb3 has been setup. Each of the components therein has an independent test suite.
cache : provides a mechanism to work with passivatable stateful objects
pool : memory pooling for use with stateless objects
Some other not yet flashed out components:
aspects ? : all aspects in one (bad idea?)
core ?
injection : injection for POJOs based on annotations or meta data
remoting : the EJB 3 remoting aspects
General Rules
Time boxing
Although time boxing has been dropped on us. I don't want to say that we will do time boxing perse.
I found a better (and shorter) piece on the triangle here.
For the most part we must try to better institute time boxing into our development process. That means we should use a strict regime on Jira issues in conjunction with the MoSCoW model.
Blocker : drop everything you're doing fix it now
Critical : Must have
Major : Should have
Minor : Could have
Note that anything we 'Won't have' must be set to another fix version.
For scheduling purposes every issue in Jira should be estimated. Just make a rough guess and calculate some slack within that guess.
The main problem I see is that as we try to change the solved puzzle it becomes harder to make the pieces fit again.
Notes
Always refer to an EJBTHREE issue in a commit message.
For commits in JBPAPP refer to the JBPAPP issue.
Branch_4_2 is frozen. It must remain backwards compatible, so do not change any unit tests, only add new ones.
Q4 Goals
AS 5
For AS 5 Beta 3 we must be API ready. This means that the JBoss EJB 3 Extension API must be frozen before then.
TCK 100%
We need to get a certified TCK. This means we need to create a proper EJB 3.0 implementation, by the book. I don't want any discussions on the intention of the specification, it is what it is. There are some parts which are superfluous (4.7.1), plain wrong (4.7.3 should refer to 3.4.5) or gray area, in those cases we will have a discussion.
Note that TCK certification doesn't mean the product is usable in the field. Keep this in mind.
--
Rules are meant to be broken, but the reason better be real good.
Comments