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.
Just a bit of a pain I guess.
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 .....
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".
