is a difficult one. here is why. handle is serializable so that ideally it can live by itself, serialize go in mail attachement :) and reappear in a new VM... no connection to the object and it must be able to rebuild the EJBObject all by itself. Now that is easy on the container since there are calls on the JRMPContainerInvoker to do just that (called when we do create and find)... but the problem we have is that there is no way for us to call the container directly from the client outside home or object so far. Building an EJBOBject or EJBHome we get a reference to the container (JRMPCOntainerInvoker) and we could pass anything through these (even fake methodInvocations but that is besides the point). But I have no way of finding the "invoker" directly and I have to go through home or object. The invocation logic in the current Proxies is a bit "naive", (there is none... do look at the lookup/failover logic in jboss1.0 FYI)... Fine, so i started going through home(that I can lookup) but then the problem is that a "getEJBOBject "must be declared in the Home proxy, fine so I added the Handle method to that proxy, realizing that it was a mistake since the handle doesn't take an argument. So I am screwed... I need to declare a "fake" system class with all the right calls that need to happen (in our case at least the getEBJOBject) and all the calls we would want to do with the home and pass that with the Proxy build. I am saying there is NO way outside the additional interface to work through home or object in the current base. So that is one solution, a hack really, but works around the naive design. The other solution has to do with high availability. in jboss1.0 I had coded it by having a failover in case of failed invocation on an instance (simple Proxy logic, you can check it out). That involved looking for a bare invocation channel to use. yes that was specific in the case of jboss1.0 since we used a common channel through and through which jboss2.0 doesn't do. but it would boil down to having a channel per container exposed in JNDI. That channel is then "non-typed" so I can have invocations that send teh getEJBOBject(id) call that I have coded in the container already. That is a more generic solution. does it make sense? XP? design? if you have even opinions it would help at this point, otherwise I will just think about it some more and code it... This code as it is is clumsy, and we need something much more "professional". Kid any other ideas? you have painted ourselves into a corner... regards marc ________________________ Marc Fleury Chief Technology Officer Telkel, Inc. ________________________
