Hans, Paul
I have not been able to recreate the problem on any of your core tags, which is
of course the way it should be. But I have definitively found and corrected a
line of code in my tag which seems to have been the reason for the problem here.
My app works this way:
I have pre compiled sets of scripts stored in a repository. I have tags for
creating "objects" (contexts) and invoking "methods" (scripts from repository)
on those contexts. A set of "methods" I call a "clazz", can inherit "methods"
from each other.
When invoking a "method" on an "object" my tags call an engine which uses the
repository of compiled scripts for execution.
In this way I can create complex "pipelines" of functionality.
I was able to recreate the problem with a simplified tag:
package se.keriksson.jool.jelly;
import java.util.*;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;
import org.apache.commons.jelly.JellyTagException;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class TestAttributesTag extends TagSupport {
private static Log log = LogFactory.getLog(InvokeTag.class);
private String clazz;
private String method;
private String var;
public TestAttributesTag() {
}
public void setClazz(String clazz) {
this.clazz = clazz;
}
public void setMethod(String method) {
this.method = method;
}
public void setVar(String var) {
this.var = var;
}
public void doTag(XMLOutput output) throws JellyTagException {
log.debug("... var: " + var);
log.debug("... clazz: " + clazz);
log.debug("... method: " + method);
if(var.equals("") && clazz.equals("")) {
setClazz("bar");
}
invokeBody( output );
}
}
First time the tag is run like <mylib:myTestAttributesTag method="foo" /> the
result is as expected, only the method variable has a value ("foo"). The second
time, the clazz variable is already set to "bar" which is not what I expect.
The problem seems to lie in the line:
setClazz("Bla");
Removing this line of code solves my issue, and my pipeline of scripts runs
fine.
Important to mention is that this only seems to occur on the second "level" of
execution, that is, one script calling another, via my own engine. But the
engine does not spawn new threads or anything.
I realize that this complexity makes it difficult to somehow recreate the
problem, but I can only assure you that running the exact same pipeline of
scripts on RC1 works perfectly fine.
I don't know if there are any reasons for you to "dig any deeper into" this
matter, but I would like to ask you Paul for the patch you have created as I
understand, with some sort of "reset-setters" method, so I can at least try it
out and se if it changes anything.
Many thanks
/Kristofer Eriksson
-----Original Message-----
From: Kristofer Eriksson [mailto:[EMAIL PROTECTED]
Sent: Montag, 27. Juni 2005 10:26
To: Jakarta Commons Developers List
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch
Hi,
A similar use of different attributes depending on usage is the set tag, where
you can use either a "var" attr or a "target" attr. My custom tag works in a
similar ways with different functionality depending on attrs given. Like:
package se.keriksson.jool.jelly;
import java.util.*;
import org.apache.commons.jelly.XMLOutput;
import org.apache.commons.jelly.JellyTagException;
import se.keriksson.jool.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class InvokeTag extends TagSupport implements InvokeInterface {
private static Log log = LogFactory.getLog(InvokeTag.class);
private String clazz;
private String method;
private String var;
private String out;
private List in;
private JoolJellyContext runtimeContext;
public InvokeTag() {
this.clazz = "";
this.var = "";
in = new ArrayList();
}
public void setClazz(String clazz) {
this.clazz = clazz;
}
public void setMethod(String method) {
this.method = method;
}
public void setVar(String var) {
this.var = var;
}
public void setOut(String out) {
this.out = out;
}
public void setInParameter(String name, Object value) {
this.runtimeContext.setVariable(name, value);
}
public void addInValue(Object value) {
this.in.add(value);
}
public void setRuntimeContext(JoolJellyContext runtimeContext) {
this.runtimeContext = runtimeContext;
}
public JoolJellyContext getRuntimeContext() {
return this.runtimeContext;
}
public void doTag(XMLOutput output) throws JellyTagException {
if(!var.equals("")) {
runtimeContext = (JoolJellyContext)context.getVariable(var);
clazz = this.runtimeContext.getClazzName();
log.debug("... invoking existing: " + var);
} else if(!clazz.equals("") && !clazz.equals("super")) {
runtimeContext = new JoolJellyContext(context, null);
log.debug("... invoking static: " + clazz);
} else if(clazz.equals("super")) {
try {
runtimeContext = (JoolJellyContext)context;
log.debug("... invoking super");
} catch (Exception e) {
log.debug("... error casting context, exec continues", e);
}
} else if(var.equals("") && clazz.equals("")) {
try {
runtimeContext = (JoolJellyContext)context;
setClazz(runtimeContext.getClazzName());
log.debug("... invoking this: " +
runtimeContext.getClazzName());
} catch (Exception e) {
log.debug("... error casting context, exec continues", e);
}
}
if(runtimeContext==null) {
runtimeContext = new JoolJellyContext(context, null);
log.debug("... runtime context null, new created");
}
invokeBody( output );
runtimeContext.setIn(this.in);
Jool.exec(clazz, method, runtimeContext);
if(out != null) {
context.setVariable(out, this.runtimeContext.getOut());
}
}
}
I haven't tried the set tag for this "problem", but according to me there must
be a potential for the same behavior.
I will try this as soon as I get the time.
Regards
/Kristofer
-----Original Message-----
From: Hans Gilde [mailto:[EMAIL PROTECTED]
Sent: Montag, 27. Juni 2005 04:39
To: 'Jakarta Commons Developers List'
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch
Hmm, I'm having a hard time replicating this. Could you send some examples?
Basically, if the tag has two attributes on the first run, how would it have
one attribute on the second run?
-----Original Message-----
From: Kristofer Eriksson [mailto:[EMAIL PROTECTED]
Sent: Friday, June 24, 2005 10:30 AM
To: Jakarta Commons Developers List
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch
Just TagSupport
-----Original Message-----
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Freitag, 24. Juni 2005 16:26
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Which tag-class are you subclassing ?
paul
Le 24 juin 05, à 15:33, Kristofer Eriksson a écrit :
> Hi Paul,
>
> many thx for the quick answer.
>
> In my case, yes I do expect the setters to be called at every new run.
> Setters receiving an expression would solve my problem, or always
> specifying all attributes, even "empty" ones (<mylib:mytag attr1="foo"
> attr2="" />) but then all scripts (and I have loads) needs to be
> modified.
>
> I believe there would be useful though, not only for me but in
> general, to have some way to disable caching per tag or (preferably)
> some sort of "re-run-setters" method that is called on every run as
> you suggested. Either solution would solve my problem.
>
> Regards
>
> /Kristofer Eriksson
>
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 24. Juni 2005 14:14
> To: Jakarta Commons Developers List
> Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
>
> Since a bit earlier than the patch, indeed, caching has been activated
> by default and caching disablement has been removed. This was needed at
> least by some jelly:define tags, as far as I could tell.
>
> Can you give more details ?
> - Do you expect the setters to be called at every new run ?
> - Would you have enough if having a method accessible such as
> "re-run-setters"?
> - Alternatively, would you be happy with overall cache-disablement (at
> your own risks) ?
> - Finally, did you not find a possibility to have setters receive
> expressions which, then, get re-evaluated each time needed ? I would
> believe this would be the best practice.
>
> thanks
>
> paul
>
>
> Le 24 juin 05, à 13:38, Kristofer Eriksson a écrit :
>> Secondly, to add to the above topic, I see the change in cache
>> behavior
>> (since the patch?!?). When calling a Tag a second time attributes not
>> specified will have values previously set, as mentioned by Brett.
>>
>> First call: <mylib:mytag attr1="foo" attr2="boo" />
>> Second call: <mylib:mytag attr1="foo" />
>>
>> The second time mytag is called, attr2 will still have the value
>> "boo",
>> and not null or default value. My question is if this is the desired
>> behavior, if not, can this be fixed somehow.
>>
>> Kind Regards
>>
>> /Kristofer Eriksson
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
