Where is you design? David's design looks totally obvious to me. It is well understood, and based on our existing "real-world" experiences. To me it looks like you are the one invent "the perfect design/API". So can you present you invocation chain as did and show us the error in our logic?
-dain
On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote:
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Saturday, February 22, 2003 11:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing
since sliced bread
This is really boring and unpleasant, bill. We don't seem to
I am sorry I am boring you. Summarized, my major concern with the TX
refactor is that it will not work for clients that cannot have interceptor
chains (i.e. non-Java), but support Tx propagation (CORBA) for all
trans-attributes (specifically, NotSupported, and RequiresNew). I thought
Marc's vision for creating these generic, transport specific invokers was to
isolate the EJB Container from the transport layer, and I see this refactor
as breaking this vision.
The only way I see this working is if we have separate transport-specific
interceptor chains on the server to support non-Java clients. I wanted to
avoid this because this is what has happened when I put in support for
multiple invokers. Client-side interceptor configuration became bloated.
All this to avoid creating and passing over a TxId. See my point now?
===========================
As far as AOP goes, I'm hoping that as we implement services on top of the
Framework and apply the framework to JMX and remoting, the requirements and
API will be fleshed out as we iterate. I'd like the design of AOP to be
driven by "real-world" requirements and applications rather than what we
might think as the perfect (and probably bloated) design/API might be
currently. I'm not afraid of throwing code out or having to modify huge
amounts of code to iterate. Iteration is key. Allows us to get to market
quick and to quickly notice bad designs. Didn't somebody say "Release
early, release often"?
Bill
have a shared
understanding of how interceptors ought to work with local and remote
calls. Most of your comments make no sense to me, and I think
contrariwise. I'll try to explain my view one more time, and
I'll write an
interceptor framework that satisfies my understanding of what is
needed for
mbeans, ejbs, remoting, and aop (which I don't understand all that well).
If you don't like it and I can't understand your objections, I'll let you
indulge your previously expressed wish to write a transaction
manager. You
might also get that wish fulfilled if you say the following is
obvious. I
thought it was, but I don't think we have agreed on it. I'm writing it
down to try to form a basis for discussion, which is currently missing.
==========================
Dave's mental model for invocations.
Lets assume first you already have something representing the object you
are interested in (such as an ejb Remote interface object, mbean thingy,
aop-ized object, or some kind of proxy). Items marked with a * might be
removed for non-remotable objects.
Key to symbols:
\/ interceptor chain "invokeNext()" calls.
\/ || method/field access/... calls whose nature may vary depending on the application and that are not part of the interceptor/invocation framework.
\/
\/ calls between "segments". These are of the form invoke(invocation)
on a particular object found by the current interceptor.
.......... sequence of interceptors in a chain.
||
|| transport mechanism. For a remote object, this is the boundary
between client and server.
===========================
Some program does something on the "object"
\/ ||
The Object
\/ ||
Something that knows about interceptor chains and metadata. It looks at
the method (or field access, ...) call and its environment and determines
what interceptor chain to use. It constructs an Invocation object that
includes an iterator over the selected chain, the method call data, and
some metadata. Then it starts the invocation down the chain. I will call
this a Container. I believe it corresponds to your aop Advisor(s).
\/
Several interceptors (client side interceptors specific to the object/class you are calling)
.....
\/
* Transport selector interceptor. This examines the metadata and picks a
transport endpoint. It calls invoke(invocation) on the selected transport
endpoint. It does not call invocation.invokeNext(), so this may be the end
of the use of the original interceptor iterator.
\/ \/
* Transport endpoint. If this is a local "do nothing" transport, it may
simply call invocation.invokeNext(). Otherwise, it replaces the
interceptor iterator with one for the client side transport interceptor
stack.
\/
* Several interceptors (client side interceptors specific to the transport
endpoint you are calling. Examples would include the XAResource
representing a remote jboss instance (whenever the branch is created, you
still need an XAResource, and it needs to know about the method
calls), and
the clustering thingy that picks a remote server)
\/
* client side end of the transport. I believe this is essentially the
remoting framework.
||
||
||
* server side end of the transport. This may include some kind of
relationship with a thread pool. Lets assume the work is
dispatched with a
thread, no matter how it is picked and how
synchronous/asynchronous it is.
Anyway, the reconstituted invocation object has its interceptor iterator
replaced with one for the transport specific server side interceptors
\/
* Several interceptors (server side interceptors specific to the
transport. In my current dtm implementation, one of these would import an
xid in the invocation into the server side tm)
.....
* Target selector. Based on the metadata, this interceptor picks and
locates a target object, and calls invoke(invocation) on it. This is the
end of the transport specific server side interceptor chain.
\/ \/
* Server side target object. This is analogous to the current
server side
ejb Container object. It replaces the invocation's interceptor iterator
and starts it off by calling invocation.invokeNext().
\/
Server side interceptors. For non remotable objects and for "no transport" local remotable objects, the original interceptor chain would continue here.
.......
\/
Final interceptor. This uses the metadata and the method information to do something to the actual object instance we are working with.
\/ ||
object of interest.
Note that this requires, for remotable objects, being able to get two
interceptor iterators: one for the client side iterators, and one for the
server side iterators. For "local only" objects, you only need one
interceptor iterator. For objects that can be local or remote, looking up
the server side target object can be avoided if the client side
interceptor
iterator also includes all the server side interceptors: the (client side)
Transport Endpoint would (after determining that the call is local) simply
call invokeNext() on the invocation.
Lets see if we can come to an agreement on this much before we consider
constructors or how to get something representing a remote object.
Please remember that I consider this very obvious, but I don't think we
agree on it: I think if we did your comments would make sense to
me, and so
far they don't. Saying something like "don't be obvious" will indicate to
me that you are not interested in discussing this aspect of jboss
architecture with me, so I will take your recommendation and stop working
with interceptors, at least until my curiousity gets the better of my
sense.
david
------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
