This discussion is interesting. One thing xdoclet inherited from old ejbdoclet was generating stuff by default, we then added switches to turn off those you don't want. But let's face it guys: it better to turn many things off by default! And to apply some defaults by default!
For example the usefulness of data-objects declined in ejb2 because of local interfaces (though I'm a firm believer in dataobject even in ejb 2!). So having to put generate="false" in source code is a pain. I guess we should change some things: - A deployable="true|false" (or deploy as you call it, I prefer deployable) for specifying whether the bean is a real bean you want to use or an abstract one. Assuming that we'll also implement the logic for turning off some subtasks if desired (say you don't want <session/> or <entitycmp/>), this parameter is only applicable if you have entitycmp/bmp defined. So we should write an isDeplyable tag impl in EjbTagsHandler. Another interesting thins we can do is to search for abstract methods, if there's one then the bean is an abstract bean, of course we omit persistent getter/setter methods and get/setData. Another useful default is to guess session bean type: if implementing SessionSynchronization then it's stateful, if has a single ejbCreate() method then stateless and things like that, of course if user does not override it by putting a @tag. - The same is true for generate="true|false" in regard to entitycmp/etc. - All subtasks should be optional. If you don't declare <entitycmp/> you don't get the subclassed class. If you declare <deploymentdesciptor/> and nothing more it means you don't need more, probably because you have legacy code, so you don't want it in general. - Something we still don't provide: useful defaults. For example you should be able to pass a bean source that has no @ejb: tags and get everything generated. Some defaults should apply, for example there's no ejb:bean name param, so classname should be used, same for jndi name and so on. This gives a much better jumpstart to a newbie and we can even write a tutorial that way: first show a normal class, run xdoclet, see what happened, then try to control the output by adding @tags. I also think each *doclet task should have a tutorial like the one I talked about here, "here is entitybmp it generates this and that, we run it now, here is the result". Dmitri, if you could make the optional subtasks happen we could get rid of many of those requests saying they only want deployment descriptor or they don't like the auto-generated cmp class and so on :o) Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Dmitri Colebatch > Sent: Tuesday, October 30, 2001 4:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [Xdoclet-devel] CVS update: 'xdoclet/core/src/xdoclet/ejb > > 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 _________________________________________________________ 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
