marc fleury wrote: > the ejb behavior is implemented in the actual linked list of interceptors > that we put there, exactly what we do today from the ContainerFactory but > completely and **genericaly** at the JMX layer. Building the EJB will be > nothing more than passing standardjboss.xml topology of stacks.
Gotcha. > |It should be doable as MBeans, i.e. no real need to change the bus. The > |interceptor stack map fairly well to JMX Adaptors. > > I am surprised Andreas is not on your case yet, the JMX adaptors in his eyes > have a very different meaning. You seem to suppose that > adaptors=interceptors (as in invoke() stacks). Andreas explains in the book > that adaptors are really just an "adaptor" from the semantic of the calls > coming from the connectors to the semantics of the JMX bus. > > Different things. That would be one way of looking at it. In that sense they map fairly well to the Bridge design pattern, i.e. converting between two worlds of perspectives. I'll rephrase myself. Interceptors could be done as a series of JMX MBeans implementing DynamicMBean, i.e. they don't do anything with the call except delegate to other DynamicMBeans, with the last one actually doing something. This would work, and it would make it simple to configure each interceptor separately, since they're MBeans. The problem is that for each MBean requiring a specific set of interceptors there would be a bunch of additional MBeans (i.e. the interceptors themselves). You would hence get loads and loads of MBeans who play the interceptor game. Not sure if that's a good idea. However, if you put the interceptors in the bus you then have two ways of writing components: as MBeans and as JMX server interceptor plugins. Any thoughts on that? > |There are a couple of important points to lessen the "crazy aspect": > |1) There will not be nxn connections where n is number of services. The > |*worst* case will be sxs connections where s is the *number of servers*. > |RMI connections can be shared by MBeans in the same server. > > right, and even in the rabbit hole picture that is not limited to RMI (I am > not saying you are saying this ;-). Good point. Actually, there's no need to use RMI for the talking, only required for talking to the LUS. What you get from the LUS could be the connectors to the other servers, which can talk whatever lingo you want. In this sense you're only using the Jini/LUS as a way for the servers to find each other. After that you can do whatever you want. > But I suspect that for many first > iteration it will nxs at least with the current implementation of the > proxies. If we do smart stuff (like I outlined to bill and you privately) > then we can actually reuse the connection. It is the power of the detyped > invocation and we don't know what is behind or need to. True. > |But you do have a point in that it might be the case that configuring > |the stacks can be done *more efficiently* if done inside the server. > |Maybe, maybe not. > > It's more clear cut than that. Take the "debugging" for example. Say that > we want to trace particular flows in the system. What we would do is start > sending "radioactive" messages with a "trace flag" IN THE MESSAGE. And the > one that stamps the messages like that can be some code flag in the > connector sure but that would be inferior since we can't update that part so > easily (well you can in rabbit hole due to the dynamic hot deploy of server > parts but that is beyond the point). The point is that we can put ANY NEW > FANCY tracer in there dynamically that would add any complex type to the > payload of the MI going in so we can do fancy tracing. Then we can remove > the interceptor ENTIRELY, not even fuck with flag settings in JMX and what > not. It is a whole new level of JMX infrastructure as plugin management and > dynamic scripting of flows... all due to the JMX bus presence with a fully > detyped invocation. Interesting. And how is this configuration done? Also through JMX? What you'd want to avoid is two ways of doing the same thing (e.g. JMX + JMX/infra) > To me these are squarely system issues that are better dealt at the system > level. +1. > The role separation is very easy to do in that invoke flow (like you did the > interceptors in JBoss2 rickard) and it is very clear. It's your stuff in a > new dimension, don't you see? Loud and clear. > |That's important for the "five nines", indeed. Or six or seven or how > |many nines you want. ahw wtf, nine nines.. that'd be something :-) > > yes we are there :) read the microsoft research papers of 2 weeks ago.. we > are flying so fucking high they can't even start to hear us... Read and giggled :-) They are way way behind. > uffffffff 2 days to get the message through... glad its a Roger, you won't > get many communications 8-) > The other beautiful thing about this is it IS SO CORE that before a vendor > can rip off our ideas (hello again) we will know for sure as there isn't a > fucking other soul on earth that is using JMX EVEN TODAY as the base like > you did rickard. They all use it "for management". Good point. > WTF!!!!! bunch of impostors... bunch of bozos. Working in isolation of your > peers leads to decay of the mind and decay of the work. I don't buy for A > SECOND that the second grade developers at these companies can come up with > the same. It is stealing but we know better. We're all proffessional thieves, in some sense. :-) It's how good you are at putting different things together in different dimensions that makes it interesting or not. :-) > man I feel better it has been on my mind for quite some time now. > Love, to the ones who deserve it. > > To the rest... > > "we will bury you" > -- Krutchev? -- You're a blan&white kinda guy ;-) Glad I'm on the right side of the fence. PLgC /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
