> > Well, actually I've added some guessing code to ifIsAConcreteEJBean.
> > I'll commit it today. What it does is doing these in order:
> > - if generate is specified then use it
> > - now try to guess because it wasn't specifically specified whether
it
> > should be generated or not
> > - if( getCurrentClass().isAbstract() == true )//
> > <entitycmp/bmp/session/> is on
> > - //check if it has any abstract methods: if a method
> > other than create/remove/getData/like-that is abstract so it's not a
> > concrete bean
> > - check if it's abstract and has a non-xdoclet-generated
> > derived class
> > - else
> > //if( <entitycmp/bmp/session/> is off )
> > //{
> > generate( template );
> > //}
> > //else
> > //{
> > //should be a support class wrongly not abstract!
> > //}
> >
> > I'm running it on PersonBean and there's no need for ejb:bean or
> > generate="false". Isn't it great?
> >
> > So I think deployable is not useful :o)
>
> I feel like an idiot now... a bit confused - but I'm also keen to get
this
> done here and now, so hopefully we can nail it... In your previous
email
> you said you're waiting for my code here, but from what you've
written, it
> looks as though you're fine.
I haven't written the //if( <entitycmp/bmp/session/> is off ) part but
the rest is ok.
> ok - so the above code covers the whether or not the bean is included
in
> the ejb-jar.xml et. al. deployment descriptors. So I should then use
that
> same code or logic in the CMP, BMP and session subtasks yes? atm my
bean
> subtasks look skip if generate=false||dd, but what we're saying is we
> should just check the above and throw dd away?
Generally it's a good idea to let you have dataobject/pk/remote/home for
your base bean. But we should generate cmp/bmp/session for concrete
classes only. So yes, we should put a isAConcreteEJBean in
matchesGenerationRules of cmp/bmp/session.
> I still think that we need generate="dd" to instruct generation of the
> bean in the dd, but not bean subclass code. Having PersonBean working
is
> good, thats one side of the coin, but what I thought the "smart
> (tm) subtasks" were doing was allowing the user to say "i want
ejb-jar.xml
> and jboss.xml, but no subclass"... admittedly we can do that along
similar
> lines to above, but I still think we should allow an override...
It's different stories:
- support abstract base beans
- support optional subtasks
For the first one isAConcre... does the trick, for the second:
- if cmp/bmp/session is on and it's a concrete bean -> generate
cmp/bmp/session subclasses
- if cmp/bmp/session is off and it's a concrete bean -> don't generate
cmp/bmp/session subclasses
- if cmp/bmp/session is on and it's not a concrete bean -> don't
generate cmp/bmp/session subclasses
- if cmp/bmp/session is off and it's not a concrete bean -> Nothing to
do!
Note that isConcrete... assumes that mostly people provide an abstract
base class for their concrete beans, they are not interested in
create()-ing PersonBean not CustomerBean/EmployeeBean/etc. But if you
really want to be able to create() a PersonBean you can if you put a
generate="true" in it. It's a good assumption (or smart default!).
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
