Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [digester] digester adds sub-objects before fully created
From: Simon Kitching <simon@ecnetwork.co.nz>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <409E2C99.4010605@blueyonder.co.uk>
References: <409E2C99.4010605@blueyonder.co.uk>
Content-Type: text/plain
Message-Id: <1084144916.5197.19.camel@pcsimon>
Mime-Version: 1.0
Date: Mon, 10 May 2004 11:21:56 +1200
Content-Transfer-Encoding: 7bit

Hi,

On Mon, 2004-05-10 at 01:05, gary and sarah wrote:
> I am using digester to read the following file
> 
> with the following as an example of a rules
> 
>         // x axis
>         digester.addObjectCreate("tensor_frame/x_axis", 
> BasicProjections.class);
> 
>         digester.addCallMethod("tensor_frame/x_axis","setAxis",1,new 
> Class[]{Axis.class});
>         digester.addObjectParam("tensor_frame/x_axis",0,Axis.X);
> 
>         digester.addBeanPropertySetter ("tensor_frame/x_axis/x", "x");
>         digester.addBeanPropertySetter ("tensor_frame/x_axis/y", "y");
>         digester.addBeanPropertySetter ("tensor_frame/x_axis/z", "z");
>         digester.addSetNext("tensor_frame/x_axis", "addProjections");
> 
>         // tensor_frame
>         digester.addObjectCreate("tensor_frame", BasicTensorFrame.class);
> 
> however, basicTensorFrame.addprojections is being called with an 
> impcompletely constructed BasicProjections object...
> 
> this apppears to be because the end clauses of rules are being called in 
> the reverse order from that in which they are declared:
> 

It's more a side-effect of the stack-oriented nature of Digester. Yes,
it's counter-intuitive.

The reason that the CallMethodRule does the actual method invocation
from the end method is that you need to be sure that all the param rules
have fired. In particular, param rules that pass the element body text
need to have completed their work.

And end methods must be invoked in the reverse order relative to begin
methods to ensure that rules which manipulate the digester object stack
and param stack clean up correctly. Begin methods commonly push onto the
stack, and end methods clean up the stack; failing to fire end in
reverse order will severely stuff up the stack(s)!

Workaround: add the SetNextRule before the CallMethodRule. Its end
method will therefore be called after the CallMethodRule's end method,
and so the object will be initialised before addProjections is invoked.
It looks a little odd, but is a 100% reliable solution.

The javadocs for the next release will have a big note pointing out this
behaviour, and the appropriate workaround. In the CVS repository there
is also an experimental alternative to CallMethodRule which doesn't
suffer from this problem, but it won't make it in the next release.

Regards,

Simon


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