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".
