On Tue, 30 Oct 2001, Andrew Stevens wrote: > > which other files? > > PK, data object, home & remote interfaces. In practise, if you don't want > the BMP/CMP/Session class generated you probably wouldn't want those done > either, but I assumed the @ejb:pk etc. had their own generate parameter to > control that. I must admit I didn't check those, though, it was only the > @ejb:bean one I tested.
yep - so we want pk to check for ejb:pk generate=false || (ejb:bean generate=false && ejb:pk generate != true)? makes sense > It is a good thing; it means one of the bugs is sorted. There is still a > problem with the ejb-jar.xml, but that was the other one :-) It doesn't > reference the non-existent BMP class any more, unfortunately it doesn't > reference anything... hehe... well its not broken (o: I dont know I really gave it the time it deserves... see how we go this week (o: > > hmmm.. yeah, so we have two scenarios: > > 1) I have a base class that I have some common functionality in - this > > shouldn't have a subclass generated, and should not be in the dd > > 2) I have a bmp entity that I done want a subclass generated for - > > this shouldn't have a subclass generated, but should be in the dd. > > > > so you're proposing something like: > > > > @ejb:bean generate="false" deploy="true" > > > > what should deploy default to if generate is false and deploy is absent? > > Depends whether you think it's more common for people to be using an > abstract base EJB than to be using existing concrete EJBs and just wanting > XDoclet to generate the DD. On the whole, I'd probably go with defaulting > to true, but I'm biased - I don't have any abstract base EJBs, but others > here are developing EJBs with other tools so there's a mixture of > XDoclet-generated and concrete hand-coded beans. I'm with you... the idea of using XDoclet is that you dont need the abstract base classes. There is always the possibility that someone is using the base classes, so I think we should provide for it. cheers dim _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
