I agree with Manik here. If it is user-specified, we mandate them to escape it
themselves for Windows. But we need to do the same for our own AS path variable
like ${jboss.server.data.dir}.
I'd say let's open a Jira and fix this in jboss-head only since we are moving
to 5.0, AFAIK.
-Ben
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manik Surtani
Sent: Thursday, April 06, 2006 10:33 PM
To: jboss-development@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBossCache 1.3.0.GA released + a change to how we deal
with java.util.properties
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
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
