[jira] Closed: (MYFACES-1079) The page rendere a 'null' string at bottom of all pages.
[ http://issues.apache.org/jira/browse/MYFACES-1079?page=all ] Bruno Aranda closed MYFACES-1079: - Fix Version: Nightly Resolution: Fixed That should be fixed in the SVN now and available in the next nightly build. Thanks for reporting! The page rendere a 'null' string at bottom of all pages. Key: MYFACES-1079 URL: http://issues.apache.org/jira/browse/MYFACES-1079 Project: MyFaces Type: Bug Versions: Nightly Environment: JDeveloper project, with Myfaces Extension Filter configured, myfaces componentes of nigthly buid of 30 january. Reporter: Eduardo Ivan Pichler Assignee: Bruno Aranda Fix For: Nightly My project use the jscookMenu, then when I just configured the MyFaces Extension Filter, is rendered a 'null' string at bottom of all pages right before the /body tag, like this null/body Martin Marinschek [EMAIL PROTECTED] tell me to report this issue and warning and assign Bruno Aranda about it... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-837) WelcomeFileFilter wants to go to the internet to load web.xml DTD
[ http://issues.apache.org/jira/browse/MYFACES-837?page=comments#action_12365187 ] Dennis Byrne commented on MYFACES-837: -- Is there any reason why you can't use a DOCTYPE element, w/ public/system identifiers, or xsi:schemaLocation ? I agree there is no need for MyFaces to be validating, as the container already does this. WelcomeFileFilter wants to go to the internet to load web.xml DTD - Key: MYFACES-837 URL: http://issues.apache.org/jira/browse/MYFACES-837 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.2, 1.1.1 Reporter: Henning Schmiedehausen The WelcomeFileFilter loads the webapp web.xml to parse the web.xml file for welcome files (see WelcomeFileFilter, line 180). However as most web.xml files contain a DTD definition, it tries to download these from the web. If the webapp can't reach the internet (firewall, no network connection), the filter fails (in my case with an UnknownHostException). IMHO, if the filter insists on parsing the web.xml, it should either be able to resolve the most common DTDs (web-app_2_2.dtd, 2_3.dtd, 2_4.dtd probaby) locally or not use a validating parser (setValidating(false) in line 181)) so that it is possible to use the WelcomeFileFilter on hosts that cannot reach the internet. The bug is still present in the current impl trunk at http://svn.apache.org/viewcvs.cgi/myfaces/impl/trunk/src/java/org/apache/myfaces/webapp/filter/WelcomeFileFilter.java?rev=193014view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-837) WelcomeFileFilter wants to go to the internet to load web.xml DTD
[ http://issues.apache.org/jira/browse/MYFACES-837?page=comments#action_12365188 ] Martin Marinschek commented on MYFACES-837: --- +1 for changing to non-validating parsing. regards, Martin WelcomeFileFilter wants to go to the internet to load web.xml DTD - Key: MYFACES-837 URL: http://issues.apache.org/jira/browse/MYFACES-837 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.2, 1.1.1 Reporter: Henning Schmiedehausen The WelcomeFileFilter loads the webapp web.xml to parse the web.xml file for welcome files (see WelcomeFileFilter, line 180). However as most web.xml files contain a DTD definition, it tries to download these from the web. If the webapp can't reach the internet (firewall, no network connection), the filter fails (in my case with an UnknownHostException). IMHO, if the filter insists on parsing the web.xml, it should either be able to resolve the most common DTDs (web-app_2_2.dtd, 2_3.dtd, 2_4.dtd probaby) locally or not use a validating parser (setValidating(false) in line 181)) so that it is possible to use the WelcomeFileFilter on hosts that cannot reach the internet. The bug is still present in the current impl trunk at http://svn.apache.org/viewcvs.cgi/myfaces/impl/trunk/src/java/org/apache/myfaces/webapp/filter/WelcomeFileFilter.java?rev=193014view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-837) WelcomeFileFilter wants to go to the internet to load web.xml DTD
[ http://issues.apache.org/jira/browse/MYFACES-837?page=all ] Dennis Byrne closed MYFACES-837: Resolution: Fixed Assign To: Dennis Byrne Done. BTW, shoudn't WelcomeFileFilter, WelcomeFileHandler and JavaScriptDetectorFilter all be under tomahawk, instead of core/impl ? WelcomeFileFilter wants to go to the internet to load web.xml DTD - Key: MYFACES-837 URL: http://issues.apache.org/jira/browse/MYFACES-837 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.2, 1.1.1 Reporter: Henning Schmiedehausen Assignee: Dennis Byrne The WelcomeFileFilter loads the webapp web.xml to parse the web.xml file for welcome files (see WelcomeFileFilter, line 180). However as most web.xml files contain a DTD definition, it tries to download these from the web. If the webapp can't reach the internet (firewall, no network connection), the filter fails (in my case with an UnknownHostException). IMHO, if the filter insists on parsing the web.xml, it should either be able to resolve the most common DTDs (web-app_2_2.dtd, 2_3.dtd, 2_4.dtd probaby) locally or not use a validating parser (setValidating(false) in line 181)) so that it is possible to use the WelcomeFileFilter on hosts that cannot reach the internet. The bug is still present in the current impl trunk at http://svn.apache.org/viewcvs.cgi/myfaces/impl/trunk/src/java/org/apache/myfaces/webapp/filter/WelcomeFileFilter.java?rev=193014view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1092) HtmlTableRendererBase.encodeInnerHtml() fails when data model returns -1 for getRowCount()
HtmlTableRendererBase.encodeInnerHtml() fails when data model returns -1 for
getRowCount()
--
Key: MYFACES-1092
URL: http://issues.apache.org/jira/browse/MYFACES-1092
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.1
Reporter: Craig McClanahan
Per the JSF spec, ResultSetDataModel.getRowCount() returns -1, to avoid the
potential of scrolling through a very large result set to find the number of
rows. This means that components that might be bound to such a result set
(such as the value property on an HtmlDataTable component) must take into
account that they might get a -1 back when asking for the row count.
The logic in the encodeInnerHtml() method of HtmlTableRendererBase fails to
account for this possibility in the calculation of the last index to be
rendered, and causes zero rows to be printed in a scenario where the table
component is bound directly to a ResultSetDataModel, no matter how many rows
the result set actually returns. For example:
h:dataTable ... value=#{mybean.rsdm} var=current .../
where the rsdm property is a ResultSetDataModel that wraps a ResultSet that
returns a non-zero number of rows. This scenario works correctly with the JSF
RI implementation.
For example apps that illustrate this, check the SQL Browser example in Shale,
or the UIData example from the JSF RI's standard demo application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-775) Exception in inputDate
[ http://issues.apache.org/jira/browse/MYFACES-775?page=all ] Bruno Aranda closed MYFACES-775: Fix Version: Nightly Resolution: Fixed I see the patch is already applied Exception in inputDate -- Key: MYFACES-775 URL: http://issues.apache.org/jira/browse/MYFACES-775 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1 Environment: myfaces-api.jar, myfaces-impl.jar, tomahawk.jar Reporter: Kristina Feldmann Fix For: Nightly Attachments: HtmlInputDate.diff There is a NumberFormatException if a InputField is empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1093) Calendar when not using popup, clicking on a date returns the day before
Calendar when not using popup, clicking on a date returns the day before Key: MYFACES-1093 URL: http://issues.apache.org/jira/browse/MYFACES-1093 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Bruno Aranda When clicking on a static calendar (not the one rendered on a popup with javascript) it returns the wrong date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
TLDs gone
Can one of the more maven knowledgeable persons please look into why the TLDs are no longer in the impl jar? Dennis Byrne
