Re: is broken with Jython in the recent trunk builds

[Alexey Solofnenko]

I think we need to restore old functionality, because it was done after 1.7 was released. Or it can be made smarter by checking if setValue() was called and use that value instead of return value. Again we need to decide if we want 100% backward compatibility or slightly less.

- Alexey.

Matt Benson wrote:

--- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:

Sorry about that. Personally I would prefer
"expression" attribute to
contain an expression itself - it is supposed to be
simple.

That still doesn't address the situation I mentioned,
whereby some arbitrary scripty stuff is done to
calculate a final result, then return it.  It seems
that experience has shown we shouldn't discriminate
between an attribute and nested text.  Maybe a
different attribute name would better express the
concept I am after.

-Matt

- Alexey.

On 7/31/07, Matt Benson <[EMAIL PROTECTED]>
wrote:

--- Alexey Solofnenko <[EMAIL PROTECTED]> wrote:

It is just a thought - should ScriptFilter,
ScriptMapper, ... also return a
value instead of setting it?

mmmm.... I don't know!  :)  In hindsight maybe it
would have been better to leave this can of worms
unmolested rather than deal with these concepts of
consistency...  I suppose that in either of those
cases it might well be reasonable to handle a

return

value.  But with good old Python, what--you can't
execute arbitrary junk, return a value, and

consider

that an evaluation?  Jython seems to be a pain
overall... seems like every time I have to deal

with

it there's a headache involved.  If we do extend

this

concept, I suppose we could pull up "expression"

to

AbstractScriptComponent, and have evaluate()

delegate

to execute() and return null when expression ==
false... then any type that wanted to support a

return

value could just switch to calling evaluate and

prefer

a return value to whatever its "legacy" mechanisms
were.  How does this sound?

-Matt

- Alexey.

On 7/31/07, Matt Benson <[EMAIL PROTECTED]>
wrote:

--- Alexey Solofnenko <[EMAIL PROTECTED]>

wrote:

Old code was executing self.setValue() and

the

current behaviour breaks
backward compatibility. I have tried old
ScriptCondition.eval() and it fixed
the problem. I think we should add

"expression"

attribute to
AbstractScriptComponent and change it to use

it

with

evaluateScript(),
otherwise nested text will be executed with

old

executeScript() call.

Thanks for running this down, Alexey.  I see

where

you're coming from with the "expression"

attribute,

though I'm not sure I agree it should live all

the

way

up in AbstractScriptComponent, because we

can't

use it

to automatically drive anything.  I am going

to

add it

to ScriptCondition directly; if we change our

minds

later pulling it up shouldn't cause any

problems.

-Matt

- Alexey.

On 7/31/07, Peter Reilly
<[EMAIL PROTECTED]> wrote:

For BSF there are two methods to run a

script:

  eval and exec,

In ant 1.6.* the only method supported was

exec.

Hence all

the <script*> types called methods on self

to

set

the return

value.

For ant 1.7.0, I modified the scripting

code

to

allow access to

eval and exec, but did not modify any

calling

types to use

eval rather than exec. (In fact I did not

test

the

eval on anything)

I placed it here to allow expression

handling

from

property callbacks

- something like <if test='${groovy: abc

==

"abc"}"> ..., but did

not follow up.

I assume that jython does not like a new

line

in

its expression.

one can in python do
a = 1
if a > 0:
   b = 2
however, one cannot do
if #
  a > 0:


...
So I think that this is a clear case of BC

problem.

It would be nearly impossible to use

<scriptcondition> with

jythton in it's current state.


(I cannot test at the moment due to

(bsf/log4j/commons

logging/jython.jar issues)

Peter



On 7/31/07, Dominique Devienne

<[EMAIL PROTECTED]> wrote:

On 7/31/07, Matt Benson

<[EMAIL PROTECTED]>

wrote:

<scriptcondition> originally behaved

such

that

a

default value can be declared on the

task

as

an

attribute, and the embedded script can

set

the

condition value.  I preserved this

behavior,

but added

a preference for a return value, if

any,

from

the

script:  again, on the basis that this

seemed

a (more)

natural behavior to me.  DD, you said

"not

returning a

value is fine by you"... and that's

what

<scriptcondition> always did, and

_should_

still

allow... am _I_ missing anything

(other

than

whatever

I've apparently done to break python

compatibility)?

Ah, sorry, I meant that "not returning a

value

is meaningless to me".

Sure, if a default value for the

condition

is

set as an attribute, why

not (although I don't see why that's

necessary

or useful), but a

scriptcondition is supposed to be a

script

fragment which returns a

boolean value, and I don't see the point

of

not

returning a value.

--DD

PS: The error message could be nicer

though

;-)

---------------------------------------------------------------------

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]

--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)

____________________________________________________________________________________

Choose the right car based on your needs.

Check

out Yahoo! Autos new Car

Finder tool.
http://autos.yahoo.com/carfinder/

---------------------------------------------------------------------

To unsubscribe, e-mail:

[EMAIL PROTECTED]

For additional commands, e-mail:

[EMAIL PROTECTED]

--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)

____________________________________________________________________________________

Pinpoint customers who are looking for what you

sell.

http://searchmarketing.yahoo.com/

---------------------------------------------------------------------

To unsubscribe, e-mail:

[EMAIL PROTECTED]

For additional commands, e-mail:

[EMAIL PROTECTED]

--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)

Choose the right car based on your needs.  Check out Yahoo! Autos new Car 
Finder tool.
http://autos.yahoo.com/carfinder/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

____________________________________________________________________________________

--
------------------------------------------------------------------------
Alexey N. Solofnenko <http://trelony.cjb.net/>
Pleasant Hill, CA (GMT-8 usually)

smime.p7s
Description: S/MIME Cryptographic Signature