Escaping single backslashes is probably not a good idea. What if I
want to pass in (for some obscure reason) a \n ? I'd expect this to
be translated to a new line, not the string "\\n".
I think we just mandate that users passing in backslashes as a part
of a path construct use double-backslashes. Fair assumption I'd
assume (it's what I'd do anyway if specifying Windows paths in a Java
propfile.)
--
Manik Surtani
[EMAIL PROTECTED]
Lead, JBoss Cache
Telephone: +44 7786 702 706
MSN: [EMAIL PROTECTED]
Yahoo: maniksurtani
AIM: maniksurtani
Skype: maniksurtani
On 6 Apr 2006, at 14:12, Scott Marlow wrote:
It turns out that the root cause behind JBCACHE-531 is deeper than I
thought.
After fixing a minor international character support issue in
org.jboss.cache.config.CacheLoaderConfig (we were calling
String.getBytes() without specifying an encoding). I then came across
the same issue in
org.jboss.util.propertyeditor.PropertiesEditor.getValue(). I fixed
the
character encoding issue locally but I'm not sure of how to fix the
deeper issue.
Before I move into the deeper issue, let me explain the problem with
calling String.getBytes() without specifying an encoding (before
someone
flames me :). String.getBytes() will return a byte array
containing the
character values converted into the default platform encoding (perhaps
big5 or utf8 or perhaps latin1). In the two code sites mentioned
above,
we are passing the byte array into java.util.properties which always
wants encoding "ISO8859_1".
The deeper issue:
org.jboss.util.propertyeditor.PropertiesEditor.getValue() is
expected to
take a Java String value and parse it java.util.properties style.
However, we also support expanding JBoss system expressions that
can be
invalid when passed into java.util.properties.load() as we do.
For example, if the expression "${jboss.server.data.dir}" is passed in
and you are running on Windows, the intermediate result might be path
"c:\jboss\server\all\data". The output of java.util.properties.load
will be something like: "c: boss erver ll ata".
This creates a blocking problem for our sfsb fine grained replication
project. :(
Should we try to hack the expansion of jboss system expressions to
double escape the "\" escape character?
This seems like a tricky path to follow as I'm not sure if we
should do
the same for values that are simply passed in. For instance, are
users
expected to hard code paths in configuration files like this?
mytempdir=c:\temp
or like this:
mytempdir=c:\\temp
In one case, they already hit the bug that requires "\" to be doubled.
If I add code that doubles their "\", then we might end up with
something like "mytempdir=c:\\\\temp" (assuming that they already
doubled them). I suppose we could detect if the "\" characters are
already escaped and don't escape them again if so.
This also seems like a big change to make so near the end of the 4.0.4
release. I'll create a Jira for 4.0.4 unless someone talks me out of
making this change.
What is the right thing to do here?
On Thu, 2006-04-06 at 06:36 -0500, Ben Wang wrote:
Yes, it has. The other two are almost done. Scott Marlow and I
need to
verify JBCACHE-531 fix. I'd say let's go for QA next Monday then?
-Ben
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
