Couple of points below...
--- "J. Matthew Pryor" <[EMAIL PROTECTED]> wrote:
> All these approaches I have seen gloss over the fact that all methods
> in the
> "local" variant of the interface still have to declare themselves as
> throwing java.rmi.RemoteException which logically cuts across the
> implication that these are explicitly local objects, but I can
> understand
> all the other reasons for having to put the throws clauses there.
The local objects do *not* have to throw RemoteExceptions. The Remote
interface does have to declare that it throws RemoteExceptions, but the
local class does not. In Java you are allowed to remove exceptions when
implementing an interface, you just can't add any new ones.
So if the interface declares that it throws RemoteExceptions then you
can use the same interface for your EJB objects as your local objects.
Furthermore, your local objects do not need to throw the
RemoteException which makes coding the client side much more tolerable.
> I suppose this becomes a requirement for all methods in an interface
> then,
> if you ever want your interfaces to form the basis of this kind of
> interface
> design, you should always throw java.rmi.RemoteException
>
> Kind of ugly, but .....
I agree, the fact that essentially all interface methods have to throw
a RemoteException is a little ugly. But its tied to a fundamental part
of RMI and the Java spec so I don't think it will change anytime soon
:)
If you want to ignore spec compliance there is always Voyager, which
doesn't require RemoteExceptions.
-Brent
>
> Matthew
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Thursday, July 13, 2000 8:00 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: MI2: Strategies to reduce EJB development time?
> >
> >
> > Try this: http://www.javasuccess.com/cat1_may.html
> >
> > This was one of the "Challenge Winners".
> >
> > -Chris.
> >
> > CC: List because I posted the wrong URL before. Duh!
> >
> > > -----Original Message-----
> > > From: Humphrey Sheil [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, July 13, 2000 10:01 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: MI2: Strategies to reduce EJB development
> time?
> > >
> > > Chris,
> > >
> > > thanks for the reply. I think your idea below would help a
> > lot, if it was
> > > the subject of a JSR or the spec. was expanded / supplemented to
> talk
> > > about
> > > required development features. Then it could become a
> > selection criterion
> > > for IDEs.
> > >
> > > RE: design patterns, I guess you meant
> > http://www.javasuccess.com and not
> > > http://www.java.success.com
> > >
> > > I couldn't find the (incomplete) design pattern you mentioned
> > or even one
> > > that looked potentially like it. I looked here:
> > > http://www.javasuccess.com/cookbook.html
> > >
> > > and here: http://www.javasuccess.com/design_patterns.html but no
> joy.
> > >
> > > Is it posted on the website yet?
> > >
> > > Regards,
> > >
> > > Humphrey
> > >
> > > -----Original Message-----
> > > From: Chris Raber [mailto:[EMAIL PROTECTED]]
> > > Sent: 11 July 2000 21:18
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: MI2: Strategies to reduce EJB development time?
> > >
> > >
> > > What would be ideal is a light weight, non-distributed EJB
> > > server/container
> > > that runs In The Client JVM!
> > >
> > > Since we don't have this today, and since the integrated
> > environments are
> > > immature ( I have heard this from our customers too...), you
> might
> > > consider
> > > some design patterns that eliminate EJB'ness during development.
> In the
> > > GemStone/J Developer's Guide, the domain objects are not-EJB's.
> > EJB's wrap
> > > them for deployment. So one could develop, test and debug prior
> to
> > > wrapping
> > > as beans and deploying to EJB.
> > >
> > > There is also a design pattern for this approach on
> java.success.com. It
> > > is
> > > admittedly incomplete, but it's not a bad start.
> > >
> > > -Chris.
> >
> > ==================================================================
> > =========
> > 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".
>
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/
===========================================================================
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".
