interceptors...

[squirest]

Ok,

JBoss interceptors (I think) are done so that the invocation object is passed between interceptors that have a ref to the next interceptor in the chain.

Thus they do a getNext().invoke(invocation).

Why doesn't the invocation maintain it's own position in the chain (which interceptors have no access to)?

In order to pass the invocation along the interceptors would do something like this:

Object invoke(Invocation inv)
{
// do work
// decide to continue the chain
return inv.invoke();
}

Is there something inherently bad about that?

Trev

[davidjencks]

What advantage would there be to this? I thought about it and concluded it would be harder to configure and understand what the configuration was, for no apparent gain. (I was thinking about the ejb interceptors in jboss). I'm not sure if the jmx interceptors have any state (per stack, not per invocation). I like the idea of having the possibility of configurable instances of interceptors, so each stack gets its own instance of each interceptor in it. With this design I don't understand why you would want the list of interceptors in the invocation rather than in the linked list of interceptor objects. If the interceptors are all stateless singletons that you want to share among all possible stacks, your proposal makes more sense.

[squirest]

Thanks for the reply David.

I'm not convinced either way, so it's not a proposal at all - just something that's been rolling around in the back of my head for a couple of hours.

The stateless singletons one feels right because I think it can be used in either way. The stateless not-so-singletons of the current ejb interceptors is, of course, already there and working so it kinda wins.

I'm curious though, why do you think it would be harder to configure and understand?

Trev

[davidjencks]

Thinking about it more I'm not sure it makes much difference. I haven't tried it, so my hunch that it would be simpler one way or another has no evidence. If there is state information (per-stack) needed for the interceptors where would you put it and would this argue for one or the other traversal iterator? I've thought in the interceptors would be a good place, however marc I think wants to put it in a hashmap in the head of the stack.

[marc.fleury]

Yeah,

this is what I call the "post-modern" container design. It will be important for very tight memory footprints (read embedded).

When all is said and nothing done, interceptors are purely stateless constructs. It happens to be that we put a lot of contextual information in the container (this is your cache this is your persistence engine, this is your metadata, this is your security proxy) and this is what I described in Sydney as being the "where is my mommy" approach to container design. All the interceptors are linked to a container. Everyone goes to this static container (all interceptors).

The point on "configuration" is a lot of boloney (made in security for example), the pointer to a given contextual resource should live in the Invocation object. The interceptor takes its given configuration from it, right now it is static and that is a weakness. I.e. the interceptor would LOAD its configuration as the invocation goes through, all cached of course. The point about ease of configuration is just as invalid btw, you can have EXACTLY the same amount of information and keep the series of pointers in the Invocation as opposed to the static "container". "container" then becomes an object associated with a given ObjectName and it is a gateway to a set of pointer (just like it is today) but it leaves in a map association with the ObjectName and travels through with the Invocation.

This is the post-modern container.

I am afraid of unleashing it yet as people like the "where is my mommy?" approach of the current container.

Following my own "so if there is pain, where is the gain?" approach to decisions, I can only justify doing the post-modern picasso container if we go embedded.

This will be *very* relevant for people who want to embed JBoss in *TIGHT* memory footprints, and will be the basis for MBoss in JBoss4.0

Repeat after me "ooooommmmmM!"

marcf

[squirest]

Thanks Marc,

At least that validates that I wasn't missing something.

It also means that my doodles of 2 contexts in the invocation object (one caller context, one mbean context) aren't too far off the mark.

Trev