Hi,
I think we agree.
In particular, I have no problems with no
differential metadata for interceptor chain
configurations.
Also, I am glad that you like the concept of
special purpose interceptors and plugins for
bean-aware special-purpose containers.
But maybe I was not precise enough when speaking
about protocol in the interceptor chain. This is
just an attempt to put some theory behind what
we are actually doing here.
Like you pointed out this is implicit, as it is
nowhere documented nor explicitly enforced.
The protocol I am referring to exists between any
two adjacent interceptors in the chain, so there
are actually a number of protocols in the chain.
Part of the protocol is enforced by static language
constructs (ie. the interceptor must have invoke()
and invokeHome() methods), but that is not very
interesting when discussing interceptor chain
configurations. What is more interesting is the
part that you refer to as "kernel developers common
sense". Though not documented nor enforced in the
code, this becomes relevant when configuring
interceptor chains.
I'll try with a definition:
The protocol between two adjacent interceptors
in the interceptor chain is the set of invariants
that exist on the border between these two
interceptors.
One implication of this definition is that if an
interceptor does not change anything (ie. a purely
readonly interceptor, for logging or debugging), it
speaks the same protocol before and after. I guess
MetricsInterceptor falls into this category. Such
an interceptor could therefore be placed anywhere
in the interceptor chain. (At least when it comes
to the correctness of the chain. MetricsInterceptor
would log slightly different metrics.)
Most interceptors only do a small, well-defined
job, and passes all other data (and thus their
invariants) unaltered. This means that the protocol
between adjacent interceptors A and B also depends
on the the protocol before A (and thus possibly on
all interceptors in the chain before A). And since
this is bidirectional (invariants about return
values and exceptions are also part of the
protocol), the protocol between A and B also
depends on the protocol after B (and thus possibly
on all interceptors in the chain after B).
Now, having established that the protocol between
adjacent interceptors A and B can depend on the
entire chain configuration, it is obvious that the
notion of protocol isn't very useful for telling
if a given chain is correct. But that would be a
hard job anyway as we would have to explicitly
know all protocol requirements before and after
every interceptor, as well as the protocol changes
every interceptor introduces in both directions.
But the notion of protocol could be useful for
knowing some cases when a given interceptor chain
is *not* correct: For that we only have to focus
on a single invariant at a time, and how the
interceptors in the chain change that invariant.
Taking the BMT example again:
We know that at the start of the chain, we have
INV(MI.EnterpriseContext not set)
and that before BMT interceptor we must have
INV(MI.EnterpriseContext set)
for the BMT interceptor to work correctly.
Since the InstanceInterceptor is the only
interceptor changing MI.EnterpriseContext, we
can conclude that the chain will not be correct
if we do not have InstanceInterceptor before
BMT interceptor.
I'm not calling for any kind of automated
correctness proof, or even formal documentation
on these invariants.
But maybe a simple javadoc comment here and
there would make these requirements a bit easier
for newcomers to understand.
For example: In BMTInterceptor "this requires
that the EnterpriseContext has been set on the MI
on entry", and in InstanceInterceptor "this sets
EnterpriseContext on the MI."
Best Regards,
Ole Husgaard.
marc fleury wrote:
>
> |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.
> |
