You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Giovanni Azua <gi...@imc.nl> on 2008/10/03 16:16:02 UTC
criteria-based action forking: missusing Code behind?
hi,
I have different types of (trading strategy/algorithm) configurations.
My application allows scheduling Simulations for any of the existing
types, depending on the type it should be redirected to a specific form e.g.
--------------------------------------------
Example
--------------------------------------------
Algo 1 Config -\ / Form Schedule Sim "Algo 1 Config"
Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
Algo 3 Config -/ \ Form Schedule Sim "Algo 3 Config"
I have many "Opp" actions that generically handle any type of
configuration but from there it needs to redirect to the type-specific
form. To do the forking part I am trying to use a redirect action
mapping with an OGNL expression like this:
<action name="FormScheduleSimulation">
<result type="redirectAction">${ 'FormScheduleSimulation' +
configType.name }</result>
</action>
But here the result parameters coming from "Opp" do not get passed
through and the ONGL expression does not see the needed configType bean.
To solve this I imported the CodeBehind plugin expecting it to
automatically discover that "FormScheduleSimulation" action does not
have a corresponding Action class and therefore it would create one on
the fly and let the original action result parameters pass right through
including the needed "configType" but does not work.
Is there any additional step to take for the Code Behind plugin to work
here ... ?
TIA,
Regards,
Giovanni
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: criteria-based action forking: missusing Code behind?
Posted by Giovanni Azua <gi...@imc.nl>.
It works like this though:
<action name="FormScheduleSimulation"
class="com.sag.optimizer.ui.web.action.form.FormScheduleSimulationAction">
<result type="redirectAction">${ 'FormScheduleSimulation' +
configType.name }</result>
</action>
Having:
1-. No Code Behind plugin installed
2-. Providing FormScheduleSimulationAction that exposes the needed
properties including configType.
The problem is that in the future there might be additional properties
to pass through, then the FormScheduleSimulationAction will need to be
updated each time ... I think that the purpose of Code Behind is to
cover exactly this kind of use-cases ...
TIA,
regards,
Giovanni
Giovanni Azua wrote:
> btw I am using v2.1.2
>
> do you mean like this:
> <action name="FormScheduleSimulation">
> <result type="redirectAction">${ 'FormScheduleSimulation' +
> #parameters.configType.name }</result>
> </action>
>
> unfortunately does not work like that :(
>
> regards,
> Giovanni
>
> Musachy Barroso wrote:
>
>> yup, that's the problem, I think. If it is a parameter you can reference it
>> as #parameters.xyz.
>>
>> On Fri, Oct 3, 2008 at 10:29 AM, Giovanni Azua <gi...@imc.nl> wrote:
>>
>>
>>
>>> hi! :)
>>>
>>> The configType is a bean property exposed by the "Opp" action. In fact I
>>> get the error logging below. I believe this happens because there is no
>>> action passing these parameters through (I expected Code Behind to do it for
>>> me). Meantime I will try providing an action class to see if it works ...
>>>
>>> Many thanks!
>>> Best regards,
>>> Giovanni
>>>
>>> Oct 3, 2008 4:24:12 PM
>>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>>> caught setting 'configType' on 'class com.opensymphony.xwork2.ActionSupport:
>>> Error setting expression 'configType' with value ['T11', ]
>>> Oct 3, 2008 4:24:12 PM
>>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>>> caught setting 'exportFileName' on 'class
>>> com.opensymphony.xwork2.ActionSupport: Error setting expression
>>> 'exportFileName' with value ['null', ]
>>> Oct 3, 2008 4:24:12 PM
>>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>>> caught setting 'simulationRunId' on 'class
>>> com.opensymphony.xwork2.ActionSupport: Error setting expression
>>> 'simulationRunId' with value ['I30gBGp.1FxpeY.Hp35xbF.1k', ]
>>>
>>>
>>>
>>> Musachy Barroso wrote:
>>>
>>>
>>>
>>>> Is configType a parameter? where is it coming from?
>>>>
>>>> musachy
>>>>
>>>> On Fri, Oct 3, 2008 at 10:16 AM, Giovanni Azua <gi...@imc.nl> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> hi,
>>>>>
>>>>> I have different types of (trading strategy/algorithm) configurations. My
>>>>> application allows scheduling Simulations for any of the existing types,
>>>>> depending on the type it should be redirected to a specific form e.g.
>>>>>
>>>>> --------------------------------------------
>>>>> Example
>>>>> --------------------------------------------
>>>>> Algo 1 Config -\ / Form Schedule Sim "Algo 1
>>>>> Config"
>>>>> Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
>>>>> Algo 3 Config -/ \ Form Schedule Sim "Algo 3
>>>>> Config"
>>>>>
>>>>> I have many "Opp" actions that generically handle any type of
>>>>> configuration
>>>>> but from there it needs to redirect to the type-specific form. To do the
>>>>> forking part I am trying to use a redirect action mapping with an OGNL
>>>>> expression like this:
>>>>>
>>>>> <action name="FormScheduleSimulation">
>>>>> <result type="redirectAction">${ 'FormScheduleSimulation' +
>>>>> configType.name }</result>
>>>>> </action>
>>>>> But here the result parameters coming from "Opp" do not get passed
>>>>> through
>>>>> and the ONGL expression does not see the needed configType bean. To solve
>>>>> this I imported the CodeBehind plugin expecting it to automatically
>>>>> discover
>>>>> that "FormScheduleSimulation" action does not have a corresponding Action
>>>>> class and therefore it would create one on the fly and let the original
>>>>> action result parameters pass right through including the needed
>>>>> "configType" but does not work.
>>>>>
>>>>> Is there any additional step to take for the Code Behind plugin to work
>>>>> here ... ?
>>>>>
>>>>> TIA,
>>>>> Regards,
>>>>> Giovanni
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: criteria-based action forking: missusing Code behind?
Posted by Giovanni Azua <gi...@imc.nl>.
btw I am using v2.1.2
do you mean like this:
<action name="FormScheduleSimulation">
<result type="redirectAction">${ 'FormScheduleSimulation' +
#parameters.configType.name }</result>
</action>
unfortunately does not work like that :(
regards,
Giovanni
Musachy Barroso wrote:
> yup, that's the problem, I think. If it is a parameter you can reference it
> as #parameters.xyz.
>
> On Fri, Oct 3, 2008 at 10:29 AM, Giovanni Azua <gi...@imc.nl> wrote:
>
>
>> hi! :)
>>
>> The configType is a bean property exposed by the "Opp" action. In fact I
>> get the error logging below. I believe this happens because there is no
>> action passing these parameters through (I expected Code Behind to do it for
>> me). Meantime I will try providing an action class to see if it works ...
>>
>> Many thanks!
>> Best regards,
>> Giovanni
>>
>> Oct 3, 2008 4:24:12 PM
>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>> caught setting 'configType' on 'class com.opensymphony.xwork2.ActionSupport:
>> Error setting expression 'configType' with value ['T11', ]
>> Oct 3, 2008 4:24:12 PM
>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>> caught setting 'exportFileName' on 'class
>> com.opensymphony.xwork2.ActionSupport: Error setting expression
>> 'exportFileName' with value ['null', ]
>> Oct 3, 2008 4:24:12 PM
>> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
>> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
>> caught setting 'simulationRunId' on 'class
>> com.opensymphony.xwork2.ActionSupport: Error setting expression
>> 'simulationRunId' with value ['I30gBGp.1FxpeY.Hp35xbF.1k', ]
>>
>>
>>
>> Musachy Barroso wrote:
>>
>>
>>> Is configType a parameter? where is it coming from?
>>>
>>> musachy
>>>
>>> On Fri, Oct 3, 2008 at 10:16 AM, Giovanni Azua <gi...@imc.nl> wrote:
>>>
>>>
>>>
>>>
>>>> hi,
>>>>
>>>> I have different types of (trading strategy/algorithm) configurations. My
>>>> application allows scheduling Simulations for any of the existing types,
>>>> depending on the type it should be redirected to a specific form e.g.
>>>>
>>>> --------------------------------------------
>>>> Example
>>>> --------------------------------------------
>>>> Algo 1 Config -\ / Form Schedule Sim "Algo 1
>>>> Config"
>>>> Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
>>>> Algo 3 Config -/ \ Form Schedule Sim "Algo 3
>>>> Config"
>>>>
>>>> I have many "Opp" actions that generically handle any type of
>>>> configuration
>>>> but from there it needs to redirect to the type-specific form. To do the
>>>> forking part I am trying to use a redirect action mapping with an OGNL
>>>> expression like this:
>>>>
>>>> <action name="FormScheduleSimulation">
>>>> <result type="redirectAction">${ 'FormScheduleSimulation' +
>>>> configType.name }</result>
>>>> </action>
>>>> But here the result parameters coming from "Opp" do not get passed
>>>> through
>>>> and the ONGL expression does not see the needed configType bean. To solve
>>>> this I imported the CodeBehind plugin expecting it to automatically
>>>> discover
>>>> that "FormScheduleSimulation" action does not have a corresponding Action
>>>> class and therefore it would create one on the fly and let the original
>>>> action result parameters pass right through including the needed
>>>> "configType" but does not work.
>>>>
>>>> Is there any additional step to take for the Code Behind plugin to work
>>>> here ... ?
>>>>
>>>> TIA,
>>>> Regards,
>>>> Giovanni
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: criteria-based action forking: missusing Code behind?
Posted by Musachy Barroso <mu...@gmail.com>.
yup, that's the problem, I think. If it is a parameter you can reference it
as #parameters.xyz.
On Fri, Oct 3, 2008 at 10:29 AM, Giovanni Azua <gi...@imc.nl> wrote:
> hi! :)
>
> The configType is a bean property exposed by the "Opp" action. In fact I
> get the error logging below. I believe this happens because there is no
> action passing these parameters through (I expected Code Behind to do it for
> me). Meantime I will try providing an action class to see if it works ...
>
> Many thanks!
> Best regards,
> Giovanni
>
> Oct 3, 2008 4:24:12 PM
> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
> caught setting 'configType' on 'class com.opensymphony.xwork2.ActionSupport:
> Error setting expression 'configType' with value ['T11', ]
> Oct 3, 2008 4:24:12 PM
> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
> caught setting 'exportFileName' on 'class
> com.opensymphony.xwork2.ActionSupport: Error setting expression
> 'exportFileName' with value ['null', ]
> Oct 3, 2008 4:24:12 PM
> com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
> SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
> caught setting 'simulationRunId' on 'class
> com.opensymphony.xwork2.ActionSupport: Error setting expression
> 'simulationRunId' with value ['I30gBGp.1FxpeY.Hp35xbF.1k', ]
>
>
>
> Musachy Barroso wrote:
>
>> Is configType a parameter? where is it coming from?
>>
>> musachy
>>
>> On Fri, Oct 3, 2008 at 10:16 AM, Giovanni Azua <gi...@imc.nl> wrote:
>>
>>
>>
>>> hi,
>>>
>>> I have different types of (trading strategy/algorithm) configurations. My
>>> application allows scheduling Simulations for any of the existing types,
>>> depending on the type it should be redirected to a specific form e.g.
>>>
>>> --------------------------------------------
>>> Example
>>> --------------------------------------------
>>> Algo 1 Config -\ / Form Schedule Sim "Algo 1
>>> Config"
>>> Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
>>> Algo 3 Config -/ \ Form Schedule Sim "Algo 3
>>> Config"
>>>
>>> I have many "Opp" actions that generically handle any type of
>>> configuration
>>> but from there it needs to redirect to the type-specific form. To do the
>>> forking part I am trying to use a redirect action mapping with an OGNL
>>> expression like this:
>>>
>>> <action name="FormScheduleSimulation">
>>> <result type="redirectAction">${ 'FormScheduleSimulation' +
>>> configType.name }</result>
>>> </action>
>>> But here the result parameters coming from "Opp" do not get passed
>>> through
>>> and the ONGL expression does not see the needed configType bean. To solve
>>> this I imported the CodeBehind plugin expecting it to automatically
>>> discover
>>> that "FormScheduleSimulation" action does not have a corresponding Action
>>> class and therefore it would create one on the fly and let the original
>>> action result parameters pass right through including the needed
>>> "configType" but does not work.
>>>
>>> Is there any additional step to take for the Code Behind plugin to work
>>> here ... ?
>>>
>>> TIA,
>>> Regards,
>>> Giovanni
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: criteria-based action forking: missusing Code behind?
Posted by Giovanni Azua <gi...@imc.nl>.
hi! :)
The configType is a bean property exposed by the "Opp" action. In fact I
get the error logging below. I believe this happens because there is no
action passing these parameters through (I expected Code Behind to do it
for me). Meantime I will try providing an action class to see if it
works ...
Many thanks!
Best regards,
Giovanni
Oct 3, 2008 4:24:12 PM
com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
caught setting 'configType' on 'class
com.opensymphony.xwork2.ActionSupport: Error setting expression
'configType' with value ['T11', ]
Oct 3, 2008 4:24:12 PM
com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
caught setting 'exportFileName' on 'class
com.opensymphony.xwork2.ActionSupport: Error setting expression
'exportFileName' with value ['null', ]
Oct 3, 2008 4:24:12 PM
com.opensymphony.xwork2.util.logging.commons.CommonsLogger error
SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception
caught setting 'simulationRunId' on 'class
com.opensymphony.xwork2.ActionSupport: Error setting expression
'simulationRunId' with value ['I30gBGp.1FxpeY.Hp35xbF.1k', ]
Musachy Barroso wrote:
> Is configType a parameter? where is it coming from?
>
> musachy
>
> On Fri, Oct 3, 2008 at 10:16 AM, Giovanni Azua <gi...@imc.nl> wrote:
>
>
>> hi,
>>
>> I have different types of (trading strategy/algorithm) configurations. My
>> application allows scheduling Simulations for any of the existing types,
>> depending on the type it should be redirected to a specific form e.g.
>>
>> --------------------------------------------
>> Example
>> --------------------------------------------
>> Algo 1 Config -\ / Form Schedule Sim "Algo 1 Config"
>> Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
>> Algo 3 Config -/ \ Form Schedule Sim "Algo 3 Config"
>>
>> I have many "Opp" actions that generically handle any type of configuration
>> but from there it needs to redirect to the type-specific form. To do the
>> forking part I am trying to use a redirect action mapping with an OGNL
>> expression like this:
>>
>> <action name="FormScheduleSimulation">
>> <result type="redirectAction">${ 'FormScheduleSimulation' +
>> configType.name }</result>
>> </action>
>> But here the result parameters coming from "Opp" do not get passed through
>> and the ONGL expression does not see the needed configType bean. To solve
>> this I imported the CodeBehind plugin expecting it to automatically discover
>> that "FormScheduleSimulation" action does not have a corresponding Action
>> class and therefore it would create one on the fly and let the original
>> action result parameters pass right through including the needed
>> "configType" but does not work.
>>
>> Is there any additional step to take for the Code Behind plugin to work
>> here ... ?
>>
>> TIA,
>> Regards,
>> Giovanni
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: criteria-based action forking: missusing Code behind?
Posted by Musachy Barroso <mu...@gmail.com>.
Is configType a parameter? where is it coming from?
musachy
On Fri, Oct 3, 2008 at 10:16 AM, Giovanni Azua <gi...@imc.nl> wrote:
> hi,
>
> I have different types of (trading strategy/algorithm) configurations. My
> application allows scheduling Simulations for any of the existing types,
> depending on the type it should be redirected to a specific form e.g.
>
> --------------------------------------------
> Example
> --------------------------------------------
> Algo 1 Config -\ / Form Schedule Sim "Algo 1 Config"
> Algo 2 Config -- Opp -> Fork - Form Schedule Sim "Algo 2 Config"
> Algo 3 Config -/ \ Form Schedule Sim "Algo 3 Config"
>
> I have many "Opp" actions that generically handle any type of configuration
> but from there it needs to redirect to the type-specific form. To do the
> forking part I am trying to use a redirect action mapping with an OGNL
> expression like this:
>
> <action name="FormScheduleSimulation">
> <result type="redirectAction">${ 'FormScheduleSimulation' +
> configType.name }</result>
> </action>
> But here the result parameters coming from "Opp" do not get passed through
> and the ONGL expression does not see the needed configType bean. To solve
> this I imported the CodeBehind plugin expecting it to automatically discover
> that "FormScheduleSimulation" action does not have a corresponding Action
> class and therefore it would create one on the fly and let the original
> action result parameters pass right through including the needed
> "configType" but does not work.
>
> Is there any additional step to take for the Code Behind plugin to work
> here ... ?
>
> TIA,
> Regards,
> Giovanni
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd