RE: [JBoss-dev] Invocation and MethodInvocation
|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). h 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=383845type=issuecoll=portaldl= |ACMidx=J79part=magazineWantType=Magazinestitle=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
Re: [JBoss-dev] Invocation and MethodInvocation
marc fleury wrote: h 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 Well, namespaces can be used with or without RDF. It's just a very nice way to get multiple aspects of a particular element into one XML file without element name clashes. Simple too. |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=383845type=issuecoll=portaldl= |ACMidx=J79part=magazineWantType=Magazinestitle=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. To be precise, AspectJ is the compilation heavy approach. Aspect Oriented Programmin in general is more of a philosophy that can be implemented in numerous ways, the interceptor architecture of JBoss being one of them. The interceptors in JBoss fit really well with the notion of aspects in AOP. 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. Yes, scripting will make it easier to insert aspect join points. Good point. To me it seems like AspectJ has this scripting aspect to it, although it uses pre-runtime compilation to get it into bytecode. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |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). ___ 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
Re: [JBoss-dev] Invocation and MethodInvocation
danch wrote: When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? Bean instance, container, and client. Yes. It may only hold state that is relevant for the particular work it is doing, such how to do it. For example, an invocation monitor sending messages to JMS might have an instance variable with the name of the topic to send messages to. That name is not client specific, it is not instance specific, and it is not container specific, but it is nevertheless state. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|When we talk about 'stateless' interceptors, do we really mean |stateless, or do we merely mean stateless with regard to bean instance |and client? bean instance and client marcf |-danch | |Scott M Stark wrote: | | Any of the interceptors can be made stateless, its a question of the cost | of reassociating the state from the container meta-data and having to | cast from an opaque generic form to the data required by the interceptor. | The current state in the security interceptors is just cached |data derived | from the container meta-data. In the case of the SecurityProxyInterceptor | the derived data can be an expensive transformation of the container | meta-data. | ||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). | | | | | | ___ | 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|Bean instance, container, and client. Yes. It may only hold state that |is relevant for the particular work it is doing, such how to do it. For |example, an invocation monitor sending messages to JMS might have an |instance variable with the name of the topic to send messages to. That |name is not client specific, it is not instance specific, and it is not |container specific, but it is nevertheless state. And Turin calls them state machines. I would rather quote the genius that got it started than the wallpaper patterns of the itzy bitzy weeny bozos of today marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
They are talking stateless with regard to any container instance. - Original Message - From: danch [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 7:07 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |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). ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
- Original Message - From: marc fleury [EMAIL PROTECTED] To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 6:59 AM Subject: RE: [JBoss-dev] Invocation and MethodInvocation |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. Really, what am I cleaning up by moving container derived data out of the interceptors? The fact that the meta-data is in the container is simply a matter of choice. The security meta-data is really an interceptor property. No where in the codebase is the EJBSecurityManager for the container used but in the SecurityInterceptor and SecurityProxyInterceptor. The same is true of the SecurityProxyInterceptor. The custom securityProxy at the Container is also not used anywhere but in the SecurityProxyInterceptor and its supporting classes. By virtue of the fact that one can define interceptors per bean class we are supporting interceptors that are tied to their container in interceptor specific ways. Users are writing interceptors that have their own state based on data derived from container meta-data in an interceptor specific way, and the container has no knowledge of this state. |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. This is a restriction on the current view of the interceptors. You can argue that interceptors must be stateless. This simply pushes each stateful interceptor to develop their own session cache management layer. What are we gaining from this change in the interceptor model? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
On 2001.11.15 11:09:40 -0500 Scott M Stark wrote: I feel like its deja vu all over again. About a month ago I had this same conversation with Scott and concluded that having an instance of interceptor for each chain is definitely the way to go. Here are some reasons: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. I vote for instances of interceptors per chain. The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. david jencks - Original Message - From: marc fleury [EMAIL PROTECTED] To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 6:59 AM Subject: RE: [JBoss-dev] Invocation and MethodInvocation |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. Really, what am I cleaning up by moving container derived data out of the interceptors? The fact that the meta-data is in the container is simply a matter of choice. The security meta-data is really an interceptor property. No where in the codebase is the EJBSecurityManager for the container used but in the SecurityInterceptor and SecurityProxyInterceptor. The same is true of the SecurityProxyInterceptor. The custom securityProxy at the Container is also not used anywhere but in the SecurityProxyInterceptor and its supporting classes. By virtue of the fact that one can define interceptors per bean class we are supporting interceptors that are tied to their container in interceptor specific ways. Users are writing interceptors that have their own state based on data derived from container meta-data in an interceptor specific way, and the container has no knowledge of this state. |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. This is a restriction on the current view of the interceptors. You can argue that interceptors must be stateless. This simply pushes each stateful interceptor to develop their own session cache management layer. What are we gaining from this change in the interceptor model? ___ 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
Re: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. 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. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want 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. 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). /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
- Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 8:55 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want 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. 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). This is the crux of this issue. Some interceptors are stateful and are tied to the type of container they are being used with. The EJB security model is completely different than the Web security model. All the security related interceptors due is translate from the container specific model to the generic JAAS implmentation in fact. I can force a container independent model on the interceptors that show up at the top-level, but internally, the security interceptor is going to have to determine how to enforce the container specific view. 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. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
On 2001.11.15 11:55:18 -0500 Rickard Öberg wrote: David Jencks wrote: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. 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. If you pass the head of the chain with every invocation call, obviously the interceptor can extract whatever metadata it needs, compute whatever derived info is necessary, and use it. But if these computations take on the order of seconds, which is definitely a possibility and I think the case with the security proxy interceptor [NOT the security interceptor] (and the interceptor I have for rule engines), you need to precompute the derived info and save it somewhere in an initialization step. No matter which approach we use, this initialization step is necessary. I am saying that storing the results of the initialization in the interceptor makes more sense than putting it in an untyped map in the head of the chain. Doing this systematically also means you don't need to pass the head of the chain when you are traversing it with a method invocation. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? They each store the info they are interested in. If its the same as another interceptor, who cares? The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want 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. what I'm talking about can also be used for any container. The metadata extraction occurs during chain initialization. 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). Lets set up an example mbean code=org.jboss.system.InterceptorFactory name=JB:service=TxInterceptor attribute name=classorg.jboss.ejb.TxInterceptor/attribute mbean code=org.jboss.system.InterceptorFactory name=JB:service=SecurityInterceptor attribute name=classorg.jboss.ejb.SecurityInterceptor/attribute mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-elementJB:service=TxInterceptor/mbean-ref-list-element mbean-ref-list-elementJB:service=SecurityInterceptor/mbean-ref-list-element /mbean-ref-list mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactoryJB:service=MyChain/mbean-ref attribute name=EjbNamemyEjb/attribute /mbean when the mbeans are started up, the Container gets the metadata for the ejb, asks the InterceptorChainFactory for an interceptor chain containing new instances of the specified interceptors from the interceptor factories, and initializes (starts) it by sending itself or the metadata down the chain. Each interceptor extracts whatever info it needs from the metadata and saves it in the most convenient form in itself, in typed objects. Method invocations go down the chain, and the interceptor instances use their specially calculated info to do their job. Note that the InterceptorFactory mbeans can of course include additional attributes to further specialize the instances they create. david jencks /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
Scott M Stark wrote: This is the crux of this issue. Some interceptors are stateful and are tied to the type of container they are being used with. The EJB security model is completely different than the Web security model. All the security related interceptors due is translate from the container specific model to the generic JAAS implmentation in fact. That is beside the point. If I have an MBean *wanting* the EJB security model, I'd like to be able to invoke it using the EJB interceptor, without the interceptor complaining about it. It shouldn't care what the end destination is, as long as the container can provide the right meta-data. I can force a container independent model on the interceptors that show up at the top-level, but internally, the security interceptor is going to have to determine how to enforce the container specific view. 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. That is your opinion :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|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
Re: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote: If you pass the head of the chain with every invocation call, obviously the interceptor can extract whatever metadata it needs, compute whatever derived info is necessary, and use it. But if these computations take on the order of seconds, which is definitely a possibility and I think the case with the security proxy interceptor [NOT the security interceptor] (and the interceptor I have for rule engines), you need to precompute the derived info and save it somewhere in an initialization step. No matter which approach we use, this initialization step is necessary. I am saying that storing the results of the initialization in the interceptor makes more sense than putting it in an untyped map in the head of the chain. Doing this systematically also means you don't need to pass the head of the chain when you are traversing it with a method invocation. This seems to have more to do with caching than the decision on where to keep the data. AFAICT there's no problem with caching the data in the interceptor (although you'd have to do it in a hashtable, with the end-point MBean name as key), to allow such initialization work to be done. As long as you can always re-get the data from the MBean, and that the MBean is really *in charge of* the state. Is the reason you want interceptors stateful only for performance? If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? They each store the info they are interested in. If its the same as another interceptor, who cares? Well, *how do they get that info*?? As above, if two interceptors *cache* the data that is fine, because then they're not *in charge of* the data from an architectural/design point of view. It is then inherently shareable. If the metadata belongs to any of the interceptors, then somewhere there needs to be knowledge about what interceptor needs what metadata so that they can be provided this. In the stateless model they are themselves responsible for accessing whatever they need from the container (or whatever the end-point is), thus encapsulating the knowledge of that need. Also, a stateless interceptor can be used for any container. If you want 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. what I'm talking about can also be used for any container. The metadata extraction occurs during chain initialization. What you mean is that during chain init a particular instance is being created for that chain. Right? What I'm saying is that interceptors exist independently of these chains, i.e. they may exist before any chains exist, it's just that without a chain they are never invoked. When the chains are created particular interceptors are chosen for that chain, and then used. Those interceptors may however be part of other chains acting concurrently. mbean code=org.jboss.system.InterceptorFactory name=JB:service=TxInterceptor attribute name=classorg.jboss.ejb.TxInterceptor/attribute mbean code=org.jboss.system.InterceptorFactory name=JB:service=SecurityInterceptor attribute name=classorg.jboss.ejb.SecurityInterceptor/attribute mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-elementJB:service=TxInterceptor/mbean-ref-list-element mbean-ref-list-elementJB:service=SecurityInterceptor/mbean-ref-list-element /mbean-ref-list mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactoryJB:service=MyChain/mbean-ref attribute name=EjbNamemyEjb/attribute /mbean snip Excellent! Nothing like an example to clarify things. Here's mine: mbean code=org.jboss.ejb.TxInterceptor name=JB:service=TxInterceptor attribute name=transactionManagerjava:/MyTM/attribute /mbean mbean code=org.jboss.ejb.SecurityInterceptor name=JB:service=SecurityInterceptor attribute name=realmMyCompanyRealm/attribute /mbean mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-element JB:service=TxInterceptor /mbean-ref-list-element mbean-ref-list-element JB:service=SecurityInterceptor /mbean-ref-list-element /mbean-ref-list /mbean mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactory JB:service=MyChain /mbean-ref attribute name=EjbNamemyEjb/attribute /mbean -- The interceptors are MBeans, and thus
RE: [JBoss-dev] Invocation and MethodInvocation
|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. Ineed toturnoffthisemail 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
Re: [JBoss-dev] Invocation and MethodInvocation
marc fleury wrote: I was planning on putting a reference to the container ie. the repository of chain configuration, IN the invocation itself. You then have a self describing invocation. The rugged interceptor can then come and say alright little fella, give me the tx tag you want big schme! 2 links instead of one, and no lookup in there. Good. again abstract the end-point into a chain it is a different beast where the identity is the sum of mbeans, that container is really the repository of the path for a given logical type of flow. EJB has little reality in this approach, it only exists as a temporary list of interceptors and plugins. Alright, I'm cool with that. BTW, this notion is extremely similar to some meta-physics theories, which I find to be very amusing. :-) Funny how real-life concepts tends to finds its way into programming. I also think the real problem is in the nature of this beast, too disruptive a view. I am ok with dealing with it, but I think that for most people the real interceptor chain is reassuring also as in its first incarnation, I doubt it will bring more functionality, you will find resistence in the brains to let go and really go with this detyped/stateless/dynamic/shared flow system view of the world. It is fundamentally a SYSTEM view, really what JBoss is all about these days. Where there was a reassuring container we now have a new beast, lightweight and dynamic with very little reality. Yeah, now we're talking! It is always frightening to let go of adopted beliefs, but boy is the rush worth it ;-) Maybe for JBoss 4 then... I think that an application such as a rule engine dynamically scripting the flow of invocation *graphically* where you can see your flow, will be a proof, but we really are far from that at this point. So for the 4th time today, let's try to keep the religiousness of this discussion in a pure academic world, since I won't code it this week. I would really like to code for the rest of the day... can I go ? You're excused. Go code. I'm glad you got the above though. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
snip I think that an application such as a rule engine dynamically scripting the flow of invocation *graphically* where you can see your flow, will be a proof, but we really are far from that at this point. (Oh yeah? how far?) OK, this is the one capability the one interceptor approach has that the factory approach doesn't. Do you have an example where this is useful? So for the 4th time today, let's try to keep the religiousness of this discussion in a pure academic world, since I won't code it this week. I would really like to code for the rest of the day... can I go ? But what will we do???;-) david 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
wowowo, I realize I forgot to say what this is good for :) you can now attach ANY PAYLOAD to an invocation, not just the stuff generated at the client, so that you can pass information down the chain, have interceptors talking to each other and pass arbitrary data around the JMX base, VERY VERY VERY useful for your custom advanced interceptors. (was it the motorola kids in the Las Vegas training that mentioned they needed this?) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, November 14, 2001 12:08 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: [JBoss-dev] Invocation and MethodInvocation | | |Ok, | |[FOR RECORD, ARCH CHANGE] | |we discussed some time ago the possible extension of the MethodInvocation |to be a more generic and powerful entity. | |Basically I have added the invocation directory and the Invocation.java, as |well as changed the MethodInvocation. | |The 10,000 ft is that the new RH JMX view puts the mbeans in front. The |entity that travels inside our JMX bus is the Invocation that I just |introduced. The invocation basically takes the transaction and security |information as its basis. You are always doing stuff as part of |transaction |context (maybe empty meaning no transaction) and as someone authenticated |(if you set it up) but these are the building blocks. Then everything else |is in a payload of possibly serialized byte[] data that we can carry |around as such (avoiding cl madness). We extend this for the |methodinvocation which is more EJB'ish in that it knows about the |EnterpriseContext (more on that later). | |The other new thing in there is the presence of the mbean list of objects |this Invocation is supposed to go through. It will identify the MBean |interface of the Container for the EJBs, thereby really finalizing the |detaching of the invokers from the invocation, both from the bus (which is |already done) and the rmi impl (to be done next). | |The Invocation is not using the mbean list as yet, but possibly will, since |what would come next is a self standing invocation in our JMX base, going |through the bus from mbean to mbean, which would really give us a possibly |dynamic way of maintaining the path that our invocation takes in the base. |The stuff is there, will use a little bit to hook up the EJB container, we |will see. | |I will also probably don't externalize the interceptors as yet, no good |reason except it would be less disruptive a view from what we have now and |it would be lindfors recommendation. | |I was going to talk about the EnterpriseContext thing but this is already |a long mail. I will do so in a forthcoming email. | |Finally I will say that for legacy reasons I have kept the old constructors |and allowed the Invocation to carry no MBean association. The 2 legacy are |1- the invocation chain is not fully generic yet, it knows the target, this |is detached already (going JMX bus) but will move next 2- the CMR |stuff from |Dain that uses the invocation chain to invoke stuff on itself, this assumes |that you know the container (which it does) and calls it directly (which it |does) withouth the intermission of the JMX bus (which is ok), so this is |likely to remain as is for now. Moving it to the bus would be trivial but |not a priority right now. | |The testsuite testbean runs fine afaict, so this should not disrupt the |existing RH codebase, fully backward compatible (again afaict) | |just warming up | |marcf | |Marc Fleury |President |JBoss Group, LLC | | | |___ |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
RE: [JBoss-dev] Invocation and MethodInvocation
|Although I originally thought including an mbean-iterator in the method |invocation, as you have done, was the way to go, after discussion with |Scott and some experiments I changed my mind to think an approach using |interceptor factories and interceptor chain factories (both mbeans) is a |better idea. The mbean is there to identify the target MBean for now. Whether or not we go to the fully stateless design might be down the road. Reread my email, for now (today's todo) it is going to point to the container. The String[] could be a String (no []) this is how I am going to use it this afternoon with the detaching of the connector (see if it works well). |There are 2 problems I know of with the mbean-iterator approach. |1. It requires the interceptors to be stateless. All state info has to be |carried in the invocation object. Any setup information the interceptor You are mixing 2 issues, one is making the chain of interceptors fully stateless (which they are afaict I still have to see the example you are refering to). The other is list of mbeans you go through, since the interceptors AREN'T MBEANS yet, we would have to make that first wouldn't we? |may need has to be stored in the head-of-the-chain object and sent with |each MI. IMHO this is _really_ not where this info belongs. The head ??? the invocation is the only one that uses the information. |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. | |2. (possibly an implementation issue, but real at the moment). Calling |mbeanserver.invoke is _wa_ 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. |The interceptor chain methodology I cureently think will work best involves |2 mbeans: We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking about a list of MBeans. right now the only mbean is the container that was added by Scott and I wired the other day... |Interceptor factories: | |takes Interceptor class name as an attribute, has an mbean method |newInterceptor returning a copy of the Interceptor. | |This is a dynamic mbean, it could be made to expose the get/set properties |of the interceptor as attributes in the InterceptorFactory mbean. | |InterceptorChainFactory: |takes an mbean-ref-list of the mbeans you want in the chain. Has a |newInterceptorChain method taking the head and tail of the chain as |parameters, returns a new chain with the interceptors specified in the |list. Calls init(head) on each interceptor. (the head is an object that is |assumed to contain the info needed for initialization, such as the info for |the SecurityProxy setup.) The supplied tail is setup as the last element. | |I have this much written. | |I have been wondering how to fit this into the ContainerFactory: I think |one approach might be to make the Containers into MBeans that can be |configured as any other mbeans in a service-xml file, and include an 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. 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. marcf |mbean-ref to the InterceptorChainFactory needed. The ContainerFactory |could have mbean-refs to the default chains for each type of bean. I |haven't looked into this extensively yet. | |Thanks |david jencks | |On 2001.11.14 12:08:00 -0500 marc fleury wrote: | Ok, | | [FOR RECORD, ARCH CHANGE] | | we discussed some time ago the possible extension of the | MethodInvocation | to be a more generic and powerful entity. | | Basically I have added the invocation directory and the Invocation.java, | as | well as changed the MethodInvocation. | | The 10,000 ft is that the new RH JMX view puts the mbeans in front. The | entity that travels inside our JMX bus is the Invocation that I just | introduced. The invocation basically takes the transaction and security | information as its basis. You are always doing stuff as part of | transaction | context (maybe empty meaning no transaction) and as someone authenticated | (if you set it up) but these are the building blocks. Then everything | else | is in a payload of possibly serialized byte[] data that we can carry | around as such (avoiding cl madness). We extend this for
RE: [JBoss-dev] Invocation and MethodInvocation
actually scratch all this discussion, I think I have a better idea for the MI/Invocation I will keep the payload and just put different readers on it, the basic one will be the Invocation, the extended one will be the MI but essentially we can create a MI and set the payload from the incoming invocation and then read a typed invocation (ejb in this case) only when we reach the valid stacks, this allows for something truly powerful: byte[] messages until we reach the stack that knows how to read them, but the fact that they are serialized or not is transparent to the MI, which is truly not the case ... the basic invocation is thus the payload, the readers are just typed conveniences in the stacks. Will make sense when I commit this. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, November 14, 2001 1:54 PM |To: David Jencks; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Invocation and MethodInvocation | | ||Although I originally thought including an mbean-iterator in the method ||invocation, as you have done, was the way to go, after discussion with ||Scott and some experiments I changed my mind to think an approach using ||interceptor factories and interceptor chain factories (both mbeans) is a ||better idea. | |The mbean is there to identify the target MBean for now. Whether or not we |go to the fully stateless design might be down the road. | |Reread my email, for now (today's todo) it is going to point to the |container. The String[] could be a String (no []) this is how I am going to |use it this afternoon with the detaching of the connector (see if it works |well). | ||There are 2 problems I know of with the mbean-iterator approach. ||1. It requires the interceptors to be stateless. All state info has to be ||carried in the invocation object. Any setup information the interceptor | |You are mixing 2 issues, one is making the chain of interceptors fully |stateless (which they are afaict I still have to see the example you are |refering to). The other is list of mbeans you go through, since the |interceptors AREN'T MBEANS yet, we would have to make that first wouldn't |we? | ||may need has to be stored in the head-of-the-chain object and sent with ||each MI. IMHO this is _really_ not where this info belongs. The head | |??? the invocation is the only one that uses the information. | ||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. || ||2. (possibly an implementation issue, but real at the moment). Calling ||mbeanserver.invoke is _wa_ 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. | ||The interceptor chain methodology I cureently think will work |best involves ||2 mbeans: | |We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking |about a list |of MBeans. right now the only mbean is the container that was |added by Scott |and I wired the other day... | ||Interceptor factories: || ||takes Interceptor class name as an attribute, has an mbean method ||newInterceptor returning a copy of the Interceptor. || ||This is a dynamic mbean, it could be made to expose the get/set properties ||of the interceptor as attributes in the InterceptorFactory mbean. || ||InterceptorChainFactory: ||takes an mbean-ref-list of the mbeans you want in the chain. Has a ||newInterceptorChain method taking the head and tail of the chain as ||parameters, returns a new chain with the interceptors specified in the ||list. Calls init(head) on each interceptor. (the head is an |object that is ||assumed to contain the info needed for initialization, such as |the info for ||the SecurityProxy setup.) The supplied tail is setup as the last element. || ||I have this much written. || ||I have been wondering how to fit this into the ContainerFactory: I think ||one approach might be to make the Containers into MBeans that can be ||configured as any other mbeans in a service-xml file, and include an | |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. | |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. | |marcf | ||mbean-ref to the InterceptorChainFactory
RE: [JBoss-dev] Invocation and MethodInvocation
This is great. This is what I wanted to do when I wrote my message passing hack. I think one problem is the current interceptors will be expecting a Method object, so when they are changed to handle an Invocation with out a Method object, I will definitely switch over. -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 11:44 AM To: marc fleury; Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Invocation and MethodInvocation wowowo, I realize I forgot to say what this is good for :) you can now attach ANY PAYLOAD to an invocation, not just the stuff generated at the client, so that you can pass information down the chain, have interceptors talking to each other and pass arbitrary data around the JMX base, VERY VERY VERY useful for your custom advanced interceptors. (was it the motorola kids in the Las Vegas training that mentioned they needed this?) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, November 14, 2001 12:08 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: [JBoss-dev] Invocation and MethodInvocation | | |Ok, | |[FOR RECORD, ARCH CHANGE] | |we discussed some time ago the possible extension of the MethodInvocation |to be a more generic and powerful entity. | |Basically I have added the invocation directory and the Invocation.java, as |well as changed the MethodInvocation. | |The 10,000 ft is that the new RH JMX view puts the mbeans in front. The |entity that travels inside our JMX bus is the Invocation that I just |introduced. The invocation basically takes the transaction and security |information as its basis. You are always doing stuff as part of |transaction |context (maybe empty meaning no transaction) and as someone authenticated |(if you set it up) but these are the building blocks. Then everything else |is in a payload of possibly serialized byte[] data that we can carry |around as such (avoiding cl madness). We extend this for the |methodinvocation which is more EJB'ish in that it knows about the |EnterpriseContext (more on that later). | |The other new thing in there is the presence of the mbean list of objects |this Invocation is supposed to go through. It will identify the MBean |interface of the Container for the EJBs, thereby really finalizing the |detaching of the invokers from the invocation, both from the bus (which is |already done) and the rmi impl (to be done next). | |The Invocation is not using the mbean list as yet, but possibly will, since |what would come next is a self standing invocation in our JMX base, going |through the bus from mbean to mbean, which would really give us a possibly |dynamic way of maintaining the path that our invocation takes in the base. |The stuff is there, will use a little bit to hook up the EJB container, we |will see. | |I will also probably don't externalize the interceptors as yet, no good |reason except it would be less disruptive a view from what we have now and |it would be lindfors recommendation. | |I was going to talk about the EnterpriseContext thing but this is already |a long mail. I will do so in a forthcoming email. | |Finally I will say that for legacy reasons I have kept the old constructors |and allowed the Invocation to carry no MBean association. The 2 legacy are |1- the invocation chain is not fully generic yet, it knows the target, this |is detached already (going JMX bus) but will move next 2- the CMR |stuff from |Dain that uses the invocation chain to invoke stuff on itself, this assumes |that you know the container (which it does) and calls it directly (which it |does) withouth the intermission of the JMX bus (which is ok), so this is |likely to remain as is for now. Moving it to the bus would be trivial but |not a priority right now. | |The testsuite testbean runs fine afaict, so this should not disrupt the |existing RH codebase, fully backward compatible (again afaict) | |just warming up | |marcf | |Marc Fleury |President |JBoss Group, LLC | | | |___ |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|-Original Message- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Wednesday, November 14, 2001 4:13 PM |To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net |Subject: RE: [JBoss-dev] Invocation and MethodInvocation | | |This is great. | |This is what I wanted to do when I wrote my message passing |hack. I think |one problem is the current interceptors will be expecting a Method object, |so when they are changed to handle an Invocation with out a Method |object, I |will definitely switch over. it is already done, the new MI walking down supports the addvalue and getvalue... go ahead use it! marcf | |-dain | | -Original Message- | From: marc fleury [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, November 14, 2001 11:44 AM | To: marc fleury; Jboss-Development@Lists. Sourceforge. Net | Subject: RE: [JBoss-dev] Invocation and MethodInvocation | | | wowowo, | | I realize I forgot to say what this is good for :) | | you can now attach ANY PAYLOAD to an invocation, not just the stuff | generated at the client, so that you can pass information | down the chain, | have interceptors talking to each other and pass arbitrary | data around the | JMX base, VERY VERY VERY useful for your custom advanced interceptors. | | (was it the motorola kids in the Las Vegas training that | mentioned they | needed this?) | | marcf | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On | Behalf Of marc | |fleury | |Sent: Wednesday, November 14, 2001 12:08 PM | |To: Jboss-Development@Lists. Sourceforge. Net | |Subject: [JBoss-dev] Invocation and MethodInvocation | | | | | |Ok, | | | |[FOR RECORD, ARCH CHANGE] | | | |we discussed some time ago the possible extension of the | MethodInvocation | |to be a more generic and powerful entity. | | | |Basically I have added the invocation directory and the | Invocation.java, as | |well as changed the MethodInvocation. | | | |The 10,000 ft is that the new RH JMX view puts the mbeans in | front. The | |entity that travels inside our JMX bus is the Invocation | that I just | |introduced. The invocation basically takes the transaction | and security | |information as its basis. You are always doing stuff as part of | |transaction | |context (maybe empty meaning no transaction) and as someone | authenticated | |(if you set it up) but these are the building blocks. Then | everything else | |is in a payload of possibly serialized byte[] data that we | can carry | |around as such (avoiding cl madness). We extend this for the | |methodinvocation which is more EJB'ish in that it knows about the | |EnterpriseContext (more on that later). | | | |The other new thing in there is the presence of the mbean | list of objects | |this Invocation is supposed to go through. It will identify | the MBean | |interface of the Container for the EJBs, thereby really | finalizing the | |detaching of the invokers from the invocation, both from the | bus (which is | |already done) and the rmi impl (to be done next). | | | |The Invocation is not using the mbean list as yet, but | possibly will, since | |what would come next is a self standing invocation in our | JMX base, going | |through the bus from mbean to mbean, which would really give | us a possibly | |dynamic way of maintaining the path that our invocation | takes in the base. | |The stuff is there, will use a little bit to hook up the EJB | container, we | |will see. | | | |I will also probably don't externalize the interceptors as | yet, no good | |reason except it would be less disruptive a view from what | we have now and | |it would be lindfors recommendation. | | | |I was going to talk about the EnterpriseContext thing but | this is already | |a long mail. I will do so in a forthcoming email. | | | |Finally I will say that for legacy reasons I have kept the | old constructors | |and allowed the Invocation to carry no MBean association. | The 2 legacy are | |1- the invocation chain is not fully generic yet, it knows | the target, this | |is detached already (going JMX bus) but will move next 2- the CMR | |stuff from | |Dain that uses the invocation chain to invoke stuff on | itself, this assumes | |that you know the container (which it does) and calls it | directly (which it | |does) withouth the intermission of the JMX bus (which is | ok), so this is | |likely to remain as is for now. Moving it to the bus would | be trivial but | |not a priority right now. | | | |The testsuite testbean runs fine afaict, so this should not | disrupt the | |existing RH codebase, fully backward compatible (again afaict) | | | |just warming up | | | |marcf | | | |Marc Fleury | |President | |JBoss Group, LLC | | | | | | | |___ | |Jboss-development mailing list | |[EMAIL PROTECTED] | |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | ___ | Jboss-development mailing
