[digester] call-method-rule

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[digester] call-method-rule

Markos Charatzas
Hi again! :D

Knowing that "call-method-rule" and "call-param-rule" dont have a strong
association between them, Im facing a problem where although a
"call-method-rule" is specified, doesn't actually get called.

Using xml rules I have the following...
-------------------------------------------------------
<pattern value="routes/route/ship">    
        <object-create-rule classname="gr.forthnet.enosis.oli.pojos.OLIShip" />
        <bean-property-setter-rule pattern="code" />
        <call-method-rule pattern="name" methodname="setEnglishName"
paramcount="1" />
        <call-param-rule paramnumber="0" pattern="name/english" />
        <call-method-rule pattern="name" methodname="setGreekName" paramcount="1" />
        <call-param-rule paramnumber="0" pattern="name/greek" />
        <set-next-rule methodname="setShip" />
</pattern>
-------------------------------------------------------

I noticed that removing either of them, the remaining one works flawlessly...

Am I missing smth?

Thanks,
Markos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Simon Kitching
On Wed, 2005-05-25 at 16:53 +0300, Markos Charatzas wrote:

> Hi again! :D
>
> Knowing that "call-method-rule" and "call-param-rule" dont have a strong
> association between them, Im facing a problem where although a
> "call-method-rule" is specified, doesn't actually get called.
>
> Using xml rules I have the following...
> -------------------------------------------------------
> <pattern value="routes/route/ship">    
> <object-create-rule classname="gr.forthnet.enosis.oli.pojos.OLIShip" />
> <bean-property-setter-rule pattern="code" />
> <call-method-rule pattern="name" methodname="setEnglishName"
> paramcount="1" />
> <call-param-rule paramnumber="0" pattern="name/english" />
> <call-method-rule pattern="name" methodname="setGreekName" paramcount="1" />
> <call-param-rule paramnumber="0" pattern="name/greek" />
> <set-next-rule methodname="setShip" />
> </pattern>
> -------------------------------------------------------
>
> I noticed that removing either of them, the remaining one works flawlessly...
>
> Am I missing smth?

I think you've struck the design flaw in CallMethodRule.

CallMethodRule uses a single stack to store its parameters on. So when
you have two "interlaced" callmethodrules like this then the parameters
can get mixed up between the calls.

And there's an additional (documented) feature with CallMethodRule which
is that a call to a method with exactly one parameter doesn't fire if
the parameter is not available. This is meant to handle the case where a
class has a default value (for "englishName" for example) and you don't
want to override that by calling setEnglishName(null) when there is no
xml tag for the parameter.

So in your case, I bet that when both name/english are undefined, no
call gets made. But when both are defined, I suspect that the parameter
associated with one method gets set twice - first to the english name,
then overwritten with the greek name. And then that method gets called
because the parameter is non-null. But the other method sees its
parameter has never been set, and so skips the call.

Regarding a solution for your case: I think it is probably easiest for
you to just write custom rules for setting the english and greek names.

// note: rough code only

class SetGreekNameRule {
  public void body(elementNamespace, elementName, bodyText) {
    OLIShip ship = (OLIShip) digester.peek();
    ship.setGreekName(bodyText);
  }
}

digester.addRule(
  "routes/route/ship/name/greek",
  new SetGreekNameRule());

// and same for the english name

Of course you're using that blasted xmlrules stuff so you'll need to
figure out how to access your custom rule classes. There is something
called "programmatically defined rules" that I think does the job.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Rahul Akolkar
Simon -

Now you got me intrigued [
http://marc.theaimsgroup.com/?l=jakarta-commons-user&w=2&r=1&s=blasted+xmlrules&q=b
], I don't know what you mean. Can you please clarify below?

The xmlrules stuff is blasted because ____.

-Rahul

P.S.-No one's getting any younger ;-)

On 5/25/05, Simon Kitching <[hidden email]> wrote:
<snip>
> Of course you're using that blasted xmlrules stuff so you'll need to
> figure out how to access your custom rule classes.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Simon Kitching
On Thu, 2005-05-26 at 02:18 -0400, Rahul Akolkar wrote:
> Simon -
>
> Now you got me intrigued [
> http://marc.theaimsgroup.com/?l=jakarta-commons-user&w=2&r=1&s=blasted+xmlrules&q=b
> ], I don't know what you mean. Can you please clarify below?
>
> The xmlrules stuff is blasted because ____.

See comment#20 on this bugzilla entry.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33001

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Markos Charatzas
In reply to this post by Simon Kitching
Arg... :(

First of all thank you Simon for your continuous support.

The only reason Im using "call-method-rule"s in this case (and not a
"bean-property-setter-rule" is that I want the "set-next-rule" to fire prior
to to the "call-method-rule". Other than making a custom "set-next-rule", is
there any other way to achieve this?

Although in another part of the config, I do have 2 "interlaced"
"call-method-rule"s that are unavoidable...

Regards,
Markos

On Thursday 26 May 2005 02:40, Simon Kitching wrote:

> On Wed, 2005-05-25 at 16:53 +0300, Markos Charatzas wrote:
> > Hi again! :D
> >
> > Knowing that "call-method-rule" and "call-param-rule" dont have a strong
> > association between them, Im facing a problem where although a
> > "call-method-rule" is specified, doesn't actually get called.
> >
> > Using xml rules I have the following...
> > -------------------------------------------------------
> > <pattern value="routes/route/ship">
> > <object-create-rule classname="gr.forthnet.enosis.oli.pojos.OLIShip" />
> > <bean-property-setter-rule pattern="code" />
> > <call-method-rule pattern="name" methodname="setEnglishName"
> > paramcount="1" />
> > <call-param-rule paramnumber="0" pattern="name/english" />
> > <call-method-rule pattern="name" methodname="setGreekName"
> > paramcount="1" /> <call-param-rule paramnumber="0" pattern="name/greek"
> > />
> > <set-next-rule methodname="setShip" />
> > </pattern>
> > -------------------------------------------------------
> >
> > I noticed that removing either of them, the remaining one works
> > flawlessly...
> >
> > Am I missing smth?
>
> I think you've struck the design flaw in CallMethodRule.
>
> CallMethodRule uses a single stack to store its parameters on. So when
> you have two "interlaced" callmethodrules like this then the parameters
> can get mixed up between the calls.
>
> And there's an additional (documented) feature with CallMethodRule which
> is that a call to a method with exactly one parameter doesn't fire if
> the parameter is not available. This is meant to handle the case where a
> class has a default value (for "englishName" for example) and you don't
> want to override that by calling setEnglishName(null) when there is no
> xml tag for the parameter.
>
> So in your case, I bet that when both name/english are undefined, no
> call gets made. But when both are defined, I suspect that the parameter
> associated with one method gets set twice - first to the english name,
> then overwritten with the greek name. And then that method gets called
> because the parameter is non-null. But the other method sees its
> parameter has never been set, and so skips the call.
>
> Regarding a solution for your case: I think it is probably easiest for
> you to just write custom rules for setting the english and greek names.
>
> // note: rough code only
>
> class SetGreekNameRule {
>   public void body(elementNamespace, elementName, bodyText) {
>     OLIShip ship = (OLIShip) digester.peek();
>     ship.setGreekName(bodyText);
>   }
> }
>
> digester.addRule(
>   "routes/route/ship/name/greek",
>   new SetGreekNameRule());
>
> // and same for the english name
>
> Of course you're using that blasted xmlrules stuff so you'll need to
> figure out how to access your custom rule classes. There is something
> called "programmatically defined rules" that I think does the job.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Markos Charatzas
The "set-next-rule" is actually in the following mapping

------------------------------------------------------
<pattern value="routes/route/ship/company">
        <object-create-rule classname="gr.forthnet.enosis.oli.pojos.OLICompany" />
        <bean-property-setter-rule pattern="code" />
        <set-next-rule methodname="setCompany" />
</pattern>
------------------------------------------------------

In any way, what Im trying to achieve is establish a parent/child relationship
between the ship and the company only that company is set to the ship prior
calling any of the setters on the greek/english names.

By the way, is release 1.7 going to address the issues with the
"call-method-rule" and "call-param-rule" ?

Thanks again,
Markos

On Thursday 26 May 2005 10:08, Markos Charatzas wrote:

> Arg... :(
>
> First of all thank you Simon for your continuous support.
>
> The only reason Im using "call-method-rule"s in this case (and not a
> "bean-property-setter-rule" is that I want the "set-next-rule" to fire
> prior to to the "call-method-rule". Other than making a custom
> "set-next-rule", is there any other way to achieve this?
>
> Although in another part of the config, I do have 2 "interlaced"
> "call-method-rule"s that are unavoidable...
>
> Regards,
> Markos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Simon Kitching
Hi Markos,

On Thu, 2005-05-26 at 16:18 +0300, Markos Charatzas wrote:
> By the way, is release 1.7 going to address the issues with the
> "call-method-rule" and "call-param-rule" ?

No.

> On Thursday 26 May 2005 10:08, Markos Charatzas wrote:
> > The only reason Im using "call-method-rule"s in this case (and not a
> > "bean-property-setter-rule" is that I want the "set-next-rule" to fire
> > prior to to the "call-method-rule". Other than making a custom
> > "set-next-rule", is there any other way to achieve this?

I think a custom SetNextRule is the best solution.

I've added an enhancement request in bugzilla for this:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=35095

Regards,

Simon
--
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [digester] call-method-rule

Rahul Akolkar
In reply to this post by Markos Charatzas
Two in one -

1)
On 5/26/05, Simon Kitching <[hidden email]> wrote:
> On Thu, 2005-05-26 at 02:18 -0400, Rahul Akolkar wrote:
<snip/>
> > The xmlrules stuff is blasted because ____.
>
> See comment#20 on this bugzilla entry.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33001
>

Sure, agreed, and thanks for maintaining the API and xmlrules in
parallel. There's just something about not having to (re)compile and
(re)deploy ...

2)
> On Thu, 2005-05-26 at 16:18 +0300, Markos Charatzas wrote:
> > By the way, is release 1.7 going to address the issues with the
> > "call-method-rule" and "call-param-rule" ?
>
> No.

If you so wish, depending on how bad you want them resolved, you can
try/improve the proposed patch.

-Rahul

P.S.-Sorry about the previous email Simon, didn't go as per plan ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]