> +1. This all came about because I was thinking about client side caches > with server invalidation. Without the JMX kernel it is a pain because > we have invent a totally new architecture to handle server to client > invocations. If we have the kernel, we quickly prototype this by > reusing the server invokers. Of course our existing invokers won't work > for a real deployment with clients behind a firewall, but it is a good > start. > > -dain >
What I would like to know, is: what are the features that JMX provides that you need on the client side?? (1) Is it the interceptor architecture built around JMX? (2) Is it the ability to look up other services via JMX? I want to know because I think that we can provide client side container without having to use JMX. I think that stuff will actually get simpler if we do not FORCE jmx on the client side. Our Aspect API is all about that. It's about providing at least #1 in a clean generic fashion. But for it successfully use for client side containers, I need to understand what all the requirements will be. Bill, I know you started doing some work on client side interceptors using the aspect stuff. What JMX features were you wishing you had on the client side?? Regards, Hiram ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
