> >Hmm, what about ConcreteEntityEJB extends AbstractEntityEJB, but not > >ConcreteEntityEJB extends AbstractEntityEJB implements > >javax.ejb.EntityBean?
So we should change the logic a bit. Extends from something should be in higher priority than implements javax.ejb.EntityBean. > That looks better, the home/remote/pk/dataobject all inherit from their > abstract counterparts. However, there's a few things that could maybe be > improved and a couple of show-stoppers: > > - the concrete data object still includes stuff for the fields that were > in > the abstract data object i.e. protected members, getters (probably setters > too, but the particular fields I'm using don't have them), and the > constructors don't use the super's constructor (I suppose toString and > equals could use the ancestor's equivalent methods, too). Oh yeah, needs work. > - the concrete remote interface contains all the methods from the abstract > remote interface again. Having said that, its getData and setData methods > still take/return the abstract data object, which I suppose probably isn't > what you'd want anyway, so perhaps the remote interface shouldn't inherit > from the abstract one anyway? It shouldn't contain all the methods from abstract remote intf, but it's absolutely ok to have an abstract one. > - the concrete home interface's create and findByPrimaryKey take the > abstract data object & pk as arguments, but return a concrete remote > interface. Since the abstract home has identical methods returning the > abstract remote, this stops it from compiling! Oh yeah, needs work. > I'll see if I can come up with a workaround. Thinking about it, we don't > actually need create and findByPrimaryKey in the abstract EJB, since it's > never going to be instantiated; for that matter, do we actually need a > home/remote for it at all? Perhaps the ideal situation is to only > generate > the abstract PK & data object (and have the concrete ones make more use of > them), with the home/remote generated as normal and only using the > concrete > PK/DO? IMHO we need home/remote for it, though I'm not sure about abstract home, it should be uncommon, but fairly possible (for example you want to define a Collection findByCreationDate()/etc for all ejbs derived from PersonBean, you put these finders in PersonBeanHome). > >- getData() return type still needs some work in inheritance case. > > I'll have to think about this some more. On one hand, they might > reasonably > be expected to use concrete data objects, on the other hand if I want to > be > able to specify transaction requirements in the abstract EJB, they have to > use abstract ones and downcast where necessary (which I guess would also > involve handling any ClassCastExceptions). getData's return type should be the abstract dataobject, but it should new concrete dataobject and return it. setData should accept concrete dataobject type imho, otherwise it doesn't have all necessary data, which is wrong. Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
