Costin,
> > This raises a question: Are properties whose values are resolved by
custom
> > PropertyHelpers always converted to Strings? I see that the return type
> > of PropertyHelper#getPropertyHook(String, String, boolean) has Object as
> > the
> > return type. But if that's always converted to a String then my custom
> > PropertyHelper will need to make sure that this is done correctly, i.e.
> > that the Object yields a meaningful String representation.
> >
> > But for tasks which have a setXXX(Object) method it would maybe make
sense
> > to preserve the property value as an Object instance, if that's what's
> > actually in the buildfile. E.g.
> >
> > <foo xxx="${my:bar}"/>
> >
> > would not convert the ${my:bar} property to a String.
>
> If you read the comments on top of PropertyHelper - that was one of the
> goals, but I don't think it is implemented yet. The return value for the
> property interceptors is already an object, but the code that does
property
> replacement doesn't know how to deal with "${prop}".
>
Thanks for pointing that out; I'd missed it.
The question is what to do with things like "${my:foo}bar". It would
probably have to call toString() on the Object returned by the property
resolution and concatenate it with "bar".
So only when specified by itself as an attribute value corresponding to a
setXXX(Object) method it will be treated as an Object. (Trying a class cast
to the setter's argument type would probably also make sense.) In all other
cases you will end up using the String representation.
--
knut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
