A wise old hermit known only as Ara Abrahamian <[EMAIL PROTECTED]> once said:
> > 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. And still extending it, I assume? In which case, I guess the problem is just to get it to omit the methods that were in the ancestor bean. I guess there's more to it that just checking if its in the concrete class or not, since it could be in the abstract bean and overloaded in the concrete bean - in that case, the abstract remote interface would contain the method so we wouldn't want it in the concrete remote as well. > > - 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). Strangely enough, the next method I'd tried to add this afternoon was... public Collection ejbFindAll() which puts a findAll() in the generated AbstractEntityHome, so (assuming it was fixed so the concrete home doesn't just include it as well anyway) we'd want the concrete home to inherit it. > > >- 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. Okay, agreed (I'll just have to remember to cast it back to the concrete one before I call the extra getters/setters). > setData should accept concrete > dataobject type imho, otherwise it doesn't have all necessary data, > which is wrong. Basically I agree, but I can see two problems: - you can't ensure setData gets implemented in all the concrete beans by including a public abstract setData in the ancestor, since setData(AbstractDO) and setData(ConcreteDO) are different methods. - you can't specify the transaction requirements globally for all the concrete beans by putting the tag against setData in the abstract bean (for the same reason, they're different methods). The only obvious way I can see around those problems is for the concrete bean's setData to also take an AbstractDO, but have setData cast it to the concrete one before using it (throwing an ClassCastException/EJBException if they passed the wrong type). That way, it's the same method so everything's inherited as required. Andrew. _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
