|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? |
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 schmellll! 2 links instead of one, and no lookup in there. perf is the same. |the data from an architectural/design point of view. It is then |inherently shareable. If the metadata belongs to any of the yes |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. yes, the "endpoint" thing is weak though (but it is what I have in the current invoker, need to think of something better) I think we need a real logical name of the "chain" as path. Sygma(path) == chain <==>container It is the path integral that defines the container. Today I identify it with the MBean name of the container built by Scott. That container encapsulates a hardcoded chain (in effect). |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 precisely |chains exist, it's just that without a chain they are never invoked. yes, they are configured in the JMX base, independently of EJB existence or any container for that matter. |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. correct. |Here's mine: | <mbean code="org.jboss.ejb.TxInterceptor" | name="JB:service=TxInterceptor"> | <attribute name="transactionManager">java:/MyTM</attribute> | </mbean> re: mail of yesterday, remove the "ejb" in that interceptor | <mbean code="org.jboss.ejb.SecurityInterceptor" | name="JB:service=SecurityInterceptor" | <attribute name="realm">MyCompanyRealm</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="EjbName">myEjb</attribute> | </mbean> |-- |The interceptors are MBeans, and thus configurable as MBeans. They can |have state, just as the two above does, but can also be used by any |container, and any chain. yes |IMHO this is more powerful, since the interceptors can be used with |pretty much whatever MBean/endpoint. If they need info about the |endpoint, such as the TxInterceptor wanting to know whether a particular |method in the end-point has a particular tx setting, they just ask the |MBeanInfo of it, which it will get from the invocation (or at least the |end-point identifier should be in the invocation, which will allow one |to deduce the MBeanInfo from that). 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. |You think this is bad? Why? If it's the performance part: fine, cache it. I frankly don't think there is a performance issue here. 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. 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 ? 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
