It's the signature that can't be side-tracked however. Becuase the proxy
ends up implementing an interface that throws remote exceptions, there
doesn't appear to be anyway to shield the client from haveing to at least
have an try-catch block. Of course this try-catch block will do nothing
since the dynamic proxy is handling the exception.
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Van Couvering
> Sent: Friday, August 18, 2000 7:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Using Dynamic Proxies for Fault Tolerance
>
>
> >From what I understand you *can* throw RemoteException in an
> implementation
> method, you just don't *have* to.
>
> The other thing you can do is re-throw the RemoteException as an
> EJBException...
>
> Dynamic proxies are great, I would definitely give them a shot.
>
> David
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> > Sent: Thursday, August 17, 2000 7:41 AM
> > To: [EMAIL PROTECTED]
> > Subject: Using Dynamic Proxies for Fault Tolerance
> >
> >
> > I could use some advice on a pattern to use to enable fault
> > tolerance on the
> > client-side of the EJB scenario. My clients access session
> beans through a
> > Facade (FundBroker) interface that is implemented on my client by
> > a class named
> > FundBrokerImpl.
> >
> > If the client invokes a method in FundBrokerImpl, the method
> > simply makes the
> > call against the appropriate session bean. If I receive a remote
> > exception, I
> > attempt to resubmit the request a number of times before trying
> > more drastic
> > actions. I understand that I could put the following code in all
> > of my methods:
> >
> > while (attempts < 3) {
> > try {
> > remote.getSomeValue();
> > return;
> > } catch (RemoteException rx) {
> > attempts++;
> > }
> > }
> > // handle fatal error
> >
> > I want to use Dynamic Proxies in JDK 1.3 to leverage the proxy
> > pattern so I can
> > eliminate some of the monotonous coding. I also want to eliminate
> > the client
> > (but not this proxy) from dealing with any extreme fatal errors.
> > Therefore, one
> > stipulation that I have is that the method signature in
> > FundBroker cannot throw
> > a RemoteException.
> >
> > FundBroker: Value getSomeValue();
> >
> > The problem is that the method signature in the implementation
> > class also cannot
> > throw RemoteException. Unfortunately, this method will contain
> > the call to the
> > remote ejb interface, which most certainly *will* throw
> > RemoteException. Of
> > course, the compiler won't let this conflict pass unnoticed.
> >
> > I know of several ways to get around this pattern without
> > resorting to Dynamic
> > Proxies, but I was wondering if anyone can think of a way I can
> > use this very
> > cool feature.
> >
> > thanks,
> > jim
> >
> > ==================================================================
> > =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
