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=18406>. 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=18406 nightly build script throws npe under some (common) conditions ------- Additional Comments From [EMAIL PROTECTED] 2003-03-27 14:58 ------- As I said in the intro, I am only looking at the symptom. The code in unknownelement is reflection rich and I did not have time to place selective printf's. I suspect that what is happening is that id's are not resolved when they are in targets that have not been run yet. id is a special attribute that is picked up by the xml parsing code in ProjectHelperImpl#initTag() the Element gets placed in the reference map here. In the normal course of events UnknownElement#maybeConfigure gets called, which in the case of path's causes the path object to be created and placed in the same map under the same name. What I think is happening here is that the project$antreftable.get() is called before maybeconfigure is called on the object. What I think is happening here is that the get() method sees an unknownelement, calls maybeconfigure, assumes that this is a task (why?) and calls getTask() to get the object. This is null for a path. My orignal patch then assumed that if getTask() was null, the table would contain the real object or null :- but this is of course mistaken as the object in the table could still be unknownelement (depending on the implementation of unknownelement), the method would then return unknownelement rather than a correct null. The second patch took care of that (remote) possiblity. The third is not needed, I had assumed that if an object in null, called instanceof on it would throw a NPE, but this is of cource not the case as instanceof is not a method.
