> > 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
Yeah, everything! We're trying to do what Sun should have done :-) > > > 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. It's not a ejb:ejb-ref any more, it's a ejb:ejb-external-ref and xdoclet does not generate any lookup class or method for it at all. With external ejbs we don't have any xdoclet level checking and not enough info to generate anything useful. Ara. _______________________________________________________________ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
