On 7/25/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 7/25/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > It seems that remoting a jmx client is not so easy. > All classes involved must be serializable or mbeans i think. > And this is not the case at all (the client has a pointer to the container, > the DefaultDestination has a pointer to the client, etc..) > So if we want to go that way, we have to provide wrapper for all > non serializable classes involved in the client api. > > So i will let the remote stuff aside for the moment. > It makes me thing that the first draft of the client api James put > in svn was simpler and easier use in a remote mode. > http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Client.html > http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Destination.html > > Should we revert back to it ? I guess we could. We could make ServiceMixClient extend Client as an interface. We could maybe have a client side version of Destination which is really just a facade on a ServiceMixClient interface? So keep, say, ServiceMixClient remote and have a client side facade using it to give the nice URI style API
Well, the problem is that the ServiceMixClient interface is not easily remotable :( Btw, the use of a remote api itself may be questioned. If you are in the same jvm, it is a big overhead to do remoting or to go through a BC to send exchanges. But if you are remote, you can easily use HTTP or JMS instead of using a remote api. A user just sent a mail about using the RemoteClient to query endpoints (which seems to not work in his case), but i'm not sure of the use for that. Just trying to find a good use case. Cheers, Guillaume Nodet Guillaume --
James ------- http://radio.weblogs.com/0112098/
