|Well, it is also a way of seperating different
|pieces of work into different interceptors.
Typing has its strength (enforcing a protocol) and weaknesses (as we see in
detyping stacks).
|> However you don't put the persistence before the acquisition for
|example, it
|> just makes no sense (logically speaking it's absurd).
|
|This is one way of shooting yourself in the foot.
|
|I don't think it has been explicitly stated
|before, but we do have a protocol before and after
|each interceptor in the chain. This protocol
no we don't... implicit...
|includes restrictions on the state of the MI and
|objects that can be reached from there.
|
|If two adjacent interceptors do not have a
|compatible protocol, things simply won't work.
what protocol are you refering to?
Yes I "know" that if I reach this given interceptor and I don't have the tx
set then it falls apart, but where is that programmatically enforced? It is
"implicit" knowledge that I have built as a "container kernel hacker",
nowhere is that documented much less enforced.
The "Protocol" you refer to is "kernel developers common sense". A user
doesn't know that protocol.
|
|An example:
|The protocol before the BMT interceptor says that
|the EnterpriseContext in the MI must be set.
|The protocol after the InstanceInterceptor says
|that the EnterpriseContext in the MI is set.
|So, if BMTInterceptor comes after InstanceInterceptor
|this is fine.
|BMTInterceptor can only come before InstanceInterceptor
|if some other previous interceptor did set the
|EnterpriseContext, otherwise the protocol would be
|violated. (Don't ask me what the II then is supposed
|to do if some other interceptor does its job.)
Again, this is not specified anywhere, it is our understanding of the
sequence of manipulation that needs to happen. But there was "no protocol"
written down.
|Similar statements about protocol can be made to
|show why the CMT interceptor has to come before
|the InstanceInterceptor, or why acquisition must
|come before persistence.
Ok I think I understand what you mean by "protocol". Yes there are so many
ways to make the container work and a careful analysis of the contracts in
EJB yields a series of stacks that in their layout implement a "protocol" of
steps to be taken by a container as it interacts with the bean. Nowhere,
outside the meaning of the spec and our layout of container is this
specified. It is total implicit knowledge (and even I have to think to
rebuild why CMT is before acquisition and BMT after or the other way around
I can't remember, see?). This is knowledge you don't want to expose in a
XML file, outside the "this is it, don't ask why". Between rickard that
puts CL mechanisms in XML and your "stacks" I really feel like the
"user-friendly" XML defender against evil waves of madness you guys are
throwing... let's keep the non-sense at a minimum.
|> It is a "freak" container. Period.
|>
|> Bottom line, there is a finite set of valid XML configurations.
|>
|> Which is the point about "relevance" of the interceptor layouts.
|
|For complete EJB conformance (nothing less, nothing
|more and nothing custom), we have one and only one
|valid interceptor chain configuration for each kind
|of container (when counting CMT/BMT as seperate kinds
|of containers). In such a case, there is no need for
yes, pretty much.
|configuration, as the interceptor chain might just as
|well be hardcoded. This is where we are today.
correct.
|When interceptor chain configuration is possible, and
|the configuration is changed from the default, we get
|some kind of "freak" container. I think these can be
|put into three categories:
Ok for me "Freak" container is only the C/ category. A container that
"isn't real" it is just a LinkedList of interceptors that doesn't do
anything useful spec wise.
|A) Working EJB compliant containers. An example of
|this could be a user adding a debugging interceptor
|somewhere in the chain to tell what is going on
|there. Another example could be replacing one of the
|standard interceptors with another interceptor that
|does the same job, but in a different way.
Yes, this is very interesting. My initial point is that even to specify
something as simple as "put a logger in front" or a "cache CMP in the back"
you need to specify the whole stack again, whereas we the container factory
we would just add one line. That is the price we pay for "externalizing".
I was just pointing it out, there is no differential metadata here, period.
No big deal, get over it.
|B) Working, but non-compliant containers. A (not very
|good) example of this could be replacing the
|TxInterceptorCMT with another interceptor that does
|not lookup metadata, but just assumes all methods have
|transaction attribute Required.
Well strictly speaking this would be a valid container.
Remember that our container can be "bean based" in its configuration. So in
fact a "non generic" plugin and interceptor is still something that is valid
from a spec standpoint. I was teaching container development to a bunch of
guys and we did a "CMP engine" that was TUNED to the class being deployed
and its dependencies. They would object that it was not a generic CMP
engine ala JBossCMP, yes... that is true, yet it was an EJB compliant
container for that bean and the CMP engine was TIED to that bean and TOTALLY
optimized in the queries for that bean. (we would maintain a cache of
queries and values for speedy lookup).
These are not freak containers !!!!!, not even "non-compliant" if they do it
right. IN FACT THEY ARE KOSHER! They are just "not generic". Throw another
bean at it and they die... but our modularity buys that flexibility and
power.
I would even say that I expect JBoss to have a great lot of success with
that kind of "optimized" bean-aware container. It is like the "Matrix"
where every bean has its own view of reality and the container surrounding
it. You should have seen the expressions of "ahhhh" when the guys got that
they could hack a container to be specific to a bean.
|C) Nonworking containers. The "persistence before
|acquisition" example you mentioned comes into this
|category.
These and B/ that don't work are the "freak containers", containers that do
not occur in nature and are pure user made aberations :)
|I think we can agree that category A is OK.
|Category C is bad, but we can see such things whenever
|someone tries to change something they do not
|understand. We probably have dozens of other things
|that can be configured to make JBoss nonworking, and
|it is hard to do anything about it if we want to give
|people the freedom to configure without restriction.
|Category B is not good either, but how can we tell if
|a given interceptor chain configuration belongs to
we can't tell, and they are non-generic, yet they are powerful optimized
beasts and their class is probably going to be a dominating one (think of
that "optimized persistence engine" my students built in a day). It is up
to the developer to ensure that the container stack is kosher. Plugins and
interceptors play a part.
Not your business nor is it your business to condemn them (but I don't think
it is what you mean)... in fact we should encourage them.
As you rightfully point out we can only validate out of the box configs
(which will cover 99.9 % cases :)
|this category (or category C), if we do not even know
|the internals of all the interceptors in the configured
|chain? And do we really want to stop people that want
|non-compliance in their own private configuration?
|
|
|Of course, JBoss should only ship with interceptor
|chain configurations in category A.
yes, correct.
|Also, it might be a good idea to warn people that
|changing the interceptor chain configuration from
|the default is advanced and may lead to non-compliance
|or a non-working container.
sure, I would say that, I would also down play it.
|But I do think that we should be liberal about what
|interceptor chain configurations should be allowed
|to leverage the full potential of interceptor chains.
I agree, Ole,
marc
|Best Regards,
|
|Ole Husgaard.
|
