Any given DConfigBean should only be asked for child DConfigBeans corresponding to the XPaths returned by getXPaths(). However, if a DConfigBean wants to access an arbitrary DDBean (for example, to put a listener on it), it can use either an absolute or relative XPath to locate that DDBean. Then it gets nasty. The DDBean.getXPath should return "the original xpath string provided by the DConfigBean". Does this means provided back when the DConfigBeans were instantiated? Or does it mean provided when you searched for the DDBean tree? If the latter, perhaps you need multiple different DDBeans representing the same DD element (one relative when the DConfigBeans were initialized, one absolute when one of the DConfigBeans saerched for a DDBean by absolute XPath).
Aaron On Sat, 24 Jan 2004, Jeremy Boynes wrote: > Dain > > After all that I think the original code was right. > > The key thing is the comment in the JavaDoc for DConfigBean: > > A DConfigBean is created by calling DConfigBean.getDConfigBean(DDBean) > method, where DConfigBean is the *object that provided the XPath* which > the DDBean represents. > > In other words, you are not allowed supply merged XPaths like > 'web-app/ejb-ref/ejb-ref-name' but must first locate the DConfigBean for > 'web-app' and then use the XPaths it says it supports e.g. > 'ejb-ref/ejb-ref-name' > > I have updated the testcase to reflect this and it passes. Which I guess > means we know the code does this, but we have to hope we are > interpreting the spec correctly ;-) > >
