just fyi... I finished the stuff with a "deep" change to get #2 working (so
I expose the invokers).
I like it.
the stuff runs and TestBeans completes.. he he!
I will commit the stuff tomorrow morning (wife calling :))) gotta go :))))
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> Sent: Sunday, August 13, 2000 4:45 PM
> To: jBoss Developer
> Subject: [jBoss-Dev] handle.getEJBObject() can'o'worms
>
>
> 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.
> ________________________
>
>
>
