marc fleury wrote: > |should not need to know or store the interceptor-specific state info for > |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. > |In particular, this conflicts directly with the security proxy interceptor.
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 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. 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). > |2. (possibly an implementation issue, but real at the moment). Calling > |mbeanserver.invoke is _wayyyy_ slower than a direct method call. On my > |machine, 100,000 iterations in 10 sec compared with 0 sec. I think this > |will be a significant performance problem. > > are you benching dynamic mbeans or standard mbeans? the dynamic mbean *is* a > direct method call (plus a lookup in a map, big deal). The standard mbean > is a reflection call which is slow but we aren't using that as the bus. Very Important Point. > I prefer the lindfors/oberg approach to this with model mbeans. The beans > will probably point to an ejb that has a persistence engine that reads xml > files like the ones we have. With that you have clustered mbean > configurations. 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). > I am going back to my linux box, over and out, will read stuff > tomorrow/tonight, give me some time with this, we will deal with the > interceptor chain when we really need to... down the road, one step at a > time, professor, one step at a time. 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. /Rickard -- Rickard �berg _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
