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
