Aaron Mulder wrote:
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).
That just seems so wrong :-(
On the other hand, the DDBeans themselves are immutable so the only events DConfigBeans receive would pertain to changes in the tree. Provided whatever is mutating the XML notifies all replicas we should be OK.
I have not done anything with the event stuff yet as I could not figure out a need. None of our DConfigBeans register for events and the tool does not modify the structure.
I didn't copy over your impl during the move as it didn't seem to register the listener on the DD node put on the parent and that seemed like a bug.
-- Jeremy
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 ;-)
-- Jeremy
/************************* * Jeremy Boynes * Partner * Core Developers Network *************************/
