commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristofer Eriksson" <kristofer.eriks...@zoirosit.de>
Subject RE: [jelly] SOLVED: Maven issue with Hans memory leak patch
Date Mon, 27 Jun 2005 08:26:01 GMT
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:hgilde@optonline.net] 
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:kristofer.eriksson@zoirosit.de] 
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:paul@activemath.org] 
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:paul@activemath.org]
> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message