I'm not certain, but my container vendor's approach to handling and
declaring RMIExceptions, may have rendered my dilemma mute.
According to the 1.1 spec, java.rmi.Exception on business methods has been
deprecated for non-application errors. I always took this to mean that it
*should* still be thrown for network errors, but it seems that this is not
the case.
If my business methods do not need to throw RemoteException's, the world is
looking a lot purer. At least from a design standpoint. At implementation,
these exceptions still have to be caught.
I am curious how other vendors interpreted the spec. The same?
jim
----- Original Message -----
From: James Cook <[EMAIL PROTECTED]>
To: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
Cc: James Cook <[EMAIL PROTECTED]>
Sent: Wednesday, November 17, 1999 9:29 AM
Subject: Re: Re: Remote Interface Question
> After reading the initial question, I didn't think this thread would grow
> beyond one response. Since everyone's attention is focused...
>
> I haven't been able to come up with a design pattern whereby my business
> interface (Sample) does *not* have to throw a RemoteException. I am using
> the traditional:
>
> +--------+ +--------------+ +-----------+
> | Sample |<---| SampleRemote |-->| EJBObject |
> +--------+ +--------------+ +-----------+
> ^ ^
> | +--------------|
> | +------------+
> +-------------+ | SampleBean |
> | SampleState | +------------+
> +-------------+
>
> Sample has to end up throwing RemoteException's because the Bean's
> implementation of these business methods have to throw RemoteExceptions.
(At
> least, this is what my container is telling me at deployment. The spec
> [section 6.2.5] seems to back this up as well.)
>
> When I pass a state object to my client (a read-only snapshot) it
implements
> my business interface. I have to catch RemoteExceptions in all of my
client
> code, even though I have a local object.
>
> It seems like a lot of extra work, but I see why it is required. I was
just
> wondering if anyone has come up with a better pattern.
>
> jim
>
> ----- Original Message -----
> From: Rickard �berg <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, November 17, 1999 7:32 AM
> Subject: Re: Remote Interface Question
>
>
> Hey
>
> Frank Sauer wrote:
> > That's right.
> > There is one often overlooked issue with this approach though.
> > The business methods in the remote interface must all throw
> > RemoteException per EJB spec, but the implementation doesn't have to.
> >
> > Except when you use this pattern, now the impl implements the business
> > interface and must all of a sudden also throw the RemoteException
> > and it cannot throw exceptions not specified in the business interface.
>
> Your above comment is incorrect. The throws clause of method in an
> interface-implementation must be a subset of the interface throws
> clause, i.e. it may be null.
>
> Suggestion: in order to use the type checking that interface
> implementation gives you, you should divide the interface into two: one
> which only contains the business methods, and one which extends the
> first interface and EJBObject. Your bean implementation may now
> implement the business interface without risk of using "this" properly,
> and you do not need to implement dummy methods for EJBObject method
> declarations.
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
>
===========================================================================
> 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".
