|Yes, if the EJB's are exposed as MBeans it is more of a special case |than anything else. (And not so special anyway, which is the whole point)
exactly, EJB's are not special from the container (JMX) point of view they use remoteness indirection invocation just as any other mbean 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. |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. |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 ;-). 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. |> If you don't do that, the client has to come up with something that |> essentially DOES EXACTLY THE SAME THING. | | |No, all you need to do is place this configuration of stacks in an |MBean, just like you do today (in what used to be ConfigurationMBean. Is |it the ServiceConfigurator or ServiceDeployer now? anyway..). Think JMX |Adaptors. hmmm even including the confusion on the "JMX adaptor" definition I think we need to be thinking of ContainerFactory here, which is a very different beast. I am specifically talking of the part of the code that creates the stack of interceptors. That today is tied to the deployment when it should really be something dynamically accessible by maintainance stacks. |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. Rickard you were the one to talk about Then in the back end you can add gate detectors (almost like in physics) that detect the passage of the invocations through so you can really see what is going on in your system from a flow standpoint, that is brand new debugging afaik and we can add/remove/update it without polluting the system at *compilation time*... that is truly powerful and totally independent of the actual business implementation of the MBeans. To me these are squarely system issues that are better dealt at the system level. 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? |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... |Meaning that any MBean can take advantage of the tx and security stacks. |NOW WE'RE TALKING. Because the EJB model, as some of the listeners are uffffffff 2 days to get the message through... glad its a Roger, you won't get many communications |aware of (Hi Sean), does have some serious flaws as a *practical |programming model*. Can you say "over engineering". Knew you could... Fuck Sean, fuck all the "vendor" guys on our list (btw THEY ARE ALL HERE, I will have to show you the list of Jboss-dev one day). The vendors are talking poopoo at this point but I am tired of giving all the knowledge for free and recommend coming to the next comm in Las Vegas ;-) 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". Can you imagine those penguins at BEA/IBM saying "oh yes, me and my buddies here, cause we are belly belly good, have come up with the same design as you guys did with all the classloader stuff and the JMX buses and the interposition and what not"... Right... you penguins wouldn't cut it a day in the Open Source flow, get your clocks cleaned 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. |I think I'm still leaning more towards doing what you describe as MBean |Adaptors, but the problem with that is that you'll practically flood the |MBeanServer with interceptor stack Adaptor MBeans. Which is not good. | |Hm.... wrong definition of "adaptor" and even with the right one see above. |The Jinification I talked about is just one method of intercepting, one |possible stack, and not a replacement for you describe. sure. marcf 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? -- _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
