[
https://issues.apache.org/jira/browse/DELTASPIKE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-768.
-----------------------------------------
Resolution: Not a Problem
we don't handle that at all -> we can't check and log it.
you might face something else here (maybe seam suppressed it).
with myfaces-core (with or without deltaspike), you get the same behavior
(including a error message like: [component-id]: '[parameter-value]' must be a
number between -9223372036854775808 to 9223372036854775807 Example: 9392218515)
> 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)
