----- Original Message -----
From: "Cedric Beust" <[EMAIL PROTECTED]>
To: "Joel Riedesel" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 2:55 PM
Subject: RE: Design for both Remote/Local, is it possible?
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Joel Riedesel
>
> > Ahhh, but I'm not hearing that it shouldn't work or can't work. Only
> > a "probably not going to work". I would much prefer a reason that
> > it will or won't work according to the EJB specification.
>
> Put yourself in ejbc's shoes for a minute (yes, it's quite a stretch :-)).
>
> You are introspecting a LocalHome and looking for methods matching a
certain
> naming convention. All methods that throw RemoteExceptions are
> automatically excluded from this introspection, so ejbc will miss them.
And
> conversely for remote interfaces and methods that do not throw
> RemoteExceptions.
Now that's useful information. I did not know that. Crum.
>
> Since Java doesn't allow you to have identical methods with different
throw
> signatures, ejbc will end up with an incomplete view of the picture and
will
> probably let you know that it expected certain methods but couldn't find
> them.
(I still wasn't doing that....)
>
> > I want to write code elegantly (reuse in many cases) and also do the
> > right thing when it comes to whether I want to use the remote or the
> > local object I am trying to access. If I were not going to an EJB
world,
> > I'd be spending my energy working on the whole dynamic-proxy thing to
> > clean this up.
>
> Dynamic Proxies won't help you there (besides, they're useless for EJB 2.0
> CMP).
Not relevant.
>
> > Sounds interesting. Where does EJBGen come from?
>
> Me :-)
And? What does that mean? Are you suggesting I write my own EJBGen?
Or is this something that you generally make available?
>
> > If I didn't have to worry about scalability, everything would simply use
> > the remote interfaces. Period. But my boss would probably fire me
> > then when our product didn't scale. Thus the need to also have local
> > interfaces.
>
> I am still a bit puzzled by the fact that you seem to be using similar
> methods both locally and remotely. Typically, remote methods will be on
> stateless session beans and will be used to invoke operations. Then the
> stateless session bean will mostly make calls on Entity bean accessors.
> Different semantics, different localities.
I'm not at liberty to explain my architecture. However, suffice it to
say that objects in our system may be used both locally and
remotely. The design is a purely remote design but one wants local
access a majority of the time for performance. If the beans in the
system are all running in the same VM then they all want to use local
access to each other. That's all I'm talking about. No big thing.
Thanks for your comments,
Joel
===========================================================================
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".
