re: 2) I can't speak for any deployment tools since I don't use them, but the
Weblogic EJB
server does indeed support inheritance in remote interfaces. I use it
extensively.
Lou
Richard Monson-Haefel wrote:
> A couple of notes about the business interface strategy.
>
> 1) The methods declared in the business interface need to throw RemoteException
> in order for this to work. This is stated clearly in the book but I noticed you
> didn't include the throw clauses in your example. The bean does not need to
> declare these throw clauses when it implements the business interface.
>
> 2) This strategy does not work in the J2EE RI or (according to my readers) in
> the Weblogic EJB server. The deployers and runtime engines of these servers do
> not recognize interface inheritance.
>
> EJB servers are supposed to support remote and home interface inheritance (EJB
> 1.1 specification section B.2). Its unclear if the business interface
> inheritance strategy outline in the O'Reilly's EJB book is technically the same
> kind of inheritance since the business interface is not a remote interface.
>
> At any rate the business interface was not intended to, nor should it, be
> specified as a parameter or return type in remote invocations. Only value types
> and interface that inherit from java.rmi.Remote qualify as parameters and return
> types in Java RMI. The business interface is simply intended to provide a
> common interface between the remote and bean class to in force consistency
> between these types. Its not required.
>
> Thanks,
>
> Richard
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
> Jeff Oh wrote:
>
> > Phil Lewis wrote:
> >
> > <snip>
> >
> > The problem is that the MyClassEJBFactory creates an instance of the remote
> > interface using MyClassHome. When I try to fave the MyClassEJBFactory return
> > the remote interface, I get a compile time error saying that the factory
> > method
> > needs to return MyClassBusiness.
> >
> > </snip>
> >
> > This seems a bit strange to me, as I'm doing something very similar in some
> > benchmark code that I've written, where I have a number of beans that
> > implement the same interface with different implementations for
> > benchmarking.
> >
> > Basically, I've implemented it as follows
> >
> > // Business interface holds all business methods (a la Monson-Haefel, et
> > al)
> > public interface MyClassBusiness {
> > public method1()
> > ...
> > }
> >
> > // Remote Interface
> > public interface MyClass extends MyClassBusiness, javax.ejb.EJBObject {}
> >
> > // Local version of same - could be an interface or a class
> > public interface MyClassLocal extends MyClassBusiness {}
> >
> > public abstract class MyClassFactory {
> > public MyClassFactory() {};
> > public abstract MyClassBusiness create();
> > }
> >
> > public MyClassEJBFactory extends MyClassFactory {
> > ...
> >
> > public MyClassBusiness create() {
> > return (myClassHome.create());
> > }
> > }
> >
> > While I haven't tested this construction, I see no reason why the compiler
> > would complain about this since myClassHome.create() returns a MyClass
> > interface which IS a MyClassBusiness. Note that to make this work, you need
> > to put all your business methods in a separate interface which is inherited
> > by both MyClass and MyClassLocal a la Monson-Haefel. If your MyClass
> > interface extends MyClassBusiness, then your MyClassEJBFactory should be
> > able to cast MyClass interfaces to MyClassBusiness interfaces with impunity.
> >
> > Note that this *does* mean that you lose the stuff in javax.ejb.EJBObject.
> > If this is a problem, then your local object needs to implement
> > javax.ejb.EJBObject as well, in which case MyClassFactory can return MyClass
> > interfaces instead of MyClassBusiness interfaces. Alternatively, you could
> > use run-time casting (yuck!), or implement a third interface which extends
> > MyClassBusiness with the methods from javax.ejb.EJBObject() that you
> > require...
> >
> > Jeff 8-)
> >
> > ===========================================================================
> > 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".
--
Lou Bona
Chief Software Architect
AgentGo.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".
