This is really a discussion for the openejb mailing list, but since
you asked here I'll respond here.
On Jan 20, 2006, at 11:17 AM, David Jencks wrote:
On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote:
On Jan 20, 2006, at 9:46 AM, David Jencks wrote:
Personally I am not ready for 1.1 to be frozen.
Also, there is at least one major bug (tomcat cross-context
dispatch) that needs to be fixed and I haven't seen any progress
on it.
The nature of your change might affect other peoples opinion on
this also, what are you planning?
I am working on splitting the OpenEJB container into one object
for each deployed ejb and a set of share invocation processing ejb
containers. This is a refactoring of internal interfaces well
below the layer our users see.
Does this mean there will be one interceptor stack for each ejb
type, shared among all the e.g. stateless sesssion ejbs?
By default, yes. The idea is you can deploy extra invocation
processors that have different QoSes configured and then you assign
an ejb to the processor you want.
What is the advantage of this design?
I think the important important advantage for OpenEJB is that this
change aligns the 2 code with the 1 code. The other big advantage is
that it the job of a deployer is simpler because the most complex
configurations (like caches) are placed on the invocation processors
which will be defined using he generic gbean xml tags.
I can think of some disadvantages compared to our present design
but no advantages. Probably just a lack of imagination, but I'd
really appreciate discussion of architectural changes before the
code arrives.
The architectural change is to split the current EJB container into a
service for each EJB and a shared service for invocation processing.
If you want to have a discussion on this, we should move to the
openejb dev mailing list.
-dain