It seems that the generation of support classes is heavily biased on the deployable bean implementing the EntityBean interface.
I have an entity bean superclass that does the implementing of EntityBean. This is a design that I have seen many others use also. This base class performs some dummy implementations of ejbActivate, ejbPassivate, and takes care of setEntityContext. It also performs JNDI lookups, logging, etc. XDoclet seems to want to include this base class in its generation. On the actual bean subclass, xdoclet generates interfaces, dao classes, and PK classes that want to extend the non-existant interfaces, dao classes, and pk classes of the base class. To workaround this problem I have placed generate false tags on the base bean class.. Furthermore, and the more troubling problem, I have to specify tags on the subclass bean to specifically extend javax.ejb.EJBHome, (also remote, and the locals). I also can see that some people may not have the source available to them for this base bean class. Are they out of luck? Perhaps I am doing something wrong as I am a newbie to this. Perhaps there is an intelligent way to decide whether a bean's superclass should figure into the generation process. I think that a new attribute for the @ejb:bean tag would suffice. Something to the effect of 'generation-root'. This could be a signal to the generator that the superclasses of this bean are not meant to be part of the class hierarchy when generating the support classes. jim _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
