I'm trying to create some BMP entity EJBs that use a DAO (each). Because of their similarities, it made sense to try and use abstract superclasses, so I've defined an AbstractEntityEJB and AbstractDAO.
The abstract EJB implements EntityBean, and contains - stuff to store (and clear) the EntityContext in set/unsetEntityContext. - xdoclet @ejb:persistent-fields that are common (and read only) to all the tables involved (creation and modification timestamps and users). - an abstract getDao() method with return type AbstractDAO. - ejbCreate, (a does-nothing) ejbPostCreate, ejbLoad, ejbStore, ejbRemove, ejbFindByPrimaryKey and ejbFindAll methods that delegate to the DAO. These all use AbstractEntityPK and AbstractEntityDataObject classes where appropriate for passing the PK and state (with the PK obtained from the context we stored earlier) e.g. ejbLoad uses setData(getDao().load((AbstractPFDEntityPK) ctx.getPrimaryKey())), ejbStore uses getDao().store(getData()). However, because of this, I also needed to declare getData and setData in the abstract EJB, using the abstract DataObject class. The abstract DAO declares create, load, store, remove, findByPrimaryKey and findAll methods, called from the corresponding methods in the EJB. So, I just need to write a concrete DAO for each EJB that has the SQL for its particular tables/columns, and include in each concrete EJB a getDao method returning its specific DAO, plus its remaining persistent fields (and any extra finders etc. specific to that EJB). Which just leaves the xdoclet bits... Since it's not an actual EJB, in AbstractEntityEJB I used @ejb:bean generate="false". Since I've referred to AbstractEntityPK and AbstractEntityDataObject I'd figured xdoclet might as well generate them, however: - 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. - it contains a static final serialVersionUID, which I guess will cause problems for the other generated PKs (which will inherit from it, but include their own value)? Likewise for the DataObject, which also contains a final serialVersionUID. - I guess I could use @ejb:pk generate="false" and supply one without these problems, but in the DataObject's case that means I lose the automatic maintenance if I add any more common persistent fields. - 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. - 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. - the home and remote interfaces, remarkably, seem okay. The abstract home 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? However, for all these generated files, the ones for the subclasses all include the stuff that was in the abstract ones anyway, so is there any advantage in having them extend an abstract one? Is it really worth it, generating anything at all for the abstract class? And is that the reason the BaseEntityBean and BaseTellerBean in the samples get excluded from the fileset in the ejbdoclet task i.e. because that's the best way to handle it? (in which case, some comments in the sample classes explaining that reasoning would have saved me wasting time rediscovering that). Andrew. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
