For logging purposes ;) need...early... coffee.
marcf |-----Original Message----- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, October 02, 2001 9:13 AM |To: Rickard Öberg |Subject: RE: [JBoss-dev] JMX service architecture: next gen++ | | ||It should be. So then you will instead have n number of "Tx-EJB-style" ||MBeans for each configuration of it that you want to be able to use. | |not necessarily, I wasn't probably very clear in my previous emails, |a lot of the configuration is in the metadata used by the |interceptor today and that data can be pegged with the MI. | ||There is a stacking problem here though. If each interceptor is supposed ||to know which interceptor comes next in the chain, then you will need | |Who said that it would work like jboss2? reread my email, I talk |about a "stack of object names". | |That stack is essentially a map of the interceptors you are going |to go through as an MI. That stack is not harcoded in the |interceptors but in the gates where the MI is created. What type |of MI are you ? you are going to go through A-B-C-D. What type of |MI are you? you are going to go through C-D-Z. | |Can you hear me? Can you see me? | |Ok for work! | ||one instance per *chain configuration*. I.e. if you have two MBeans ||being served by the same chain, and then want to modify the chain for ||one of the MBeans, you'll have to duplicate the chain and make the ||modification. It would be messy. | |I don't think so. | ||The only way I can see to get around that is to have the interceptor ||chain interleaved with a configuration interceptor. | | || ||Example: ||MBean XYZ wants the interceptor chain A,B,C (where C handles the call). ||Somehow this config info is given. An interceptor stack management MBean ||(MGMT) knows this, and for each incoming call the actual runtime chain ||of invocations looks like this: ||1. Connector.invoke (incoming call) ||2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in ||chain) ||3. A.invoke (do the A stuff, delegate back to MGMT) ||4. MGMT.invoke (determine that the chain has progressed past A, delegate ||to B) ||5. B.invoke (similar as 3) ||6. MGMT.invoke (same as 4) ||7. C.invoke (similar as 3, delegate to XYZ through reflection) ||8. XYZ.invoke ||9. return through interceptors ||10. Connector.invoke return result | |That is a way, but is this better than giving the map at the |beginning? You save on a ton of calls and you still have the |dynamicity of the configuration (update maps == (LinkedList of |ObjectNames)) | ||This is the only way you can get away with having a finite amount of ||interceptor MBean instances. If each interceptor is aware of the next in ||the chain, as in JBoss2 EJB, then you will have the config explosion ||problem (i.e. each interceptor will have the state "config+chain ||knowledge" instead of just "config"). || ||See what I mean? | |Yes, right analysis on the wrong hypothesis. | ||To get this to work the interceptor chain needs the following meta-info ||in the MI: ||1. Final MBean to invoke (XYZ in above case. this identifies the chain ||to use) | |OBjectName as identifier. Map of "maps to component" where |essentially we store the metainformation we used to use in the |container of jboss2. | ||2. Point in chain (0,1,2,3 in above case. this identifies which ||interceptor in the chain to delegate to next) ||3. method ||4. arguments ||5. custom meta-data(?) | |On 4. I got this idea from "Dresdner Bank" in London with the |project "open adaptor". You might want to check it. I think |their view of the system world is a bit soft but the logic is |there and is kind of relevant. They described random payloads as just |Object[] | |in their case I think they typed the payload as some silly object |DataObject[] or something like that, which I think is superflous. |Again we are doing that but on steroids and with a clearer system |head (they use properties to configure the stacks) but the |"philosophy" is known by the bank guys. | |On 5. custom meta-data might be interesting, at least in the |navigation structures of it, I don't know. | ||This way you can take maximum advantage of the fact that interceptors ||are largely stateless (and thread-safe), hence reusable for multiple ||concurrent calls. | |You got it. | ||Yes, true. As in above, the point-in-chain is very important though in ||order to externalize the actual chain from the interceptors. || ||Agree? | |almost see above, | ||It would require the above to work I think, but it's definitely doable. | |almost there rickard | |marcf | || ||/R || || ||-- ||Rickard Öberg ||Software Development Specialist ||xlurc - Xpedio Linköping Ubiquitous Research Center ||Author of "Mastering RMI" ||Email: [EMAIL PROTECTED] || _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
