I decided to go the xdoclet route and am generating remote and home
interfaces with the ejbdoclet task.
Question is about the default behavior. My Bean has an abstract base
class which appears to cause ejbdoclet to copy this name as a base
class for remote and home interfaces. I can't see what it is trying to
achieve.
..../**
....* @ejb.bean name="My" type="Stateless"
....*/
....class MyBean extends BaseBean
....{
........// methods
....}
XDoclet is generating a remote interface that looks like this
....interface My extends BaseBean
....{
........// methods
....}
and for the remote home
....interface MyHome extends BaseBeanHome
....{
........// methods
....}
Obviously this doesn't compile with the interfaces extending an
abstract class and the home version doesn't exist.
To get around the problem I am specifying the following but this seems
like a really bad solution since I will have to duplicate this for
every bean.
....* @ejb.home
....* generate="remote"
....* extends="javax.ejb.EJBHome"
On 12/13/06, Ashish Narvekar <ashish.narvekar@xxxxxxxxx> wrote:
I fully endorse what James is saying about thinking about always using
remote interfaces. I don't know if all appservers do this but I can
definitely vouch for jboss. I have even verified in the debugger that jboss
intelligently optimizes for in-the-same-jvm calls.
Ashish.
On 12/13/06, James Carman <james@xxxxxxxxxxxxxxxxxxxx> wrote:
> Or, as one of the comments points out, you could avoid local
> interfaces altogether and just access it via the remote interface.
> The app server will take care of optimizing the call if it's really a
> local call.
>
> On 12/13/06, Keshav Kode <keshav.kode@xxxxxxxxx> wrote:
> > As I see it you have 3 potential options:
> >
> > 1) use something like xdoclet to generate interfaces
> > 2) move to EJB3
> > 3) use 'Business Interface' pattern
> > (
http://www.theserverside.com/patterns/thread.tss?thread_id=12363)
> >
> > Hope this helps.
> > Keshav Kode
> >
> > On 12/11/06, Edward Sumerfield < esumerfd@xxxxxxxxxxxxxx> wrote:
> > > Anyone have any fancy ways of removing the duplication between these
> > > two interfaces? One needs to throw the RemoteException and the local
> > > does not. Makes sence in theory but it means duping every method in
> > > every bean.
> > >
> > > I could go code generation, copy from EJBObject to EJBLocalObject and
> > > filter out the "throws RemoteException" string. Should be a simple ant
> > > task but someone must have solved this inefficiency already?
> > >
> > > --
> > > Ed
> > --
> > Thank you,
> > Keshav Kode
> > Keshav.Kode@xxxxxxxxx
--
Ed
|