> Yes, step by step. v1.2 has a set of @ejb:persistence tags for example > which tries to define a common tags for database persistence tags > (column-name, table-name stuff like those). We haven't yet > applied it on > all of the modules but we're moving in that direction.
ejb-refs too? Ie the AppServer specific binding between the ejb-refs in a bean and thier jnid lookups > > 2. The EJBUtil classes which can be generated hold statics for the > > COMP_NAME > > and JNDI_NAME. JNDI_NAME might make sense but COMP_NAME is really > specific > > to clients of that bean. Shouldn't client beans (which must have > ejb-refs > > to > > these target beans) instead have entries in *their* BeanUtil classes > that > > provide the COMP_NAMEs for their ejb-refs? > > Imho it's better to keep everything in a single lookup class. > We'll add > support for multiple comp_names later, when we implement Tyler Jewel's > multi-jndi-deployment pattern, and there will be > getHomeOfThisJndi() and > getHomeOfThatJndi() methods. Thats OK if you own/control the target beans, but conceptually its not correct. And if you are writing clients to some pre-packaged beans then you lose out and have no compile time checking between a COMP_NAME lookup and the ejb-refs that you have defined. William _______________________________________________________________ Multimillion Dollar Computer Inventory Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
