>|>You just mean that "invoke()" is a more natural way to String together >|>detyped services but you could argue that for the price of putting the >|>Dynamic Proxies right behind the standard MBean interface you can generate >|>the same invoke() call and thus string a stack behind it. >| >|You can only do that if you are in control over the MBean instantiation and >|registration. If you want to make generic MBeans that do not depend on the >|JBoss infrastructure this does not hold. It is not very standard-ish. > >Either that or you control the JMX infrastructure, a JMX server that >includes the externalization of stacks of JBoss would do just that.
That's true. So, you want to replace the RI then? >|> then there are other easier ways to achieve this (see upcoming Juha's >|>Book ;-) by extending even the *binary* itself. >| >|What do you mean by "extending the binary"? > >read the book Ah, ok. Very informative answer. Does this mean there's no one-liner reply, that you don't think it's worth the effort to answer properly, or that you don't know? >|Sure, that could work. Still, I don't see in current JBoss 3 code >|where this >|is left to the individual MBean to decide. It seems like JBoss mandates the >|configuration to come through the SAR stuff. > >The stuff that does that is the XMBeans of Juha's upcoming book. .. which is similar to what I have described, right? >|It seems like what I have done is very similar to what he has done >|(based on >|his descriptions anyway). Which makes it kind of interesting why you're >|dizzing what I'm saying, since you're on the other hand praising the very >|same approach. I never did understand you dude... > >well relax... I am not dizzying you. I am praising the load and store in >both approaches. The important thing is the beans dealing with their >configuration semantics. Which is not how JBoss 2/3 works today. > I was critizing the rest of the "praise", in my >mind the real pro here is the localized semantics. Yes, that MBeans can deal with their own configuration semantics. Right? *Which is what I said*....geeezz... >|wants to be able to start without a dependency having been resolved it can >|mark it as not-required in the XML configuration. If an MBean is > >do you hold a bean until you get an event in case you don't have the bean >yet? Not quite sure what you're asking about. Example: MBean A has a not-required dependency on MBean B, which is coupled to the attribute "b". A can start without B being available or started, i.e. calling "getB" on A can yield null. When B is started the dependency is resolved, and setB is called with a proxy to B as argument. A may then use B. This means that A has to check whether B is set or not before it tries to use it. This is the semantics of not-required dependencies. >|started and a required dependency becomes unavailable it will stop, unless >it can find >|another MBean matching the same ObjectName-pattern (this is the "poor mans >|failover" part). > >hmmm interesting is this during run-time? Of course. > so how does this work you recieve >an event e.g. MBean A receives the event "MBean B state is now STOPPING", i.e. B is becoming unavailable for A to use. > and you stop the mbean e.g. A is stopped due to a dependency to B is becoming unresolved. > and you control the reference inside the >object (must be exposed) and you set it to the new MBean name... the >reference of inter-bean is what? this is not clear. Do you call the bean >directly do you call the server? You are talking about stateless stuff here >obviously. These sentences make no sense to me. I have no idea what you're asking about. Can you be more specific. An example perhaps? >Yes but that is inferior to rerouting on the server. Reread my mail. In my case the client is another server, i.e. I'm referring to MBean2MBean communication where the MBeans can reside on different servers. How is it inferior? >|On the server side, yes, but that is worse because then the client is never >|given the option of using another provider of the service. You are > >That is not correct. The client knows about different JMX node invokers. But you are then assuming that the client has to know about the concept of "invokers" in the first place. In my scenario the client MBeans only sees other MBeans and does not have to know about the underlying stuff, which could indeed be based on what you describe. >Either you do it there or you do it in the bean, either way you need a way >to describe the stack of interceptor to the bean (that would create it) or >to the JBoss-like deployer. Correct. And if you do it in the server the MBeans that makes use of it are tied to the JBoss server, i.e. they are not portable to other servers. By placing the logic in the MBeans instead, i.e. in between the invoke() and the actual call handling, the MBeans become more self-contained. I prefer self-contained, unless there is a big win with putting it in the server itself. >I am not following you. You keep talking about clients on the web with RMI >references to JINI and a "star" of connections from n clients to n >services... with RMI... on the web... I think the main difference between what we're saying is that in my case the "clients" are other JMX servers, and the MBeans in them. In that sense this is really only a replacement for the java:comp/env facilities and not a generic JNDI client (as in end-user client) mechanism. >you crazy? Not that I know of, no. >I believe that monitoring the state of the mbeans in the nodes (multi node >even, but squarely server side) is the way these services will scale. So >the monitoring is good on server only. As above, my definition of "client" is not "end-user client" but rather other servers that host MBeans using MBeans in other servers. For the *end-user client* stuff your invokers et al becomes much more interesting. Absolutely. >|JBoss 3 is going to be very very cool, but IMHO it could really >|benefit from >|using the ideas I outlined, which in essence are: >|1) Make the configurator non-dictatorial by exploiting the PersistentMBean >|interface > >Yes, agreed in development for the book, the XMBeans. If you want to commit >your stuff there today, feel free. At least read the XMBean chapter from >the book would be interesting. Will do. Juha, interested? >What I really want to do is finish the website and then go back to >developing sometime next week. I will code the "detaching" of the invokers >and we should pick up this discussion when we try to finish the >configuration stuff in JBoss3. Fair enough. /R _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
