[jira] Created: (MYFACES-2891) Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping
Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping -- Key: MYFACES-2891 URL: https://issues.apache.org/jira/browse/MYFACES-2891 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Weblogic 10.3, Sun JAVA 1.6, Spring Framework 3.0.3, Spring Webflow 2.1.1 Reporter: Michal Dvorak The loop while (uri.startsWith(prefix) || uri.startsWith(//)) ... cannot end when prefix is empty string (which should be valid value). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2891) Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping
[ https://issues.apache.org/jira/browse/MYFACES-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901762#action_12901762 ] Michal Dvorak commented on MYFACES-2891: This happens probably only when using Spring, where viewId comes already resolved to /WEB-INF/... path, and prefix is empty string. I solved it simply by adding if (prefix.length() == 0) viewId; to the start of the method. Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping -- Key: MYFACES-2891 URL: https://issues.apache.org/jira/browse/MYFACES-2891 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Weblogic 10.3, Sun JAVA 1.6, Spring Framework 3.0.3, Spring Webflow 2.1.1 Reporter: Michal Dvorak Original Estimate: 0.5h Remaining Estimate: 0.5h The loop while (uri.startsWith(prefix) || uri.startsWith(//)) ... cannot end when prefix is empty string (which should be valid value). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2891) Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping
[ https://issues.apache.org/jira/browse/MYFACES-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901762#action_12901762 ] Michal Dvorak edited comment on MYFACES-2891 at 8/24/10 4:06 AM: - This happens probably only when using Spring, where viewId comes already resolved to /WEB-INF/... path, and prefix is empty string. I solved it simply by adding if (prefix.length() == 0) viewId; to the start of the method (althou it wont remove leading // in the path as loop does). was (Author: mikee2185): This happens probably only when using Spring, where viewId comes already resolved to /WEB-INF/... path, and prefix is empty string. I solved it simply by adding if (prefix.length() == 0) viewId; to the start of the method. Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping -- Key: MYFACES-2891 URL: https://issues.apache.org/jira/browse/MYFACES-2891 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Weblogic 10.3, Sun JAVA 1.6, Spring Framework 3.0.3, Spring Webflow 2.1.1 Reporter: Michal Dvorak Original Estimate: 0.5h Remaining Estimate: 0.5h The loop while (uri.startsWith(prefix) || uri.startsWith(//)) ... cannot end when prefix is empty string (which should be valid value). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces site skin v 1
+1 On Mon, Aug 23, 2010 at 10:46 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/8/23 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the version 1 release of Apache MyFaces Site Skin. This artifact is required to build the site of some myfaces projects. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven.myfaces-site-skin v 1 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 1 and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-136/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/maven/myfaces-site-skin/1/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [DISCUSS] release of myfaces-test project
I agree, that this should not block us from releasing the bits. -Matthias On Mon, Aug 23, 2010 at 11:53 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Ok. The idea in the future is integrate that work, but for now that is not a stopper for a release. The plan from my side for the next weeks is do the following releases: - Myfaces Site Skin 1 - Myfaces Test 1.0.0 - Myfaces Core 2.0.2 - Tomahawk 1.1.10 regards, Leonardo Uribe 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi Leo, I would like to discuss the internal structure of the myfaces test project before we do a release of it, because I want to integrate the GSoC webapp-tests into our codebase. However this code is not ready for a release and should be an own module, independent from the current MyFaces test framework, but I would like to have both of them in the test directory in the svn. I will start a new thread about this integration! Regards, Jakob 2010/8/23 Leonardo Uribe lu4...@gmail.com Hi It could be good to do a release of myfaces test project after the release of myfaces site skin. Personally, I think the code is good for a release, but if someone has any objection about it, this is a good moment to say it. regards, Leonardo -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces site skin v 1
+1 LieGrue, strub From: Jan-Kees van Andel jankeesvanan...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, August 24, 2010 11:02:00 AM Subject: Re: [VOTE] release for myfaces site skin v 1 +1 Looks good. Regards, Jan-Kees 2010/8/24 Matthias Wessendorf mat...@apache.org +1 On Mon, Aug 23, 2010 at 10:46 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/8/23 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the version 1 release of Apache MyFaces Site Skin. This artifact is required to build the site of some myfaces projects. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven.myfaces-site-skin v 1 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 1 and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-136/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/maven/myfaces-site-skin/1/ / -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces site skin v 1
+1 Regards, Jakob 2010/8/24 Mark Struberg strub...@yahoo.de +1 LieGrue, strub From: Jan-Kees van Andel jankeesvanan...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, August 24, 2010 11:02:00 AM Subject: Re: [VOTE] release for myfaces site skin v 1 +1 Looks good. Regards, Jan-Kees 2010/8/24 Matthias Wessendorf mat...@apache.org +1 On Mon, Aug 23, 2010 at 10:46 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/8/23 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the version 1 release of Apache MyFaces Site Skin. This artifact is required to build the site of some myfaces projects. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven.myfaces-site-skin v 1 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 1 and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-136/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/maven/myfaces-site-skin/1/ / -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[DISCUSS] fading out the old snapshots repo
Hi folks! With the new apache parent, we also got a new snapshots repository. We now face the problem to have 2 apache-snapshots repositories which will not work without overriding the maven metainfo of each other. To work around those weird problems I usually have the following entry in my ~/.m2/settings.xml: mirrors mirror idnew.apache.snapshots/id namenew apache snapshots repository. We need this to skip the old ones/name urlhttp://repository.apache.org/snapshots/url mirrorOfapache.snapshots/mirrorOf /mirror /mirrors We should move over to the new snapshost-repo and then drop the old one completely. This will work as long as no pom is referenced which virulently pulls in the old snapshots repo. LieGrue, strub
Re: [DISCUSS] fading out the old snapshots repo
Hi Mark, +1 This means that we have to remove all snapshot-repo entries from our poms, right? Regards, Jakob 2010/8/24 Mark Struberg strub...@yahoo.de Hi folks! With the new apache parent, we also got a new snapshots repository. We now face the problem to have 2 apache-snapshots repositories which will not work without overriding the maven metainfo of each other. To work around those weird problems I usually have the following entry in my ~/.m2/settings.xml: mirrors mirror idnew.apache.snapshots/id namenew apache snapshots repository. We need this to skip the old ones/name urlhttp://repository.apache.org/snapshots/url mirrorOfapache.snapshots/mirrorOf /mirror /mirrors We should move over to the new snapshost-repo and then drop the old one completely. This will work as long as no pom is referenced which virulently pulls in the old snapshots repo. LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] fading out the old snapshots repo
+1 But if they don't share the same repository id, if you happened to have both snapshots repos in your POM file, the newer snapshot will be the one to be picked, no?. So as long as you add the new snapshot repository with a new id you should be safe. Of couse, to replace the old one would be recommended... Cheers, Bruno On 24 August 2010 10:18, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Mark, +1 This means that we have to remove all snapshot-repo entries from our poms, right? Regards, Jakob 2010/8/24 Mark Struberg strub...@yahoo.de Hi folks! With the new apache parent, we also got a new snapshots repository. We now face the problem to have 2 apache-snapshots repositories which will not work without overriding the maven metainfo of each other. To work around those weird problems I usually have the following entry in my ~/.m2/settings.xml: mirrors mirror idnew.apache.snapshots/id namenew apache snapshots repository. We need this to skip the old ones/name urlhttp://repository.apache.org/snapshots/url mirrorOfapache.snapshots/mirrorOf /mirror /mirrors We should move over to the new snapshost-repo and then drop the old one completely. This will work as long as no pom is referenced which virulently pulls in the old snapshots repo. LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] fading out the old snapshots repo
@Jakob: we should imo generally remove ALL repositories and distributionManagement repo settings (repos, NOT the sites!). All we need for doing a release is in apache-parent, and all other settings are most probably problematic if not broken. @Bruno: sadly the 2 repos both have the same id :( This was meant to provide a smooth migration but turned out to introduce problems with some maven versions if the snapshots are 'versioned' (automatically applying a timestamp). Thus my mirrorOf solution... LieGrue, strub From: Bruno Aranda brunoara...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, August 24, 2010 11:52:51 AM Subject: Re: [DISCUSS] fading out the old snapshots repo +1 But if they don't share the same repository id, if you happened to have both snapshots repos in your POM file, the newer snapshot will be the one to be picked, no?. So as long as you add the new snapshot repository with a new id you should be safe. Of couse, to replace the old one would be recommended... Cheers, Bruno On 24 August 2010 10:18, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Mark, +1 This means that we have to remove all snapshot-repo entries from our poms, right? Regards, Jakob 2010/8/24 Mark Struberg strub...@yahoo.de Hi folks! With the new apache parent, we also got a new snapshots repository. We now face the problem to have 2 apache-snapshots repositories which will not work without overriding the maven metainfo of each other. To work around those weird problems I usually have the following entry in my ~/.m2/settings.xml: mirrors mirror idnew.apache.snapshots/id namenew apache snapshots repository. We need this to skip the old ones/name urlhttp://repository.apache.org/snapshots/url mirrorOfapache.snapshots/mirrorOf /mirror /mirrors We should move over to the new snapshost-repo and then drop the old one completely. This will work as long as no pom is referenced which virulently pulls in the old snapshots repo. LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Resolved: (MYFACES-2891) Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping
[ https://issues.apache.org/jira/browse/MYFACES-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2891. Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed I changed the algorithm so that prefix is // if it would be an empty string. With this way we can prevent an infinite loop but still have the double slash prevention (actually even twice). Empty url mapping prefix causes infinite loop in DefaultViewHandlerSupport.handlePrefixMapping -- Key: MYFACES-2891 URL: https://issues.apache.org/jira/browse/MYFACES-2891 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Weblogic 10.3, Sun JAVA 1.6, Spring Framework 3.0.3, Spring Webflow 2.1.1 Reporter: Michal Dvorak Assignee: Jakob Korherr Fix For: 2.0.2-SNAPSHOT Original Estimate: 0.5h Remaining Estimate: 0.5h The loop while (uri.startsWith(prefix) || uri.startsWith(//)) ... cannot end when prefix is empty string (which should be valid value). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces site skin v 1
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/8/24 Jakob Korherr jakob.korh...@gmail.com +1 Regards, Jakob 2010/8/24 Mark Struberg strub...@yahoo.de +1 LieGrue, strub From: Jan-Kees van Andel jankeesvanan...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, August 24, 2010 11:02:00 AM Subject: Re: [VOTE] release for myfaces site skin v 1 +1 Looks good. Regards, Jan-Kees 2010/8/24 Matthias Wessendorf mat...@apache.org +1 On Mon, Aug 23, 2010 at 10:46 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/8/23 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the version 1 release of Apache MyFaces Site Skin. This artifact is required to build the site of some myfaces projects. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven.myfaces-site-skin v 1 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 1 and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-136/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/maven/myfaces-site-skin/1/ / -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (MYFACES-2892) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only --- Key: MYFACES-2892 URL: https://issues.apache.org/jira/browse/MYFACES-2892 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces trunk Reporter: Martin Kočí 11.1.3 Application Configuration Parameters: If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value Currently UIInput.validate applies it to every type of submittedValue, not only for String. If I use custom non-String submmited value with toString().length()=0 UIInput.validate turns it into null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2892) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only
[ https://issues.apache.org/jira/browse/MYFACES-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kočí updated MYFACES-2892: - Status: Patch Available (was: Open) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only --- Key: MYFACES-2892 URL: https://issues.apache.org/jira/browse/MYFACES-2892 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces trunk Reporter: Martin Kočí 11.1.3 Application Configuration Parameters: If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value Currently UIInput.validate applies it to every type of submittedValue, not only for String. If I use custom non-String submmited value with toString().length()=0 UIInput.validate turns it into null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2886) UIData: push and pop row component to and from EL during broadcast()
[ https://issues.apache.org/jira/browse/MYFACES-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2886: --- Status: Resolved (was: Patch Available) Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed fix + test case in place UIData: push and pop row component to and from EL during broadcast() Key: MYFACES-2886 URL: https://issues.apache.org/jira/browse/MYFACES-2886 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces trunk 2.0.2-SNAPSHOT Reporter: Martin Kočí Assignee: Jakob Korherr Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2886.patch UIData should push and pop row component in/from EL when brodcasting is performed. Currently this is omitted and when for example ActionEvent from a UICommand in UIData is delivered, CURRENT_COMPONENT is UIData but obviously it should be UICommand. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2892) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only
[ https://issues.apache.org/jira/browse/MYFACES-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901870#action_12901870 ] Matthias Weßendorf commented on MYFACES-2892: - thanks for the reminder - I have a similar fix on my machine, while fixing related issues from Trinidad ;-) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only --- Key: MYFACES-2892 URL: https://issues.apache.org/jira/browse/MYFACES-2892 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces trunk Reporter: Martin Kočí Assignee: Jakob Korherr Attachments: MYFACES-2892.patch 11.1.3 Application Configuration Parameters: If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value Currently UIInput.validate applies it to every type of submittedValue, not only for String. If I use custom non-String submmited value with toString().length()=0 UIInput.validate turns it into null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2839) cleanup of UIInput
[
https://issues.apache.org/jira/browse/MYFACES-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved MYFACES-2839.
-
Assignee: Matthias Weßendorf
Fix Version/s: 2.0.2-SNAPSHOT
Resolution: Fixed
cleanup of UIInput
--
Key: MYFACES-2839
URL: https://issues.apache.org/jira/browse/MYFACES-2839
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.0.1
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf
Priority: Minor
Fix For: 2.0.2-SNAPSHOT
looking at shouldValidateEmptyFields() I see this code:
...
ExternalContext extCtx = context.getExternalContext();
String validateEmptyFields = (String)
extCtx.getInitParameter(VALIDATE_EMPTY_FIELDS_PARAM_NAME);
if (validateEmptyFields == null)
{
validateEmptyFields = (String)
extCtx.getApplicationMap().get(VALIDATE_EMPTY_FIELDS_PARAM_NAME);
}
= Should be cached on application_map instead of always parsing the web.xml
(getInitParam())-
Actually I don't see a put to stored it on the applcaitonMap;
Inside of the validate() I see similar code:
String contextParam =
context.getExternalContext().getInitParameter(EMPTY_VALUES_AS_NULL_PARAM_NAME);
= not cached
Similar in the _ExternalSpecifications clazz, no cache maintained here
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2892) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only
[ https://issues.apache.org/jira/browse/MYFACES-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated MYFACES-2892: Status: Resolved (was: Patch Available) Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL applies for String only --- Key: MYFACES-2892 URL: https://issues.apache.org/jira/browse/MYFACES-2892 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces trunk Reporter: Martin Kočí Assignee: Matthias Weßendorf Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2892.patch 11.1.3 Application Configuration Parameters: If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value Currently UIInput.validate applies it to every type of submittedValue, not only for String. If I use custom non-String submmited value with toString().length()=0 UIInput.validate turns it into null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTVAL-115) Column of Trinidad table disappear
Column of Trinidad table disappear -- Key: EXTVAL-115 URL: https://issues.apache.org/jira/browse/EXTVAL-115 Project: MyFaces Extensions Validator Issue Type: Bug Affects Versions: 1.2.3 Environment: Ubuntu 10.04, Jetty 6.1.8 / Tomcat 6.0.26 Reporter: Walter Mourão When I add extval to a project using Trinidad, the first column of a tr:table disappear after the first line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Different settings for different ProjectStages
You're right, Gerhard. Furthermore we now have a spi package in impl (for the JBoss integration) and I think this is the best place to put it. I will open a JIRA issue, do some prototyping and provide a patch soon. Regards, Jakob 2010/8/13 Gerhard gerhard.petra...@gmail.com the mentioned approach is quite similar to your initial suggestion - it just uses different terms and you have one property per config entry (which allows to use it in a typesafe way). - if a manager impl. would be possible - this approach should be possible as well. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/8/13 Jakob Korherr jakob.korh...@gmail.com For this work properly we would have to provide an abstract config class, but we can only do that in myfaces-impl. However I think it's not a good idea to require myfaces-impl beeing a compile-dependency, impl should always be a runtime-dependency. Although I really like the idea of having a typesafe way of doing configuration, I think we can't/shouln't do this for MyFaces 2.0.x because of the aforementioned reasons. However we could raise a spec issue and ask the EG to think about it. Maybe we will get a javax.faces.config.AbstractConfig for 2.x. Regards, Jakob 2010/8/11 Gerhard gerhard.petra...@gmail.com i would prefer something like [1] it allows - a default implementation which could implement the mentioned behavior - a typesafe config regards, gerhard [1] http://home.base.be/vt692569/blogs/2010-07-13.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/8/11 Matthias Wessendorf mat...@apache.org On Wed, Aug 11, 2010 at 4:23 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi guys, Talking to some users of MyFaces, we found out that it would be really nice to be able to have web.xml-settings depending on the current project stage. For example you want to have different error pages for Development and Production. Imagine there is the config parameter org.apache.myfaces.MY_PARAM. Now you want to use 3 different values for this parameter, depending on the project stage. So you can set org.apache.myfaces.MY_PARAM.DEVELOPMENT for the development value, org.apache.myfaces.MY_PARAM.PRODUCTION for the production value and org.apache.myfaces.MY_PARAM for the default value (all other stages). I kinda like this fluent extension proposal. To accomplish this we could introduce a web.xml-settings manager, which handles this lookup. With the help of this manager we could get rid of the usual lookup via ExternalContext and use the manager instead. good idea. I hate the fact that you see over and over again the same calls. A unified manager that does that for you; and you just give it the param would be nice. What do you think? Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Resolved: (TRINIDAD-1884) Back port the Trinidad 2 visit tree changes into the 1.2 branch
[ https://issues.apache.org/jira/browse/TRINIDAD-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1884. --- Fix Version/s: 1.2.15-core Resolution: Fixed Back port the Trinidad 2 visit tree changes into the 1.2 branch --- Key: TRINIDAD-1884 URL: https://issues.apache.org/jira/browse/TRINIDAD-1884 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.12-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 1.2.15-core Quite a bit of work was done for the tree visiting support in the trunk branch, but the 1.2 branch lacks these changes. For the most part, these changes can be directly back ported from Trinidad 2 to 1.2 leveraging the APIs that Blake created for 1.2 tree visiting (like the VisitResult and VisitContext as examples). Without these changes, there are bugs that may be found in 1.2 if users begin to leverage tree visitation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-906) It should be possible to unselect a selected row in a selectable tc:sheet.
[ https://issues.apache.org/jira/browse/TOBAGO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901961#action_12901961 ] D. W. commented on TOBAGO-906: -- Thanks for your quick reaction and apologies for my late reply :) I agree, that it seems to be the default behavior in other user interfaces. However, I - personally - was never quite happy with such a behavior. Why should the user be able to select something, which he/she cannot unselect anymore. In the worst case, this is like a trap for the user, since once you made a selection among several items, you are stuck with the given options and have to select at least one. The same goes for the radio buttons. I guess this is also the reason, why you sometimes see a blank entry in a select box - exactly to give the user the chance to not select/unselect his choice. Having said this, I see four possible solutions: 1) Simply allow the user to unselect an item or the last remaining item. And don't change anything on the programmers side, i.e. in the tag definitions. This is against common user interface behavior, however with the reasons given above, I actually see an improvement in the user experience. 2) Implement your idea of a selectable=singleOrNone . Here the programmer can choose to allow or disallow unselecting an item or the last remaining item for a single select. 3) Instead of a new attribute value for selectable, add a new attribute unselectable which can be true or false. This would give a more consistent behavior w.r.t. multi select, because then the programmer can also enforce at least one selected item, once an item has been selected. 4) Replace all given values of attribute selectable and introduce the following ones: - zero (equal to none) - one (only one item can be selected; item cannot be unselected) - zeroOrOne (only one item can be selected; item can be unselected) - oneOrMore (mulitple items can be selected; last remaining item cannot be unselected) - zeroOrMore (multiple items can be selected; last remaining item can be unselected) I would go for the boldest approach in 1) or alternatively for the clearest + most customizable approach in 4). What do you think? Best wishes, dw It should be possible to unselect a selected row in a selectable tc:sheet. -- Key: TOBAGO-906 URL: https://issues.apache.org/jira/browse/TOBAGO-906 Project: MyFaces Tobago Issue Type: Improvement Components: Core Environment: e.g. in Firefox 3.6.8 Reporter: D. W. Priority: Minor Dear all, Given a tc:sheet is set to be selectable (selectable=single), then one can select the rows and the selected row is highlighted in some way. So far so good. Now, if the user wants to unselect this row, then there is no way to do this. This means the row remains selected and highlighted. However, I think the row should be unselected, when the user clicks on the highlighted row. Thanks for your feedback on this issue, D.W. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TOBAGO-906) It should be possible to unselect a selected row in a selectable tc:sheet.
[ https://issues.apache.org/jira/browse/TOBAGO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901961#action_12901961 ] D. W. edited comment on TOBAGO-906 at 8/24/10 12:51 PM: Thanks for your quick reaction and apologies for my late reply :) I agree, that it seems to be the default behavior in other user interfaces. However, I - personally - was never quite happy with such a behavior. Why should the user be able to select something, which he/she cannot unselect anymore. In the worst case, this is like a trap for the user, since once you made a selection among several items, you are stuck with the given options and have to select at least one. The same goes for the radio buttons. I guess this is also the reason, why you sometimes see a blank entry in a select box - exactly to give the user the chance to not select/unselect his choice. Having said this, I see four possible solutions: 1) Simply allow the user to unselect an item or the last remaining item. And don't change anything on the programmers side, i.e. in the tag definitions. This is against common user interface behavior, however with the reasons given above, I actually see an improvement in the user experience. 2) Implement your idea of a selectable=singleOrNone . Here the programmer can choose to allow or disallow unselecting an item or the last remaining item for a single select. 3) Instead of a new attribute value for selectable, add a new attribute unselectable which can be true or false. This would give a more consistent behavior w.r.t. multi select, because then the programmer can also enforce at least one selected item, once an item has been selected. 4) Replace all given values of attribute selectable and introduce the following ones: - zero (equal to none) - one (only one item can be selected; item cannot be unselected) - zeroOrOne (only one item can be selected; item can be unselected) - oneOrMore (mulitple items can be selected; last remaining item cannot be unselected) - zeroOrMore (multiple items can be selected; last remaining item can be unselected) This is also even more consistent compared to approach 3) because the theoretically possible combination of selectable=none and unselectable=true in 3) can't occur in 4) anymore. I would go for the boldest approach in 1) or alternatively for the clearest + most customizable approach in 4). What do you think? Best wishes, dw was (Author: dwtobago): Thanks for your quick reaction and apologies for my late reply :) I agree, that it seems to be the default behavior in other user interfaces. However, I - personally - was never quite happy with such a behavior. Why should the user be able to select something, which he/she cannot unselect anymore. In the worst case, this is like a trap for the user, since once you made a selection among several items, you are stuck with the given options and have to select at least one. The same goes for the radio buttons. I guess this is also the reason, why you sometimes see a blank entry in a select box - exactly to give the user the chance to not select/unselect his choice. Having said this, I see four possible solutions: 1) Simply allow the user to unselect an item or the last remaining item. And don't change anything on the programmers side, i.e. in the tag definitions. This is against common user interface behavior, however with the reasons given above, I actually see an improvement in the user experience. 2) Implement your idea of a selectable=singleOrNone . Here the programmer can choose to allow or disallow unselecting an item or the last remaining item for a single select. 3) Instead of a new attribute value for selectable, add a new attribute unselectable which can be true or false. This would give a more consistent behavior w.r.t. multi select, because then the programmer can also enforce at least one selected item, once an item has been selected. 4) Replace all given values of attribute selectable and introduce the following ones: - zero (equal to none) - one (only one item can be selected; item cannot be unselected) - zeroOrOne (only one item can be selected; item can be unselected) - oneOrMore (mulitple items can be selected; last remaining item cannot be unselected) - zeroOrMore (multiple items can be selected; last remaining item can be unselected) I would go for the boldest approach in 1) or alternatively for the clearest + most customizable approach in 4). What do you think? Best wishes, dw It should be possible to unselect a selected row in a selectable tc:sheet. -- Key: TOBAGO-906 URL: https://issues.apache.org/jira/browse/TOBAGO-906 Project: MyFaces Tobago Issue Type: Improvement Components: Core
evaluating JSR-303 @Size(max=) for input fields?
Hi! Not sure if this is covered in the spec, but wouldn't if be useful to parse for the JSR-303 Size annotation [1] and use this value for the maxlength attribute of h:inputText fields if nothing is manually specified in the xhtml? LieGrue, strub [1]http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html
Re: evaluating JSR-303 @Size(max=) for input fields?
Hi,
I tried it for my renderkit but unfortunately there is no (or I didn't
find) solution for scenario, where
value=#{bean.otherBean.constrainedProperty} and otherBean is null. In
such case you can only obtain constrains from declared type, not from
the real one.
But for simpler cases where value EL leads to property on non-null bean
it works fine and reduces duplicity of max length information. JPA
2.0 uses @Size for DB constraints too.
Regards,
Martin Kočí
Mark Struberg píše v Út 24. 08. 2010 v 20:41 +:
Hi!
Not sure if this is covered in the spec, but wouldn't if be useful to parse
for
the JSR-303 Size annotation [1] and use this value for the maxlength
attribute
of h:inputText fields if nothing is manually specified in the xhtml?
LieGrue,
strub
[1]http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html
Re: evaluating JSR-303 @Size(max=) for input fields?
hi, extval supports such features (see [1] - in this case you just have to switch to the bv-module - the rest works automatically). regards, gerhard [1] http://jsfcentral.com/articles/myfaces_extval_1.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/8/24 Mark Struberg strub...@yahoo.de Hi! Not sure if this is covered in the spec, but wouldn't if be useful to parse for the JSR-303 Size annotation [1] and use this value for the maxlength attribute of h:inputText fields if nothing is manually specified in the xhtml? LieGrue, strub [1] http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html
