|Seems logical to put the MBeanInfo object of the container in the thingy |that gets passed on. The interceptors can the extract whatever metadata |about the container they want from that.
yes, I agree. |Also, a stateless interceptor can be used for any container. If you want well that would really be the point. "Scripting the flow" in the aspect sense becomes quite trivial and manageable. |to just have tx's, you'd go find a tx-interceptor, and put it in the |invocation chain. The interceptor will extract the metadata it needs |about the container using the MBeanInfo, and do its work. That is the beauty of it, also we can leverage the metadata talk of EJB to add transactional demarcation to flows... any flow, any object, same tags, as we agree there, just that is really powerful. No additional work whatsoever, aspect programming for the masses. |If it is stateful, how will the interceptor get its metadata? I hope it |won't load it itself... that would make it dependent on the type of |object the interceptor chain is being used on (since it may be used on |things that are not EJB containers). sure, the EJB container would not be "real" except for a metadata repository of MBeanInfo describing the context for the invocation pertaining to the EJB kind. David, as I said previously, I work by increment, step by step professor, step by step. Right now the design that Rickard did is the one that you are defending. i.e. the stack of interceptors per instance. I am ok with that. In my roadmap I actually don't intend to replace it so far. So even though we are advocating the more advanced view it would require more retooling, and I am worried about the amount of work there. I don't want to get all mighty on your asses since as I said I don't think I will implement this in the near future. But the vision of Turin's slave machines is a powerful one, we are so close to implementing it in JBoss, and everyone seems to be pushing this view almost without knowing, that something in me says "do it"... apart from the elegance I think it would be an extremelly flexible framework. But again, too much for now. Please drop it now, let's avoid "empty" discussions and focus on the task at hand. marcf | |/Rickard | |-- |Rickard Öberg | | |_______________________________________________ |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
