[
https://issues.apache.org/jira/browse/DELTASPIKE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek closed DELTASPIKE-768.
---------------------------------------
> GET request parameter silently discarded upon type discrepancy with JSF
> -----------------------------------------------------------------------
>
> Key: DELTASPIKE-768
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-768
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
> Affects Versions: 1.0.3
> Environment: Glassfish 3.1.2.2, JSF 2.1.28, Weld 1.1.14, Richfaces,
> Rewrite
> Reporter: Fabien MARSAUD
> Priority: Minor
> Labels: jsf, parameter, request
>
> I have a request scoped managed bean which receives paypal IPN notifications.
> IPNs contain a shared "secret" String parameter transferred as a http GET
> param.
> I had a correct setSecret(String) on my backing bean, but because of a bad 5
> year-old copy/paste, I had the wrong return type on getSecret(). It was never
> noticed because the *getter* was never called anywhere, and with Seam we used
> until our previous release , "secret" was *set* without complaining anyway.
> On the page: {code}
> <f:metadata>
> <f:viewParam name="secret" value="#{orderPaypalIPN.secret}" />
> </f:metadata>{code}
> In the code:{code}
> @Named("orderPaypalIPN")
> @RequestScoped
> public class OrderPaypalIPNHandler {
> private String secret;
> //getter needed by JSF2
> public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
> return null; //security reason
> }
> public void setSecret(String secret) {
> this.secret = secret;
> }
> {code}
> So, when we were using Seam, "secret" was correctly set, then used by the
> rest of the code. When we started using DeltaSpike instead, "secret" was not
> set anymore (even though the issue was with the getter, not the setter). I'm
> OK with it (more strict, better), except that the get/set discrepancy is not
> logged. I think it should be.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
