commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [jelly] 'bug' setting tag properties from properties file
Date Tue, 17 Dec 2002 14:16:30 GMT
From: <>
> Background:
> I'm using the latka plugin.
> It has a set of Jelly tags which have Strings for their setter methods,
> i.e. the Request tag has a setHost(String) method.
> Problem:
> 1) I populate these tags with an expression, which references properties
> maven reads from, e.g.
> <suite defaultHost="${}">
> where is defined in the ${basedir}/
> 2) When the tag is executed, I get a
> 2002-12-17 13:29:52,798 DEBUG org.apache.commons.jelly.impl.TagScript -
> Caught exception: java.lang.IllegalArgumentException: Property
> 'defaultHost' has no write method
> java.lang.IllegalArgumentException: Property 'defaultHost' has no write
> method
> 3) This is caused because the expression is being passed to BeanUtils with
> no conversion done, e.g. :
> 2002-12-17 13:29:52,758 DEBUG org.apache.commons.jelly.JellyContext -
> findVariable: value:
> 2002-12-17 13:29:52,758 DEBUG org.apache.commons.beanutils.BeanUtils -
> setProperty(org.apache.commons.latka.jelly.SuiteTag@78aa80, defaultHost,
> 4) This tag has no methods that take an Expression as a paramter, and
> since no conversion is being done by Jelly/BeanUtils the code fails with
> the above IllegalArgumentException.
> 5) When these properties are passed in from the command prompt via
> for example, all works fine, as they are explicitly
> known as Strings.

TagScript already tries to evaluate any Expression objects before they are
set on properties on Tags. Maybe in this case we have multiply-nested
expressions inside Maven's JellyContext implementation? i.e. that an
expression evaluates to another expression, which when it evaluates the
final value is a String.

Maybe when the variable scopes are introduced into Jelly this might fix any
errors like this that are introduced by Maven's JellyContext implementation.

A workaround could be to patch TagScript to use the
expression.evaluateRecurse() rather than the expression.evaluate() methods?
I don't have time right now to investigate this but if you fancy having a
try, I've attached the patch to TagScript to do exactly this.


View raw message