First, the appropriate place to take this is
dev_at_javaserverfaces.dev.java.net, since that's where dev questions (and
complainsts) should be directed, not to any individual developer on the
project.
More inline.
On 4/28/09 10:16 AM, sterjevm_at_t-home.mk wrote:
> Hello,
>
> I can see a lot of related issues regarding JSF input value handling
> mechanism (submitted value, local value, VE). And I must say this is
> frustrating because the bugs are for such obvious things.
JSF is a big codebase, and our code coverage is a stunningly high 90%,
as of 1.2 (though much lower right now with the many new features added
in 2.0). If you have other test cases that fail, please open bugs for
them, especially with failing examples of valid code that are small, and
concise, and we'll do our best to address the problems as fast as we
can. We also then add those cases to our test base as the bugs are
fixed, to prevent regressions, and boost our coverage.
> Some of them you are neglecting and some of them are postponed for
> future releases. For example:
> Issue 904 is closed as RESOLVED having resolution WORKSFORME. How is
> that? This is perfectly legal and non trivial issue: the select
> checkboxes does not preserve the submitted value in IMMEDIATE actions,
> i.e. they render the previous, already stored local value if any, or VE
> is re-evaluated.
IIRC, I was unable to duplicate the bug with the supplied code.
Please note that the end comment of the bug said: "Please feel free to
reopen this bug with a reproducable test case at any time,
and we'll look at it right away."
Instead of reopening the bug with a reproducable test case, you chose
instead to write me directly to berate me. That won't get the bug
reopened - code will. While our bug tracking system is hardly a perfect
one, it is open to the public for submission of problems. Please use it
- we look at our bug list daily, and measure our success by it.
> Issue 838 is also not a trivial one too: isLocalValueSet() is not
> used, so the framework does not distinguish between cleared, null local
> value with updated model and null value as local value in the failed
> falidation. I don't think this is not an important one to be fixed in
> the JSF 1.2.x.
838 is one of about 300 bugs which we've worked on in the last 6 months.
If you have a fix, please attach it to the bug. Otherwise, we've
scheduled it for fix by our next major release, with a backport to 1.2
at that time. Please note that of those 300 odd bugs, we've
fixed 200 already, keeping our bug count at about 100 despite adding
many features in that time.
How we pick bugs is driven by their severity, the frequency they are
encountered, and how hard they are to fix, just like any project.
> Sorry, but WE, the rest of the world, expect that this RI is something
> that we can rely on as firm JSF foundation that follows the
> specification and the ideas therein.
That is, in fact, our goal, but see below.
> That is not the case considering
> the above bugs. Total confusion is the end result for someone reading
> JSF specification and observing the behavior of this RI!
No product is without bugs. One of the things that we consider in
assigning priority to fixing bugs is the number of votes for a bug - at
7, this bug *is* considered important by our community. Which is why
it's scheduled to be fixed within the next month or so...
Please note that while the initial bug was submitted 6 months ago, the
first confirming vote was only last month. That means that for the
first 5 months that the bug existed, it seemed that only one user cared
enough to mark it as important. Hence, our prioritization.
So, the message I'd like to give you is: report the bugs, and vote for
the ones that matter to you - it's what we look at.
Lastly, bugs that are submitted in the form of a patch that the
submitter says works are typically applied within the month that they're
submitted. So that's another way that you can get the bug fixed more
quickly.
>
> Regards,
>
> Marjan Sterjev