Ara.
> 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.
> 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.
A bug!
> - 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.
No AFAIK.
> - 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.
> - 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.
> - 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?
Sure. It's a bug.
> 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).
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.
So for all of the above items we should write code and handle them all.
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
