On Jan 16, 2007, at 9:01 AM, Alan D. Cabrera wrote:
On Jan 9, 2007, at 11:17 AM, Dain Sundstrom wrote:
* The deploymentInfo and securityIdentity are now final fields.
* When constructing a ThreadContext the deploymentInfo must not be
null.
* The primaryKey is mutable because ejbCreate for Stateful and
Entity beans changes it (we should consider just pushing a new
context).
Why not move these fields into the data map?
I was talking to David about this the other day. One thing I like
about OpenEJB is that is is very readable and easy to follow because
there has been a compromise between generic flexible code and static
inflexible code. The former is easy to extend and integrate, and the
latter is easy to read, understand and debug. There are a lot of
systems that go off the deep-end where everything is completely
generic, and it makes it almost impossible to learn the code base
because you must know the exact runtime layout components in memory
(e.g., the OpenEJB 2 interceptor stack). Other code bases, go off
the deep-end where everything is static, protected, and very
difficult to change. These code bases are very difficult to work
with because there is no where to extend (for example, the Sun ORB).
What I like about OpenEJB is that there are places to put your data
and there are hooks at the most important places to get your
processing in the execution path, but in general the OpenEJB code
doesn't use these, generic data structures and hooks, which makes the
code obvious.
In this specific case, these fields are final and it makes it obvious
that certain data is expected and that most if it will not change.
This is also a compromise between typed java fields which are fast
and untyped maps which are slow. The fields that are specifically
declared in the ThreadContext are used all the time and therefore get
a big benefit from being declared as a field.
-dain
