DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777 [PATCH] [REGRESSION] Cannot pass composite path reference between scripts ------- Additional Comments From [EMAIL PROTECTED] 2003-12-29 19:07 ------- [To Jose] Not sure whether the method should be clone() or cloneAndResolve(). Probably only needed when some refs are passed explicitly (not quite obvious to me). And yes, removing toString() in Peter's patch was definitely desirable; it is just that it exposed some underlying bugs. [To Peter] The only side-effect of toString() here is that it sets the checked flag for circular refs. If you call dieOnCircularRefs with the first project, it succeeds; with the second project, it fails. So if you call toString() on the path before passing it, dOCR succeeds and sets checked; otherwise, it is called later when the Path is used, with the wrong project (project #2), and fails. Path.list() gives the correct result so long as dOCR does not prevent it from returning! (BTW all unit tests passed for me with the original patch, not sure why it would be different for you.) [Generally] The essence of the problem is this: Reference is meaningless without a Project context; Path (e.g.) potentially keeps a bunch of Reference's around, and also one Project. The Reference should be resolved w.r.t. the Project in which it was defined, which is normally held by the Path which is also holding the Reference. Path.dieOnCircularReference() is buggy because it passes a single Project through the whole recursive call tree, which is nonsense. Each nested Path may have its own Project. Attaching a patch which corrects this (for Path only - should not be hard to generalize for other data types). It seems to fix the observed problem. Note that DataType.dieOnCircularReference should just not take a Project parameter at all - it is useless, since a correct subclass would not use it except to recurse. Yet another solution is to just keep a Project pointer in Reference to begin with. I will attach a different patch that follows this approach. Again, the patch only corrects Path. However it should be much easier to generalize to other data types than the original patch: just do a global search-and-replace of getReferencedObject(...something...) with getReferencedObject(), plus some sanity checking of course, and fix the handful of explicit uses of new Reference(...) to take a Project parameter. The patch introduces two API changes of note: 1. Reference now has a bean field 'project' of type Project, and a constructor taking Project, and a method getReferencedObject() with no args. Making a Reference without an associated Project, or derefering the ref with a different project, becomes deprecated. 2. IntrospectionHelper can assign attribute values based not only on types with a constructor taking String, but also for those taking the pair (Project,String). Path was already doing this with a special case which is generalized by the patch. I think I like this patch best since it addresses the core problem directly and more understandably, without any apparent overhead. Seems to fix the reported bug. Does not break existing unit tests (for me). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
