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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
