> >> Why? > > > > Because it's good practise. It separates the business contract > > from the > > technical contract, so you don't have ejbActivate, ejbPassivate etc. > > cluttering up your code > > Huh. I thought that this was the reason -- until I tried it and > it didn't work! I must be missing something...... If I leave > those methods out, it complains that my class isn't implementing > the SessionBean interface. If I don't implement that interface, > ejbdoclet passes over my session bean entirely.
So you give xdoclet an ordinary class and expect a session bean subclass? No. That way for any imaginable class a session subclass will be generated! XDoclet needs to find out whether the class is indeed intended to be a session bean by: either it directly or indirectly implements SessionBean interfaces, or it implements SessionSynchronization or ... some other session bean specific checks that I don't recall atm. Ara. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
