I'd prefer to copy the Geronimo list if the discussion moves. FWIW I think a
lot of folk that are on the G list would be interested. Since OpenEJB is making
the move to Geronimo (assuming it happens) I think it would be good to keep the
thread on this list so the history is cohesive.
Dain Sundstrom wrote:
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
