I am digging digging.
Something caught my attention Rickard. In the initialization of the plugins
you pass the container to helper classes (invoker, pool, cache etc).
However the interceptor don't have that information available (you don't set
the container).
Then it is access to metaData that I find puzzling, the helper classes will
be able to see it but the interceptors not, only through thread constructs?
Do they need any meta data information at all? can you do without metaData
or do you need the naming for example? in jBoss 1.0 I always had visibility
on ContainerMetaData which was a repository of all information about the
container (what you call metaData as bean in the container) and that was
visible throughout the invocation chain unlike the "interceptors here". Are
the interceptors stateless with respect to the metadata? (don't care) if not
it would quite simple to add a "setContainer" on the plugins (are they
shared, I think not since you seem to new them at every container).
Finally what prompted this question, since I was assuming a completely
"stateless design" is the existence of the BeanClassLoader that seems to
serve the only purpose of holding the root naming env and passing that
"contextual information" through the "thread" propagation. While I agree
that it needs to be stored somewhere, it is for me clearly a "metaData
thingy" and I am wondering if the sole purpose of this thing is to pass that
information in the thread to the "interceptors" since the others have access
to "pointer" information as opposed to thread attached.
In this case can't we set the container on the interceptors? (you new() them
so they are not shared and obviously not thread dependent) and speed the
stuff from Thread lookup (although I don't expect it to slow down much) and
clean that metadata a bit.
marc
