> > - since there's no actual PK fields in the abstract EJB the generated > PK > > ends up with two public AbstractEntityPK() methods (with the same > > signature) > > so won't compile. > > A bug!
Fixed. > > - in either case, I still have to include extends="..." in all the > other > > EJBs, but presumably if this was in the abstract class instead it > would be > > picked up by all the others. However, that would stop me doing any > > generation for the superclass. > > I really think it should be automatic: if you have a base bean and it > has a home/pk/etc class then automatically derived classes should use > these base classes for their home/pk/etc. Agree? Of course highest > priority is what you specify in derived classes but if you don't then > this is a reasonable and good default. Implemented and it really rocks!! I modified samples too (removed all those extends="blabla" statement, it does it all automatically and I think the defaults are very handy). > > - the generated getData/setData in the BMP classes use the DataObject > > subclass for the return/parameter type, not the abstract one. Because > of > > this, they won't compile since the signatures have changed from the > ones I > > had to define in the abstract EJB class. > > Vincent has done the data-object inheritance part. Honestly I can't > understand what he has done :-) > But I really really think the logic should be polished and refactored. > It's a common case, isn't it? Whenever we generate a method we shouldn't > dumbly output the concrete type as the return type. We should check > superclasses for methods of same signature and try to find a common base > class and use that type. It should be generalized as a template tag in > XDtMethod. I'll work on this one tomorrow. > > doesn't seem to contain COMP_NAME and JNDI_NAME (though I'm not sure > why) > > so > > no chance of clashes. By the way, I notice in the other classes these > > fields aren't final - should they be? > > Sure. It's a bug. Fixed. > Well, if you take a look at Customer data object class you see fields > from PersonDataObject are also included, which is redundant. It's again > a common case that we should generalize in XdtMethod. It's *wrong* right > now. This one for tomorrow too. PS: take a close look at, we should make sure the automatic inheritance stuff works as expected. 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
