A wise old hermit known only as Ara Abrahamian once said: >Hmm, what about ConcreteEntityEJB extends AbstractEntityEJB, but not >ConcreteEntityEJB extends AbstractEntityEJB 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). - since the abstract EJB didn't have any PK fields, I can't tell if that would have behaved similarly. - 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? - 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! 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? >- 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). >- two no arg constructors shouldn't happen, >XDtEjbPersistent:ifHasAtLeastOnePkField should handle it. It's a bug. ifHasAtLeastOnePkField was using isPersistentField, not isPkField. I've fixed it, and I'll check it in this evening. Andrew. _________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
