|But isn't the state that the security interceptor uses really meta-data |about the container? Shouldn't the interceptors get all meta-data from
afaik yes, and getting that information from the invocation pointers to the container (container here as a repository of metadata) is a way to go. |the *container*? If that is done, you'd get very clean separation of |concerns, where the interceptor act upon the meta-data, but is not |responsible for the actual meta-data. To me that seems more natural. yes, I agree. |So, the point isn't that the security interceptors should be stateless. |In fact, they may very well be stateful. However, they should not have |state *particular to any one container* (compare with Stateless Session |Beans). Following Turin, the state here is really context of the state machine, there is no context that stays with the machine once the invocation is gone through. If there is, it is in "cache" (think EJB) not in the interceptors. |Also, the Model MBeans would be responsible for reading the meta-data |from XML, which would then be provided through the standard methods |(getMBeanInfo) to the interceptors. This allows the interceptor/state |decoupling mentioned above. If the meta-data moves to RDF with |namespaces you could also have multiple aspects of a container in *one* |XML file (I'm not sure why people haven't done this already). | |To me the only reason to use multiple XML files is that namespaces |aren't used. If namespaces were introduced it should be trivial to merge |them all into one (ejb-jar.xml). hmmmm you have been pushing this RDF thingy for the past months, if it does indeed allow for a "one file" admin, it might be worth it. Right now we are going exactly the opposite way with the full file split across many little files, possibly in sars... interesting |Do take time to look into Aspect Oriented Programming if you have time. |Volume 44/Issue 10 of Communications of the ACM |(http://portal.acm.org/toc.cfm?id=383845&type=issue&coll=portal&dl= |ACM&idx=J79&part=magazine&WantType=Magazines&title=CACM) |have lots of great articles on the subject, and there are lots of |parallels with how JBoss works already. Yes, Aspect programming is the compilation heavy approach by PARC to "meta-programming". If you read this carefully you see that scripting is probably the middle ground between compilation heavy PARC and XML light EJB. Research but there is really no reason why intercepting mbeans wouldn't be close to it. marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
