Okay, your "two reasons" make sense to me why it would not be a good idea to
have the EJB implement its remote interface. I just tried deploy an EJB
which had a method in the remote interface that I didn't define in the bean.
Everything compiled and jar'd okay, but when I tried to deploy JBoss told me
a method was missing (and it told me which one - very nice!) I think it
would be much better to have such errors caught at build time, instead of at
deploy time. I've only used one other EJB container (Oracle) and deploying
with that container was a real nuisance. In general, it's always best to
catch errors as early in the process as possible. Perhaps I should submit a
recommendation to Sun that either javac or jar take a -EJB flag, which would
inform it to check to make sure that all required methods are implemented.
----- Original Message -----
From: "David A. Ventimiglia" <[EMAIL PROTECTED]>
To: "jboss-user" <[EMAIL PROTECTED]>
Sent: Sunday, March 25, 2001 4:43 PM
Subject: Re: [JBoss-dev] Fw: Fw: [JBoss-user] access modifiers lost in
EJBprogramming ?
> "David A. Ventimiglia" <[EMAIL PROTECTED]> writes:
>
> > Thanks, Alexander. You're right about RemoteException. I'm mistaken.
The
> > implementation class's methods wouldn't need to declare RemoteException
if
> > it implemented the EJB's remote interface. However, the EJB's
> > implementation class is not intended to be remotable. The interface
> > javax.ejb.EnterpriseBean extends java.io.Serializable, and that's it.
The
> > EJB's remote interface extends javax.ejb.EJBObject which extends
> > java.rmi.Remote. If the implementation class implemented the remote
> > interface then it would be remotable, and more troubling, would be an
> > EJBObject. It should not be for at least two reasons. One is that it
would
> > be legal for an instance of such a class to pass itself to another EJB,
> > allowing that class to directly invoke methods on the passed object
without
> > going through the container. Another reason is that javax.ejb.EJBObject
> > itself defines methods which are implemented by RMI stub classes. If
the
> > bean implementation class were an EJBObject, it would have to declare
these
> > methods, but they would be meaningless.
> >
> > (with heavy debt to Richard Monson-Haefel's book on EJBs)
> >
> > Cheers,
> > David
> >
> > ----- Original Message -----
> > From: "Alexander Jerusalem" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>; "jboss-user"
> > <[EMAIL PROTECTED]>
> > Sent: Sunday, March 25, 2001 2:36 AM
> > Subject: Re: Fw: [JBoss-user] access modifiers lost in EJB programming ?
> >
> >
> > > In my view, an interface defines a contract between the implementer
and
> > the
> > > client of some functionality. A programming/runtime environment has to
> > > ensure that this contract is met as far as it can (the semantic part
of
> > the
> > > contract is not enforcable anyway). How it does this is irrelevant. In
EJB
> > > the client gets a reference to the Remote interface of the EJB and the
> > > container is responsible for making sure that those methods are
> > implemented
> > > in the EJB implementation at deployment time. I think that's ok, what
else
> > > could be done to make sure the contract is met?
> > >
> > > Some other things that have come up on the thread:
> > > An EJB implementation class *can* implement it's Remote interface.
There's
> > > nothing that keeps it from doing so. It's just not necessary because
the
> > > contract is enforced via other means anyway.
> > >
> > > David, if the implementation class implements the Remote interface
(and
> > > that Remote interface has a throws clause for RemoteException) this
does
> > > *not* mean that the implementation class needs to declare those
exceptions
> > > in it's throws clause as well. The throws clause of an interface is
always
> > > a superset of the throws clause of any implementation class. As I
> > > understand it an EJB implementaion class *is* meant to be remotable
since
> > > you have to define a Remote interface for it that you specify in the
DD
> > > and/or in the implements clause.
> > >
> > > As to the public private discussion: It is possible to define an
interface
> > > that is only accessable within the package in EJB. The only limit is
that
> > > this interface cannot be a Remote interface that is managed by the EJB
> > > container (at least I think so). What I've been missing since Java
came up
> > > are the friend declarations of C++.
> > >
> > > Alexander Jerusalem
> > >
> > >
> > > At 11:30 25.03.01, David A. Ventimiglia wrote:
> > > >My understanding of why the EJB implementation class doesn't
implement
> > the
> > > >EJB's remote interface is that it's because the implementation class
does
> > > >not define a remotable object. For instance, if the implementation
class
> > > >did implement the remote interface, its implementation of business
> > methods
> > > >would need to throw javax.rmi.RemoteException, which is not something
> > that
> > > >should be thrown by an instance of the implementation class. Perhaps
> > > >someone can comment on whether this is correct or not.
> > > >
> > > >Cheers,
> > > >David
> > > >
> > > >----- Original Message -----
> > > >From: "Guy Rouillier" <[EMAIL PROTECTED]>
> > > >To: <[EMAIL PROTECTED]>
> > > >Sent: Saturday, March 24, 2001 8:59 PM
> > > >Subject: Re: [JBoss-user] access modifiers lost in EJB programming ?
> > > >
> > > >
> > > > > Interesting this topic should come up now. I've been wondering
why
> > EJBs
> > > >are
> > > > > not defined as implementing their remote interfaces. A session
bean,
> > for
> > > > > example, is defined as implementing only SessionBean, and not its
own
> > > >remote
> > > > > interface. I agree with your sentiment below, that an interface
is a
> > > > > specification. IMHO, EJBs should be defined as implementing their
> > remote
> > > > > interfaces, as that interface is the spec to which clients are
> > written.
> > > > > This would enable the compiler to ensure that the EJB has
completely
> > > > > implemented its remote interface.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: fractals <[EMAIL PROTECTED]>
> > > > > To: <[EMAIL PROTECTED]>
> > > > > Sent: Tuesday, March 06, 2001 7:35 AM
> > > > > Subject: Re: [JBoss-user] access modifiers lost in EJB programming
?
> > > > >
> > > > >
> > > > > > I don't think of an interface as a "pattern specifically about
the
> > > > > publicly
> > > > > > available views/facets of an object". You can define interfaces
that
> > are
> > > > > > visible only from the package, and in fact, this is a feature
that I
> > use
> > > > > > often in my designs. In my opinion, interfaces are a means for
> > > > > > specification: they state what you have to implement if you want
to
> > be
> > > > > > coherent with your designs. That is something that applies as
well
> > for
> > > > > what
> > > > > > you intend for the general public as for what you intend for
your
> > > > > > application's internals.
> > > > > >
> > > > > > In EJB, I see the home and remote interfaces for a specification
as
> > > >well:
> > > > > > they state what features you want the container/application
server
> > to
> > > > > > exhibit from a specification you give and partially implement. I
the
> > > >case
> > > > > of
> > > > > > ejb-references, you could want to make calls on remote objects
that
> > you
> > > > > > wouldn't want others to see.
> > > > > >
> > > > > > But if I'd like to have something like this in j2ee, it's
probably
> > due
> > > >to
> > > > > > the fact that I'm a beginner in using those tools ;-)
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > candide
> > > > > >
> > > > > > > There is no way to define anything but public method in any
> > interface.
> > > > > > This
> > > > > > > is not limited to remote interfaces or EJB. Interfaces are an
OO
> > > >pattern
> > > > > > specifically
> > > > > > > about the publicly available views/facets of an object. If you
> > want to
> > > > > > hide
> > > > > > > some method of an EJB implementation then don't put the method
in
> > the
> > > > > > > public interface. EJB adds the ability to restrict who can
access
> > the
> > > > > > public
> > > > > > > methods as well, so if the method should be available to some
you
> > have
> > > > > > > this path as well.
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "fractals" <[EMAIL PROTECTED]>
> > > > > > > To: <[EMAIL PROTECTED]>
> > > > > > > Sent: Monday, March 05, 2001 2:37 PM
> > > > > > > Subject: [JBoss-user] access modifiers lost in EJB programming
?
> > > > > > >
> > > > > > >
> > > > > > > > AFAIK, there's no way to make a method anything else than
public
> > in
> > > >a
> > > > > > remote
> > > > > > > > interface. Sad, because I *would* like to hide some of the
> > methods I
> > > > > > define
> > > > > > > > for some of my beans.
> > > > > > > >
> > > > > > > > Really, is there no way to get this cornerstone of OO
> > programming
> > > >back
> > > > > > into
> > > > > > > > the EJB realm ?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > candide
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > JBoss-user mailing list
> > > > > > > [EMAIL PROTECTED]
> > > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > JBoss-user mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > JBoss-user mailing list
> > > > > [EMAIL PROTECTED]
> > > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > >
> > > >
> > > >_______________________________________________
> > > >JBoss-user mailing list
> > > >[EMAIL PROTECTED]
> > > >http://lists.sourceforge.net/lists/listinfo/jboss-user
> > >
> > >
> > > _______________________________________________
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
