On 9/21/07, Steve Loughran <[EMAIL PROTECTED]> wrote: > Peter Reilly wrote: > > On 9/21/07, Steve Loughran <[EMAIL PROTECTED]> wrote: > >> Peter Reilly wrote: > >>> 1) Some of the traces seem to imply a bug. > >> > >> clearly :) > >> > >>> org.apache.tools.ant.taskdefs.Property$PropertyResolver.evaluate(Property.java:110) > >>> at > >>> org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:787) > >>> - locked <0x00002aaab4013548> (a > >>> org.apache.tools.ant.PropertyHelper) > >>> at > >>> org.apache.tools.ant.PropertyHelper.parseNextProperty(PropertyHelper.java:541) > >>> at > >>> org.apache.tools.ant.PropertyHelper.parseProperties(PropertyHelper.java:502) > >>> at > >>> org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(RuntimeConfigurable.java:390) > >>> The intent of Property.PropertyResolver is I think to remain in > >>> the Property task - the trace seems to imply that it has > >>> escaped from that task. > >> I think it is looping. There is a per-thread stack to detect this, but > >> it isnt working. Otherwise the loop wouldnt happen. > >> > >> This could be some wierd race condition in the JVM itself, which may be > >> reordering operations in the single thread. Remember, unless your > >> variable is tagged as volatile, or the block is synchronized, Java can > >> swap the order of actions. It can even reorder volatile access in Java <1.5 > > I know, but 1) I do not know why a ThreadLocal (shudder) is needed > > here, this means that the code is more complicated than it needs to be. > > and > > I presume its a way of preventing recursion down the resolution path. > When I did something like this in some grid-standard XML variant of the > smartfrog language I just passed the stack down as an explicit parameter. > > I dont like threadlocals as they are a way to consume more memory than > usual. > > > 2) even with the above, the clone operation should have protected > > the rest of the system as the tasks deletete is only added to > > the cloned property helper which is local to the method. > > > > makes sense > > > In any case, I think that the code is too slow for a very common code > > path in ant. > > > > well, let's get it working, then worry about performance. Actually, both > may be the same solution. If we can move to a stack param then the > concurrency logic changes.
I have made a modification to the way properties are expanded, so hopefully this should be resolved. Peter > > > -steve > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
