[jira] [Updated] (MYFACES-3434) UIInput.resetValue() throws NPE when no FacesContext available
[ https://issues.apache.org/jira/browse/MYFACES-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3434: Resolution: Fixed Fix Version/s: 2.1.7 2.0.13 Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch UIInput.resetValue() throws NPE when no FacesContext available -- Key: MYFACES-3434 URL: https://issues.apache.org/jira/browse/MYFACES-3434 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3434.patch Project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ clears pooled UIViewRoot outside request/response in a separate thread, with no FacesContext. Methods UIInput.setValue() and UIInput.setSubmittedValue() throw in such situation NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3434) UIInput.resetValue() throws NPE when no FacesContext available
UIInput.resetValue() throws NPE when no FacesContext available -- Key: MYFACES-3434 URL: https://issues.apache.org/jira/browse/MYFACES-3434 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ clears pooled UIViewRoot outside request/response in a separate thread, with no FacesContext. Methods UIInput.setValue() and UIInput.setSubmittedValue() throw in such situation NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3434) UIInput.resetValue() throws NPE when no FacesContext available
[ https://issues.apache.org/jira/browse/MYFACES-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kočí updated MYFACES-3434: - Status: Patch Available (was: Open) UIInput.resetValue() throws NPE when no FacesContext available -- Key: MYFACES-3434 URL: https://issues.apache.org/jira/browse/MYFACES-3434 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3434.patch Project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ clears pooled UIViewRoot outside request/response in a separate thread, with no FacesContext. Methods UIInput.setValue() and UIInput.setSubmittedValue() throw in such situation NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: UIInput.resetValue()
-1 Sorry, I cannot agree. The API doc of resetValue() tells you why: Convenience method to reset [..] A utility like method for convenience like this one does not belong to an interface. It does not add any behavioural function. UIInput is not an interface but a (base) class, so it is ok to have such a method there. Matze, do you have any concrete use case that could confirm your POV? --Manfred On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, the resetValue() method was added directly to UIinput, instead to a proper interface (EditableValueHolder). I guess this was done, to not break impls of that interface. IMO this is wrong and should (at least in JSF2) be part of the EditableValueHolder interface. Since JSF2 will bring much more new bits, such an enhancement on the interface might be valueable. What is your take on that ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for example,
does not extends UIInput, but do implement EditableValueHolder so the loop's
body has to look like:
if (component instanceof UIXEditable)
{
((UIXEditable)component).resetValue();
}
else if (component instanceof UIInput)
{
((UIInput)component).resetValue();
}
else if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Maybe a good compromise would be to alter UIViewRoot to add a
resetAllEditableValueHolderValues method.
Regards,
~ Simon
On Jan 15, 2008 3:19 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
-1
Sorry, I cannot agree.
The API doc of resetValue() tells you why:
Convenience method to reset [..]
A utility like method for convenience like this one does not belong
to an interface. It does not add any behavioural function.
UIInput is not an interface but a (base) class, so it is ok to have
such a method there.
Matze, do you have any concrete use case that could confirm your POV?
--Manfred
On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
the resetValue() method was added directly to UIinput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.
IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.
Since JSF2 will bring much more new bits, such an enhancement on the
interface might be valueable.
What is your take on that ?
-Matthias
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Why not use the last if alone?
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
This code fragement could also be candidate for a
EditableValueHolderUtils class in the MyFaces Commons.
--Manfred
On Jan 15, 2008 3:47 PM, Simon Lessard [EMAIL PROTECTED] wrote:
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for example,
does not extends UIInput, but do implement EditableValueHolder so the loop's
body has to look like:
if (component instanceof UIXEditable)
{
((UIXEditable)component).resetValue();
}
else if (component instanceof UIInput)
{
((UIInput)component).resetValue();
}
else if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Maybe a good compromise would be to alter UIViewRoot to add a
resetAllEditableValueHolderValues method.
Regards,
~ Simon
On Jan 15, 2008 3:19 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
-1
Sorry, I cannot agree.
The API doc of resetValue() tells you why:
Convenience method to reset [..]
A utility like method for convenience like this one does not belong
to an interface. It does not add any behavioural function.
UIInput is not an interface but a (base) class, so it is ok to have
such a method there.
Matze, do you have any concrete use case that could confirm your POV?
--Manfred
On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
the resetValue() method was added directly to UIinput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.
IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.
Since JSF2 will bring much more new bits, such an enhancement on the
interface might be valueable.
What is your take on that ?
-Matthias
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Matze, do you have any concrete use case that could confirm your POV? a hack like the mentioned utility does it. But using clean interfaces would be more appreciated. Originally this email should go the the RI list, b/c I am hoping that the interface changes in JSF2 (for some reasons). We here can only talk... The spec itself is made behind closed doors ;-) -M --Manfred On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, the resetValue() method was added directly to UIinput, instead to a proper interface (EditableValueHolder). I guess this was done, to not break impls of that interface. IMO this is wrong and should (at least in JSF2) be part of the EditableValueHolder interface. Since JSF2 will bring much more new bits, such an enhancement on the interface might be valueable. What is your take on that ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred
Re: UIInput.resetValue()
As I said, I see from the backwards compatibility why it was done.
On Jan 15, 2008 7:02 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Why not use the last if alone?
because this all is already done in JSF ...
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
This code fragement could also be candidate for a
EditableValueHolderUtils class in the MyFaces Commons.
jup, good idea. That would be more leverage able;
--Manfred
On Jan 15, 2008 3:47 PM, Simon Lessard [EMAIL PROTECTED] wrote:
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for example,
does not extends UIInput, but do implement EditableValueHolder so the loop's
body has to look like:
if (component instanceof UIXEditable)
{
((UIXEditable)component).resetValue();
}
else if (component instanceof UIInput)
{
((UIInput)component).resetValue();
}
else if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Maybe a good compromise would be to alter UIViewRoot to add a
resetAllEditableValueHolderValues method.
Regards,
~ Simon
On Jan 15, 2008 3:19 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
-1
Sorry, I cannot agree.
The API doc of resetValue() tells you why:
Convenience method to reset [..]
A utility like method for convenience like this one does not belong
to an interface. It does not add any behavioural function.
UIInput is not an interface but a (base) class, so it is ok to have
such a method there.
Matze, do you have any concrete use case that could confirm your POV?
--Manfred
On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
the resetValue() method was added directly to UIinput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.
IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.
Since JSF2 will bring much more new bits, such an enhancement on the
interface might be valueable.
What is your take on that ?
-Matthias
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Personally, considering there's always backward compatibility issues anyway, I wouldn't mind seeing some new ones if it was to allow JSF to be much faster, easier to use and more extensible. Like standardizing FacesBean for instance. If done correctly, it would give a decent speed boost, allow easier and more intelligent state saving as well as many other goodies. I'd really like to see a way to extends the Lifecycle more easily as well, maybe implying standardization of the Phase classes. Maybe adding new phases as well like register resources occurring before render to push all dependencies in a rendering context and thus allowing all script references to be rendered in the head element thus respecting w3c. A coherence validation phase as well as a mean to execute a Callback on the whole tree (to implement custom phases for example) wouldn't be unwelcome either. Anyway, we'll see that in due time. Regards, ~ Simon On Jan 15, 2008 10:33 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice... On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote: On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
nice... On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote: On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Yes, which mean that I might make such propositions or support them, but I'm not the only member and I'm pretty such that some members see apparent backward compatibility to be a precept above anything else. ~ Simon On Jan 15, 2008 11:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: aren't you part of the EG ? :-) -M On Jan 15, 2008 7:46 AM, Simon Lessard [EMAIL PROTECTED] wrote: Personally, considering there's always backward compatibility issues anyway, I wouldn't mind seeing some new ones if it was to allow JSF to be much faster, easier to use and more extensible. Like standardizing FacesBean for instance. If done correctly, it would give a decent speed boost, allow easier and more intelligent state saving as well as many other goodies. I'd really like to see a way to extends the Lifecycle more easily as well, maybe implying standardization of the Phase classes. Maybe adding new phases as well like register resources occurring before render to push all dependencies in a rendering context and thus allowing all script references to be rendered in the head element thus respecting w3c. A coherence validation phase as well as a mean to execute a Callback on the whole tree (to implement custom phases for example) wouldn't be unwelcome either. Anyway, we'll see that in due time. Regards, ~ Simon On Jan 15, 2008 10:33 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice... On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote: On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1) -M On Jan 15, 2008 9:57 AM, Simon Lessard [EMAIL PROTECTED] wrote: Yes, which mean that I might make such propositions or support them, but I'm not the only member and I'm pretty such that some members see apparent backward compatibility to be a precept above anything else. ~ Simon On Jan 15, 2008 11:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: aren't you part of the EG ? :-) -M On Jan 15, 2008 7:46 AM, Simon Lessard [EMAIL PROTECTED] wrote: Personally, considering there's always backward compatibility issues anyway, I wouldn't mind seeing some new ones if it was to allow JSF to be much faster, easier to use and more extensible. Like standardizing FacesBean for instance. If done correctly, it would give a decent speed boost, allow easier and more intelligent state saving as well as many other goodies. I'd really like to see a way to extends the Lifecycle more easily as well, maybe implying standardization of the Phase classes. Maybe adding new phases as well like register resources occurring before render to push all dependencies in a rendering context and thus allowing all script references to be rendered in the head element thus respecting w3c. A coherence validation phase as well as a mean to execute a Callback on the whole tree (to implement custom phases for example) wouldn't be unwelcome either. Anyway, we'll see that in due time. Regards, ~ Simon On Jan 15, 2008 10:33 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice... On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote: On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
And I sure hope it will. On Jan 15, 2008 1:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1) -M On Jan 15, 2008 9:57 AM, Simon Lessard [EMAIL PROTECTED] wrote: Yes, which mean that I might make such propositions or support them, but I'm not the only member and I'm pretty such that some members see apparent backward compatibility to be a precept above anything else. ~ Simon On Jan 15, 2008 11:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: aren't you part of the EG ? :-) -M On Jan 15, 2008 7:46 AM, Simon Lessard [EMAIL PROTECTED] wrote: Personally, considering there's always backward compatibility issues anyway, I wouldn't mind seeing some new ones if it was to allow JSF to be much faster, easier to use and more extensible. Like standardizing FacesBean for instance. If done correctly, it would give a decent speed boost, allow easier and more intelligent state saving as well as many other goodies. I'd really like to see a way to extends the Lifecycle more easily as well, maybe implying standardization of the Phase classes. Maybe adding new phases as well like register resources occurring before render to push all dependencies in a rendering context and thus allowing all script references to be rendered in the head element thus respecting w3c. A coherence validation phase as well as a mean to execute a Callback on the whole tree (to implement custom phases for example) wouldn't be unwelcome either. Anyway, we'll see that in due time. Regards, ~ Simon On Jan 15, 2008 10:33 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice... On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote: On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
UIInput.resetValue()
Hi, the resetValue() method was added directly to UIinput, instead to a proper interface (EditableValueHolder). I guess this was done, to not break impls of that interface. IMO this is wrong and should (at least in JSF2) be part of the EditableValueHolder interface. Since JSF2 will bring much more new bits, such an enhancement on the interface might be valueable. What is your take on that ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
