[jira] Created: (MYFACES-2127) duplicated component id with any jsp:include (or other inclusion) of jsf pages
duplicated component id with any jsp:include (or other inclusion) of jsf pages -- Key: MYFACES-2127 URL: https://issues.apache.org/jira/browse/MYFACES-2127 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.5 Reporter: Paul Pogonyshev Any type of page inclusion seems to lead to duplicated component id and thus fails with MyFaces 1.2. E.g. something like this (with appropriate taglibs): outer.jsp: f:view jsp:include page=inner.jsp/ /f:view inner.jsp: h:inputText value=foo/ gives me error: java.lang.IllegalStateException - Client-id : j_id_id0 is duplicated in the faces tree. Component Both the outer view and the inner inputText are assigned the same id0 as jspId. However, documentation on setJspId on page http://java.sun.com/javaee/5/docs/api/javax/faces/webapp/UIComponentClassicTagBase.html#setJspId(java.lang.String), to which MyFaces sources refer, notes that: IMPLEMENTATION NOTE: This method will detect where we are in an include and assign a unique ID for each include in a particular 'logical page'. This allows us to avoid possible duplicate ID situations for included pages that have components without explicit IDs. This is not true for MyFaces, which renders code reusal (which jsp inclusion facilitates) impossible for this case. Or at least I don't see how to include pages without causing errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2100) unnecessary final methods in ApplicationImpl (maybe elsewhere too)
unnecessary final methods in ApplicationImpl (maybe elsewhere too) -- Key: MYFACES-2100 URL: https://issues.apache.org/jira/browse/MYFACES-2100 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.5 Reporter: Paul Pogonyshev Priority: Minor When trying to upgrade to MyFaces 1.2.5 from 1.1.5 I get several instances of 'overridden method is final' compilation errors for custom subclass of ApplicationImpl. E.g. I override createConverter() method to post-apply custom setters to results of super.createConverter(). Are there any good reasons these methods are now final? Because if this is not fixed (i.e. reverted to previous non-final methods) I will have to reimplement the whole Application class, which sure sucks a lot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2100) unnecessary final methods in ApplicationImpl (maybe elsewhere too)
[ https://issues.apache.org/jira/browse/MYFACES-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652712#action_12652712 ] Paul Pogonyshev commented on MYFACES-2100: -- Thanks for the quick reply. About wrapper: you are probably right, but it would be nice if there was a wrapper abstract class in impl, because Application interface is kinda large. Also, having one in the library itself would ease upgrades. With custom class, when upgrading, I'd have to add wrappers/delegates for all new methods. With library-provided class this would be automatic. About final: I'm not sure it gives any speed boost for virtual methods (i.e. in Java those you access without knowing exact class of an object). Though I admit I don't really know. unnecessary final methods in ApplicationImpl (maybe elsewhere too) -- Key: MYFACES-2100 URL: https://issues.apache.org/jira/browse/MYFACES-2100 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.5 Reporter: Paul Pogonyshev Priority: Minor When trying to upgrade to MyFaces 1.2.5 from 1.1.5 I get several instances of 'overridden method is final' compilation errors for custom subclass of ApplicationImpl. E.g. I override createConverter() method to post-apply custom setters to results of super.createConverter(). Are there any good reasons these methods are now final? Because if this is not fixed (i.e. reverted to previous non-final methods) I will have to reimplement the whole Application class, which sure sucks a lot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2001) wrong referenced scope test for managed beans with scope 'none'
wrong referenced scope test for managed beans with scope 'none' --- Key: MYFACES-2001 URL: https://issues.apache.org/jira/browse/MYFACES-2001 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.4, 1.2.3, 1.2.2, 1.2.0, 1.1.6, 1.1.5 Reporter: Paul Pogonyshev I get the following exception: Property space references object in a scope with shorter lifetime than the target scope none for a managed bean with scope 'none'. It sets a property to a bean in request scope. However, request scope lifetime should not be viewed as 'shorter' than 'none'. This is observed on 1.1.5, but quick check suggests that relevant source code part is the same in SVN trunk. As I see, check in isInValidScope() is incorrect for cases when targetScope is null or 'none'. In this case it should always return true regardless of valueScope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1225) JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData
[ https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563972#action_12563972 ] Paul Pogonyshev commented on MYFACES-1225: -- Yes, indeed. However, I checked out sources trunk -- private. Checked out branches/1_2_2 --- no UIData at all... It seems I completely misunderstand MyFaces SVN. Is https://svn.apache.org/repos/asf/myfaces/core/trunk a valid URL for trunk at all? JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData --- Key: MYFACES-1225 URL: https://issues.apache.org/jira/browse/MYFACES-1225 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Assignee: Dennis Byrne Enabled protected access to internal DataModel in UIData See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=58 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1225) JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData
[ https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563986#action_12563986 ] Paul Pogonyshev commented on MYFACES-1225: -- Thank you, now I see that getDataModel() is indeed protected in 1.2. I wish that createDataModel() was protected too, but that's not such a problem: it is used only from getDataModel() once and getDataModel() is 10 lines of overridable code. I cannot wrap original createDataModel() though, but anyway, now some meaningful changes are possible without major code duplication as with 1.1. JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData --- Key: MYFACES-1225 URL: https://issues.apache.org/jira/browse/MYFACES-1225 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Assignee: Dennis Byrne Enabled protected access to internal DataModel in UIData See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=58 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1225) JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData
[ https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563607#action_12563607 ] Paul Pogonyshev commented on MYFACES-1225: -- I dont't understand. It was private and is private in SVN. What has changed? I stumbled into it after I derived right from UIData: cannot play around with createDataModel, while I could with a custom Tomahawk table derivative. Apparently, Tomahawk uses some hack class. And Tomahawk's wish to have access to getDataModel() etc. is not Tomahawk-specific, I want to do the same... JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData --- Key: MYFACES-1225 URL: https://issues.apache.org/jira/browse/MYFACES-1225 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Assignee: Dennis Byrne Enabled protected access to internal DataModel in UIData See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=58 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1150) t:columns sortable=true ... fails with an exception
t:columns sortable=true ... fails with an exception --- Key: TOMAHAWK-1150 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1150 Project: MyFaces Tomahawk Issue Type: Bug Components: Columns Affects Versions: 1.1.5 Reporter: Paul Pogonyshev Attachments: columns-fix.diff Here is the exception: java.lang.IllegalArgumentException: Component property sortable is not writable. Judging by the trunk, it happens with the trunk too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1150) t:columns sortable=true ... fails with an exception
[ https://issues.apache.org/jira/browse/TOMAHAWK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Pogonyshev updated TOMAHAWK-1150: -- Status: Patch Available (was: Open) t:columns sortable=true ... fails with an exception --- Key: TOMAHAWK-1150 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1150 Project: MyFaces Tomahawk Issue Type: Bug Components: Columns Affects Versions: 1.1.5 Reporter: Paul Pogonyshev Attachments: columns-fix.diff Here is the exception: java.lang.IllegalArgumentException: Component property sortable is not writable. Judging by the trunk, it happens with the trunk too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1165) Properties for Converters by class instead of by id
[ https://issues.apache.org/jira/browse/MYFACES-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526397 ] Paul Pogonyshev commented on MYFACES-1165: -- Regardless of whether it is in JSF specification, it is supported by MyFaces: converter converter-idformat-post-id/converter-id converter-classcom.enw.myfaces.converter.ObjectIdConverter/converter-class property property-nametype/property-name property-classjava.lang.String/property-class default-valuepost/default-value /property /converter This works fine as long as I don't create two converters using the same class. Current MyFaces behaviour is completely non-intuitive and therefore a bug. I registered this way two converters from the same class, but with different type property and later couldn't understand why using the right converter gave me an exception. Turned out, MyFaces used configuration for a _different_ converter with the same class. Properties for Converters by class instead of by id --- Key: MYFACES-1165 URL: https://issues.apache.org/jira/browse/MYFACES-1165 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.1 Reporter: Bjarne Hansen Priority: Minor When a converter is created it has its properties set from the configuration by converter class and not by converter id. This means that it is not possible to have different converters (id) implemented by the same class with different configurations specified in the faces configuration file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-902) Bug in DefaultAddResource. Resources added AddResource.BODY_END are rendered in the page header
[
https://issues.apache.org/jira/browse/TOMAHAWK-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Pogonyshev updated TOMAHAWK-902:
-
Status: Patch Available (was: Open)
Bug in DefaultAddResource. Resources added AddResource.BODY_END are rendered
in the page header
---
Key: TOMAHAWK-902
URL: https://issues.apache.org/jira/browse/TOMAHAWK-902
Project: MyFaces Tomahawk
Issue Type: Bug
Components: ExtensionsFilter
Affects Versions: 1.1.3
Reporter: David Turner
Resources added with a position of AddResource.BODY_END are rendered in the
page header not at body end.
In DefaultAddResource.writeWithFullHeader:724:
if (afterBodyContentInsertPosition = 0)
{
...
originalResponse.insert(headerInsertPosition,
writerWrapper.toString());
}
Shouldn't this be:
if (afterBodyContentInsertPosition = 0)
{
...
originalResponse.insert(afterBodyContentInsertPosition,
writerWrapper.toString());
}
Workaround:
Write your own AddResource implementation (just copy the
DefaultAddResource); include this fix; override default in web.xml with:
context-param
param-nameorg.apache.myfaces.ADD_RESOURCE_CLASS/param-name
param-valueau.com.project.common.ui.renderkit.html.util.DefaultAddResource/param-value
descriptionOverride default resource handler (extensions
filter)/description
/context-param
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-186) inputCalendar - how to change the first day of week
[ https://issues.apache.org/jira/browse/TOMAHAWK-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462253 ] Paul Pogonyshev commented on TOMAHAWK-186: -- Set `locale' attribute on f:view tag. inputCalendar - how to change the first day of week --- Key: TOMAHAWK-186 URL: https://issues.apache.org/jira/browse/TOMAHAWK-186 Project: MyFaces Tomahawk Issue Type: New Feature Components: Calendar Reporter: Rumiana Panova How can I change the first day of week from Sunday to Monday in the inputCalendar ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-842) popup is active for disabled calendar components
popup is active for disabled calendar components Key: TOMAHAWK-842 URL: https://issues.apache.org/jira/browse/TOMAHAWK-842 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.3 Reporter: Paul Pogonyshev Priority: Minor When the calendar is disabled, its text entry is rendered as inacessible to user (correct), but calendar popup can still be opened and operated (incorrect.) This should be easily fixable by adding a check for disabled text entry into _popUpCalendar() JavaScript function. I.e. if entry is disabled, don't show popup in any case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12460203 ] Paul Pogonyshev commented on MYFACES-1396: -- I don't actively see it anywhere. However, I did see it in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl constructor and it caused all non-ASCII characters be replaced with HTML entities. The entities were also seen by my work neighbor and my client, but AFAIK we all use Firefox. And replacing UTF8 string with UTF-8 in this function did solve the problem, so it was indeed a (non-direct) cause. I suggest that you try the small test page I attached. You can also make it available somewhere on a (test) MyFaces server and then I can test it with my browser. I searched the whole source tree for UTF8 again. It is not present in any configuration, Java or JSP/JSF files except in Java comments on few occasions. And in local copy of HtmlResponseWriterImpl.java, of course. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12460214 ] Paul Pogonyshev commented on MYFACES-1396: -- Paul: sorry, no, it is not needed. Just accidentally left from a real page. Tomas: yes, I started a somewhat different discussion, but I believe your problem is caused by UTF-8 characters replaced with HTML entities due to charset being UTF8, not UTF-8. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459919 ] Paul Pogonyshev commented on MYFACES-1396: -- I have fixed this locally since we have a release soon and it is not fixed in upstream (stable) versions. I spent 1.5 (!) days debugging stuff. It all went down to UTF-8 charset suddenly spelled as UTF8 (while it was with hyphen at earlier stages.) I have no idea why the change happened, I just fixed it by converting UTF8 to UTF-8 in HtmlResponseWriterImpl class. BTW, you have a really weird package structure. For some reason, there is a shared_tomahawk package, but it seems identical to shared_impl and even not present in the sources. This made my debugging three times longer than it could be... Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459944 ] Paul Pogonyshev commented on MYFACES-1424: -- Is that really so hard to fix? Popcorn: that command doesn't work either. Incorrect source repository commands Key: MYFACES-1424 URL: http://issues.apache.org/jira/browse/MYFACES-1424 Project: MyFaces Core Issue Type: Bug Components: website Reporter: Popcorn Priority: Critical On the website on the page http://myfaces.apache.org/source-repository.html, the source repository commands have the following URL: http://svn.apache.org/repos/asf/myfaces/site/trunk This doesn't point to the MyFaces source code. It needs to be fixed. I cannot figure out which path I should get source from for the current release. For example it says: The source can be checked out anonymously from SVN with this command: $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459946 ] Paul Pogonyshev commented on MYFACES-1396: -- I didn't create a patch since I didn't feel it is a proper fix for upstream version. And now I can't create one since SVN checkout commands on your site are broken. Anyway, let me describe it in more words: - when instance of org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl is created (note: shared_tomahawk, not shared_impl!), it is passed UTF8, without hyphen, as `characterEncoding'; - in all (or at least all relevant) cases before, charset is UTF-8, with hyphen, as expected; in particular this is true for org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl (note: shared_impl, not shared_tomahawk); - I fixed it by converting UTF8 string to UTF-8 in HtmlResponseWriterImpl constructor; - a proper fix would be find out why charset becomes UTF8, without hyphen, in the first place; ad-hoc fix above could be included too, as a way to make HtmlResponseWriterImpl more robust. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459948 ] Paul Pogonyshev commented on MYFACES-1396: -- Eh, I meant org.apache.myfaces.shared_impl.renderkit.html.HtmlResponseWriterImpl for the second list item. Anyway, that is mentioned in parenthesis. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459975 ] Paul Pogonyshev commented on MYFACES-1396: -- Note from the code, there's nothing like that (I actually grepped all source tree.) It may get it from the browser, I don't know. However, in this case it is very wrong: 1) at least MyFaces must handle UTF8 just like UTF-8; 2) browser must not determine encoding of pages, since it is impossible to reencode pages robustly; in particular, inserting HTML entities into unsuspecting JavaScript (as in my case) will break things. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459981 ] Paul Pogonyshev commented on MYFACES-1396: -- 1) No. I'm too tired now to find how to do it. 2) Firefox 2.0. 3) English (US). Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459986 ] Paul Pogonyshev commented on MYFACES-1396: -- And let me clarify why I think browser should have absolutely no saying in the a resulting encoding. Nowadays all browser should be able to handle any encoding just fine, as long as it is state in HTML page header. If a browser fails to handle a particular encoding, you should upgrade it, else throw it away. _Nothing_ I know of can reencode pages on the fly, so MyFaces seems to invent a wheel that is absolutely unneeded. In fact you seem to encourage browser behaviour which will not work with other server-side solutions, especially if a server just contains a number of static HTMLs. I can also confirm that it works perfectly without reencoding in JSP parts of the site. Too much escaping - Key: MYFACES-1396 URL: http://issues.apache.org/jira/browse/MYFACES-1396 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Tomas Fischer Assigned To: Martin Marinschek Priority: Blocker Attachments: test.jsf HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid charactres (like , , ), but also german umlauts. This is OK if generating (X)HTML, but not OK if generating XML. However, according to the official documentation to the outputText Tag the german umlauts should not be quoted: If the escape attribute is not present, or it is present and its value is true all angle brackets should be converted to the ampersand xx semicolon syntax when rendering the value of the value attribute as the value of the component. There is an automatic XML detection, but this is broken, as only predefined MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). This bug prevents using JSF for generating other content (e.g. SVG, MIME-type image/svg+xml). -- 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-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459991 ] Paul Pogonyshev commented on MYFACES-1424: -- Uh, sorry. Seems working, just my SVN build doesn't support SSL. Incorrect source repository commands Key: MYFACES-1424 URL: http://issues.apache.org/jira/browse/MYFACES-1424 Project: MyFaces Core Issue Type: Bug Components: website Reporter: Popcorn Priority: Critical On the website on the page http://myfaces.apache.org/source-repository.html, the source repository commands have the following URL: http://svn.apache.org/repos/asf/myfaces/site/trunk This doesn't point to the MyFaces source code. It needs to be fixed. I cannot figure out which path I should get source from for the current release. For example it says: The source can be checked out anonymously from SVN with this command: $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces -- 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-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459995 ] Paul Pogonyshev commented on MYFACES-1424: -- Well, OK, but I guess 99% of interested people are interested in the source code of MyFaces, not of its site... Incorrect source repository commands Key: MYFACES-1424 URL: http://issues.apache.org/jira/browse/MYFACES-1424 Project: MyFaces Core Issue Type: Bug Components: website Reporter: Popcorn Priority: Critical On the website on the page http://myfaces.apache.org/source-repository.html, the source repository commands have the following URL: http://svn.apache.org/repos/asf/myfaces/site/trunk This doesn't point to the MyFaces source code. It needs to be fixed. I cannot figure out which path I should get source from for the current release. For example it says: The source can be checked out anonymously from SVN with this command: $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces -- 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] Resolved: (TOMAHAWK-757) date chooser popup should be able to start with Monday, not only with Sunday
[ http://issues.apache.org/jira/browse/TOMAHAWK-757?page=all ] Paul Pogonyshev resolved TOMAHAWK-757. -- Resolution: Invalid It is already possible by specifying locale. date chooser popup should be able to start with Monday, not only with Sunday Key: TOMAHAWK-757 URL: http://issues.apache.org/jira/browse/TOMAHAWK-757 Project: MyFaces Tomahawk Issue Type: New Feature Components: Calendar Affects Versions: 1.1.3 Reporter: Paul Pogonyshev Priority: Minor In many locales weeks start with Monday, not with Sunday. It should be possible to set up date chooser to show weeks like that, not only with Sunday first. In case this is already implemented, it would be good to include in the example. -- 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] Updated: (TOMAHAWK-530) imageLocation of inputCalendar does not work
[ http://issues.apache.org/jira/browse/TOMAHAWK-530?page=all ] Paul Pogonyshev updated TOMAHAWK-530: - Status: Patch Available (was: Open) imageLocation of inputCalendar does not work Key: TOMAHAWK-530 URL: http://issues.apache.org/jira/browse/TOMAHAWK-530 Project: MyFaces Tomahawk Issue Type: Bug Components: Calendar Affects Versions: 1.1.3 Reporter: Holger Schimanski Setting e.g. imageLocation=images/calendar has no effect. Images are still loaded from Extension Filter and not from the URL, which is set in imageLocation. -- 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
