[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Matthew Farwell updated JBIDE-9357: ----------------------------------- Attachment: jboss-foo.properties-properties.png jboss-plugins.png -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen updated JBIDE-9357: --------------------------------------- Fix Version/s: 3.3.0.M3 3.3.0.Beta1 Assignee: Alexey Kazakov (was: Max Rydahl Andersen) Matthew - btw. afaik we simply only rewrite the entries that gets edited - thats why you only see it partially. and afaik we rewrite the entries according to the encoding so not sure what is going on here (beyond limitations in your spring resource loader?) Alexey - you recall the conclusion made last time with respect to encoding and why we can't retain the used characters? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Matthew Farwell commented on JBIDE-9357: ---------------------------------------- I've attached my file. My Spring Resource loader doesn't cope well with \u escapes, but this is a separate issue. Please note that in the above scenario, I'm not actually changing anything. The file is being displayed differently, and if I subsequently change a line (any line, including other lines), there the file will be saved with the \u escapes. After further investigation, if there is a space at the end of the line, then the value in the properties changes. Try foobar1=fédéral<space> foobar2=fédéral Obviously replacing <space> by " " After closing & reopening the file, you get foobar1=f\u00E9d\u00E9ral foobar2=fédéral -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Viacheslav Kabanovich commented on JBIDE-9357: ---------------------------------------------- The effect of the last space character is a bug and should be fixed. Should we do more? Now, until user touches property 'foobar=fédéral', it remains as is. If he modifies it in editor to e.g. 'foobar=Fédéral' we rewrite it as 'foobar=F\u009Ed\u009Eral' - that is correct, but evidently not everyone likes it. Should we never convert characters in the range 128-255 if original property file contains at least one of them in entries? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Matthew Farwell commented on JBIDE-9357: ---------------------------------------- Just to clarify, there is no automatic save on closing or opening the editor. The contents don't change on the disk unless I click on Save. However, it does display the text in its converted form, whether or not I save it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-9357: -------------------------------------------- Matthew - I haven't tested this but seems like you simply need to explicitly state UTF-8 encoding for the spring class ? See http://www.cakesolutions.net/teamblogs/2009/04/02/utf-8-encoding-and-mess... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Viacheslav Kabanovich commented on JBIDE-9357: ---------------------------------------------- I have studied description of UTF-8. Only ASCII characters 0..127 should be encoded with 1 byte, other characters should be encoded with sequences of 2, 3, or 4 bytes, each byte in sequence belongs to range 128..255. The Unicode Standard requires decoders to "...treat any ill-formed code unit sequence as an error condition. This guarantees that it will neither interpret nor emit an ill-formed code unit sequence." However, some decoder implementations try to resolve invalid byte sequences, for example in case of 'fédéral' separate byte 'é' can be treated as one-byte character, because it cannot occur separately in a well formed UTF-8 text. But there must be a lot of words that cannot be resolved unambiguously, and I think that we should not support any kind of resolution algorithms, neither of them being recommended by the Unicode Standard. We read file content with standard Java readers, and parse properties with algorithm implemented in java.util.Properties. If it understands 'é' in 'fédéral' - very good, but we should not do anything to 'improve' that. In the same way, to serialize properties we use algorithm implemented in java.util.Properties, if it would not save 'é' as 'é' but as '\u00E9' - we should not 'improve' it to generate invalid byte sequences. All we can do and are doing now is to check that some property has not been touched in UI editor and so may be left as is. Our algorithm for checking if a property has been touched had a bug that is covered by the description. That bug fixed, our editor - will not modify file when open/closed; - will not interfere with any changes made in Source tab; - will only rewrite entries explicitly edited in Properties tab - but in this case it will use the standard algorithm so that any 'é' will turn into '\u00E9'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-9357: -------------------------------------------- Sounds good to me too. Can't work around other utf en/decoder bugs which are actually fixed in future revs of spring afaics. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9357?page=com.atlassian.jira.plugin... ] Pavol Srna commented on JBIDE-9357: ----------------------------------- Verified on jbdevstudio-product-linux-gtk-5.0.0.v201109071858R-H28-M3. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira