|Its fine to support sharing of stateless interceptors, but to say this is |the only |way interceptors should be handled forces a refactoring of exising usage |without sufficient justification.
Neither Rickard nor I are saying this. We are saying, gosh, most interceptors are generic (including the ones you are describing, it would just mean that some come specific to the bean, big deal, we don't preclude it), then let's factor them in a clean way we we can talk to them independenly through the JMX bus and thus offer trivial scripting of flows (you want to add transaction behaviour to an assembly, you can). There can be as many mbeans as there are security types. Even one per container, it is irrelevant but at least that metadata would be dynamically updatable (defeating one of the points rickard makes about "ejb"). Look for the umpth time, we are talking of code that won't materialize in the next coming weeks. I will go with the lindfors/oberg initial description of the stack, which is just what we have with some more flexibility in the loading of configurations. I need to turn off this email station : - ) marcf | | | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
