[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584253#comment-13584253 ] Endolf commented on SLING-2536: --- The problem is that there is no bundle for sv, so you get the default, which might be en, yet getLocale() return sv, which is wrong and not what the contract of the method says it should do. We worked around it by having a key in all our bundles that have the language for that bundle in it, so we could get the language code another way and then look up the correct locale, but this is not the right way to do it. JcrResourceBundle breaks the contract of getLocale -- Key: SLING-2536 URL: https://issues.apache.org/jira/browse/SLING-2536 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.2.2 Reporter: Endolf The javadoc for getLocale state that it should return the locale of this bundle or the locale of the fallback. Currently JcrResourceBundle always returns the requested locale even if there is no mix:language for that locale. e.g. Only a mix:language with a jcr:language en is in the jcr, a request for a resource bundle of sv will return a ResourceBundle object where getLocale returns sv. This should return en according to the javadoc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421262#comment-13421262 ] Endolf commented on SLING-2536: --- That doesn't appear to be how it is working. I only have english bundle installed, I set my browser language to only allow zh-hk, hong kong chinese, I can see that my Accept-Langauge in the request headers only contains that language. Sling is set to default to english. The response contains a content-language header of zh-hk, all the properties are resolved to their english values, not the keys. JcrResourceBundle breaks the contract of getLocale -- Key: SLING-2536 URL: https://issues.apache.org/jira/browse/SLING-2536 Project: Sling Issue Type: Bug Affects Versions: i18n 2.2.2 Reporter: Endolf The javadoc for getLocale state that it should return the locale of this bundle or the locale of the fallback. Currently JcrResourceBundle always returns the requested locale even if there is no mix:language for that locale. e.g. Only a mix:language with a jcr:language en is in the jcr, a request for a resource bundle of sv will return a ResourceBundle object where getLocale returns sv. This should return en according to the javadoc. -- 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] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421288#comment-13421288 ] Endolf commented on SLING-2536: --- If I choose sv, or any of it's variations and have the sv bundle in the repository it resolves that fine from just the accept-language header. JcrResourceBundle breaks the contract of getLocale -- Key: SLING-2536 URL: https://issues.apache.org/jira/browse/SLING-2536 Project: Sling Issue Type: Bug Affects Versions: i18n 2.2.2 Reporter: Endolf The javadoc for getLocale state that it should return the locale of this bundle or the locale of the fallback. Currently JcrResourceBundle always returns the requested locale even if there is no mix:language for that locale. e.g. Only a mix:language with a jcr:language en is in the jcr, a request for a resource bundle of sv will return a ResourceBundle object where getLocale returns sv. This should return en according to the javadoc. -- 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] [Commented] (SLING-2536) JcrResourceBundle breaks the contract of getLocale
[ https://issues.apache.org/jira/browse/SLING-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421396#comment-13421396 ] Endolf commented on SLING-2536: --- getLocale() always returns the locale that was asked for, even when it's fallen back to something else. I can't paste the code in here, but here is what I've done. I've extended the SetBundleTag from the standard el tag library, in the doEndTag I get the locale from the request from pageContext, then I get the request, cast to a SlingHttpServletRequest and call the getResourceBundle method passing in the bundle basename and the locale I just got from the request. I think store that in javax.servlet.jsp.jstl.fmt.localizationContext in page context so that the standard fmt tags can use the bundle. We then just use the standard tags to access the bundle as we would in any other j2ee app. JcrResourceBundle breaks the contract of getLocale -- Key: SLING-2536 URL: https://issues.apache.org/jira/browse/SLING-2536 Project: Sling Issue Type: Bug Affects Versions: i18n 2.2.2 Reporter: Endolf The javadoc for getLocale state that it should return the locale of this bundle or the locale of the fallback. Currently JcrResourceBundle always returns the requested locale even if there is no mix:language for that locale. e.g. Only a mix:language with a jcr:language en is in the jcr, a request for a resource bundle of sv will return a ResourceBundle object where getLocale returns sv. This should return en according to the javadoc. -- 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] [Commented] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416930#comment-13416930 ] Endolf commented on SLING-2534: --- I had the same thought, sounds like a plan to me then. Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf Attachments: blankstrings.patch According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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] (SLING-2534) Strings of zero length on update in post servlet delete the property
Endolf created SLING-2534: - Summary: Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. String properties with a zero length should be blanked instead of deleted. -- 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] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Endolf updated SLING-2534: -- Description: According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. (was: According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. String properties with a zero length should be blanked instead of deleted.) Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Endolf updated SLING-2534: -- Attachment: blankstrings.patch I have tested this (but not very thoroughly) for string properties as this has the behaviour we expect in our application. Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf Attachments: blankstrings.patch According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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] (SLING-2536) JcrResourceBundle breaks the contract of getLocale
Endolf created SLING-2536: - Summary: JcrResourceBundle breaks the contract of getLocale Key: SLING-2536 URL: https://issues.apache.org/jira/browse/SLING-2536 Project: Sling Issue Type: Bug Affects Versions: i18n 2.2.2 Reporter: Endolf The javadoc for getLocale state that it should return the locale of this bundle or the locale of the fallback. Currently JcrResourceBundle always returns the requested locale even if there is no mix:language for that locale. e.g. Only a mix:language with a jcr:language en is in the jcr, a request for a resource bundle of sv will return a ResourceBundle object where getLocale returns sv. This should return en according to the javadoc. -- 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] [Commented] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416281#comment-13416281 ] Endolf commented on SLING-2534: --- That parameter would be problematic as this is only valid for strings, all other types cannot have no value. Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf Attachments: blankstrings.patch According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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] [Comment Edited] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416390#comment-13416390 ] Endolf edited comment on SLING-2534 at 7/17/12 5:39 PM: Just have the global parameter as defaulted to the existing behaviour. was (Author: endolf): Just have the parameter as defaulted to the existing behaviour?. Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf Attachments: blankstrings.patch According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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] [Commented] (SLING-2534) Strings of zero length on update in post servlet delete the property
[ https://issues.apache.org/jira/browse/SLING-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416390#comment-13416390 ] Endolf commented on SLING-2534: --- Just have the parameter as defaulted to the existing behaviour?. Strings of zero length on update in post servlet delete the property Key: SLING-2534 URL: https://issues.apache.org/jira/browse/SLING-2534 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Endolf Attachments: blankstrings.patch According to JCR specs, for string type properties, a blank string should be a valid value. Currently the post servlet delets any property where 1 or less values are specifed and the 1 value has a 0 length. I think string properties with a zero length should be blanked instead of deleted. -- 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
