On 2015-01-15, Gan Dong wrote:

> Recently, I came across a problem in Ant and the solution seems to
> write a custom LocalProperties implementation to fix the issue. But I
> found that this class has a sole privet constructor which prevents me
> from sub-classing it:

> 55     /**
> 56      * Construct a new LocalProperties object.
> 57      */
> 58     private LocalProperties() {
> 59     }

> I'd like to know, is such design on purpose? What's the consideration
> in making it private?

Basically because we never felt this is an extension point we want to
support.  The class is not meant to be subclassed.

> I know Ant provided a mechanism as following which seems to have the
> ability to register user-defined LocalProperties class:

> LocalProperties l = (LocalProperties) project.getReference(
>  MagicNames.REFID_LOCAL_PROPERTIES);

Ah, no.  There should only be a single LocalProperties stack for a
project and the code above is getting access to that.  Like a global
variable but hidden behind some smoke and mirrors.

> Some additional context on why I want to extend the class. Due to this
> ant bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=55074, our
> framework, which calls ant, occasionally throws
> ConcurrentModificationException when parallel is used.

I've been meaning to look into this, but failed to find the time to do
so so far.  LocalPropertyStack is supposed to be used only by a single
thread at a time, I'm surprised to see the
ConcurrentModificationException.  Rather than synchronizing the stack
I'd like to figure out where it leaks outside of its Thread and fix
that.

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org

Reply via email to