You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Stephen Friedrich <tr...@eekboom.com> on 2007/08/30 03:05:46 UTC
[Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Pheewww - spent a couple of hours chasing a bug - getting very late again ...
After upgrading from Trinidad 1.0.1/MyFaces to Trinidad 1.2.1/JSF RI 1.2.04
all my "validateDoubleRange" tags stopped working completely.
Probably other validators are also affected.
If I understand the problem correctly:
These methods
org.apache.myfaces.trinidad.validator.DoubleRangeValidator.saveState()/restoreState()
do not save the fields minimumSet/maximumSet of superclass javax.faces.validator.DoubleRangeValidator:
However the validate method of Trinidad's DoubleRangeValidator delegates to super() which
thinks that neither minimum or maximum is set, so validation always passes.
How to fix this?
BTW: I don't yet understand why client side validation does not kick in even before
the wrong value gets to the server.
Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Posted by Matthias Wessendorf <ma...@apache.org>.
hi,
looks like the maximumSet fields are present in JSF 1.1 RI as well.
Let me check what really the issue is, here
Trinidad's validators do have some extra properties, like
messageDetailMaximum on the doublerangevalidator, so we override it.
We delegate the save/restore to the underlying FacesBean, which is
more efficient.
@Bug, I fix this in some minutes :-)
Thx,
Matthias
On 8/30/07, Stephen Friedrich <tr...@eekboom.com> wrote:
> Matthias Wessendorf wrote:
> > Well, why should Trinidad care about the minSet/maxSet. They are only
> > in the RI, as you say.
> > Not in MyFaces. Wouldn't that cause other issues ?
>
> Well ok, I can try and raise the issue with the Sun folks.
> However I think it's in the best interest of Trinidad to play nice with the RI
> and that a "Matthias Wessendorf" is much better suited to discuss this than
> a "Stephen Friedrich" ;-)
> Maybe you even have personal contacts to some of the RI developers.
>
> What would really help is if you could point me to some paragraph in the spec
> that says you must only save/restore public attributes. Lacking that I still
> don't have any valid argument why the RI is broken.
>
> I don't know that much about the spec and its internal implementation, but
> so far it appears to me similar to the serialization problems you'll get
> when a subclass fails to serialize the super class's fields. In that case it's
> not the super class that is to blame.
>
> Anyway: Why _do_ the Trinidad validators have to overwrite saveState/restoreState
> at all? I don't see them adding anything of value.
> Or maybe do not extend the standard faces DoubleRangeValidator at all.
>
> BTW:
> Here is a code snippet that to my unsuspecting eyes looks like a definite
> Trinidad bug:
>
> In org.apache.myfaces.trinidad.validator.DoubleRangeValidator:
> public DoubleRangeValidator(long maximum)
> {
> super();
> }
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Posted by Stephen Friedrich <tr...@eekboom.com>.
Matthias Wessendorf wrote:
> Well, why should Trinidad care about the minSet/maxSet. They are only
> in the RI, as you say.
> Not in MyFaces. Wouldn't that cause other issues ?
Well ok, I can try and raise the issue with the Sun folks.
However I think it's in the best interest of Trinidad to play nice with the RI
and that a "Matthias Wessendorf" is much better suited to discuss this than
a "Stephen Friedrich" ;-)
Maybe you even have personal contacts to some of the RI developers.
What would really help is if you could point me to some paragraph in the spec
that says you must only save/restore public attributes. Lacking that I still
don't have any valid argument why the RI is broken.
I don't know that much about the spec and its internal implementation, but
so far it appears to me similar to the serialization problems you'll get
when a subclass fails to serialize the super class's fields. In that case it's
not the super class that is to blame.
Anyway: Why _do_ the Trinidad validators have to overwrite saveState/restoreState
at all? I don't see them adding anything of value.
Or maybe do not extend the standard faces DoubleRangeValidator at all.
BTW:
Here is a code snippet that to my unsuspecting eyes looks like a definite
Trinidad bug:
In org.apache.myfaces.trinidad.validator.DoubleRangeValidator:
public DoubleRangeValidator(long maximum)
{
super();
}
Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Posted by Matthias Wessendorf <ma...@apache.org>.
> Well, yeah, because these fields are not in the MyFaces implementation it works there, but breaks in RI.
> How can you argue that there's no need to save/restore the fields because they are non-standard?
> Is the "save format" specified by the standard? The RI does save/restore the fields and it works ok
> when not using Trinidad. IMHO it is Trinidad that causes the bug by not honoring the super class specifics.
Well, why should Trinidad care about the minSet/maxSet. They are only
in the RI, as you say.
Not in MyFaces. Wouldn't that cause other issues ?
are these xyzSet fields new in JSF 1.2.x ?
>
> >
> >> How to fix this?
> >
> > when it is in the RI, ask the sun guys.
> >
> >>
> >> BTW: I don't yet understand why client side validation does not kick in even before
> >> the wrong value gets to the server.
> >
> > Interesting is, that I am also on JSF RI 1.2.x + Trinidad stack, works fine.
> >
> > So, feel free to file an issue, with details (and a test-case ?)
>
> You mean you get client validation, right?
> Or do you also don't see the bug with the server side not validating min/max values?
> Client validation _is_ working in simpler forms for me, maybe my complex page breaks something.
> I get these warnings in the console. Do you think they can have something to do with the issue:
>
> 03:44:16,468 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugHtmlResponseWriter _errorWithComment
> WARNUNG: Illegal HTML: cannot put a <form> element in a <table> element.
> 03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "costLimit::icon" is used more than once.
> 03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "costLimit::msg" is used more than once.
>
> (I definitely do not use the "costLimit" id more than once, no idea why there are duplicates of these generated ids.
the response writer tells you, that <form> inside a <table> isn't valid HTML.
However, please file an issue, I'll take a look, what's going on.
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Posted by Stephen Friedrich <tr...@eekboom.com>.
Thanks for the answer, see my comments below.
Matthias Wessendorf wrote:
>> If I understand the problem correctly:
>> These methods
>> org.apache.myfaces.trinidad.validator.DoubleRangeValidator.saveState()/restoreState()
>> do not save the fields minimumSet/maximumSet of superclass javax.faces.validator.DoubleRangeValidator:
>
> I don't see a minimumSet/maximumSet field in
> javax.faces.validator.DoubleRangeValidator
> (looking at the MyFaces source). These fields aren't standard, no
> need to save/restore them.
Well, yeah, because these fields are not in the MyFaces implementation it works there, but breaks in RI.
How can you argue that there's no need to save/restore the fields because they are non-standard?
Is the "save format" specified by the standard? The RI does save/restore the fields and it works ok
when not using Trinidad. IMHO it is Trinidad that causes the bug by not honoring the super class specifics.
>
>> How to fix this?
>
> when it is in the RI, ask the sun guys.
>
>>
>> BTW: I don't yet understand why client side validation does not kick in even before
>> the wrong value gets to the server.
>
> Interesting is, that I am also on JSF RI 1.2.x + Trinidad stack, works fine.
>
> So, feel free to file an issue, with details (and a test-case ?)
You mean you get client validation, right?
Or do you also don't see the bug with the server side not validating min/max values?
Client validation _is_ working in simpler forms for me, maybe my complex page breaks something.
I get these warnings in the console. Do you think they can have something to do with the issue:
03:44:16,468 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugHtmlResponseWriter _errorWithComment
WARNUNG: Illegal HTML: cannot put a <form> element in a <table> element.
03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNUNG: The id "costLimit::icon" is used more than once.
03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNUNG: The id "costLimit::msg" is used more than once.
(I definitely do not use the "costLimit" id more than once, no idea why there are duplicates of these generated ids.
Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
> If I understand the problem correctly:
> These methods
> org.apache.myfaces.trinidad.validator.DoubleRangeValidator.saveState()/restoreState()
> do not save the fields minimumSet/maximumSet of superclass javax.faces.validator.DoubleRangeValidator:
I don't see a minimumSet/maximumSet field in
javax.faces.validator.DoubleRangeValidator
(looking at the MyFaces source). These fields aren't standard, no
need to save/restore them.
> How to fix this?
when it is in the RI, ask the sun guys.
>
>
> BTW: I don't yet understand why client side validation does not kick in even before
> the wrong value gets to the server.
Interesting is, that I am also on JSF RI 1.2.x + Trinidad stack, works fine.
So, feel free to file an issue, with details (and a test-case ?)
-M
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org