Is this related to http://jira.jboss.com/jira/browse/JBAS-1888 ?
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Ben Wang > Sent: 07 April, 2006 10:35 > 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 > > 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=k&kid0944&bid$1720&dat1642 > _______________________________________________ > 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
