RE: [JBoss-dev] JBossCache 1.3.0.GA released
I know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon. I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly? Thanks, -Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh RajasekaranSent: Tuesday, April 04, 2006 6:04 AMTo: jboss-development@lists.sourceforge.netCc: QASubject: [JBoss-dev] JBossCache 1.3.0.GA released JBossCache 1.3.0.GA Wasabi has been released and is available for download at http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920 JBossCache 1.3.0.GA has also been updated in the repository. Thanks Rajesh JBoss QA
RE: [JBoss-dev] JBossCache 1.3.0.GA released
Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA. From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PM To: jboss-development@lists.sourceforge.net Cc: QA Subject: RE: [JBoss-dev] JBossCache 1.3.0.GA released I know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon. I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly? Thanks, -Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Rajasekaran Sent: Tuesday, April 04, 2006 6:04 AM To: jboss-development@lists.sourceforge.net Cc: QA Subject: [JBoss-dev] JBossCache 1.3.0.GA released JBossCache 1.3.0.GA “Wasabi” has been released and is available for download at http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920 JBossCache 1.3.0.GA has also been updated in the repository. Thanks Rajesh JBoss QA
Re: [JBoss-dev] JBossCache 1.3.0.GA released
This is a better case. The tutorial issue on its own was not strong enough, IMO. :)Ben, is this fixed in HEAD at the moment?Cheers, --Manik Surtani[EMAIL PROTECTED]Lead, JBoss CacheTelephone: +44 7786 702 706MSN: [EMAIL PROTECTED]Yahoo: maniksurtaniAIM: maniksurtaniSkype: maniksurtani On 5 Apr 2006, at 21:55, Ryan Campbell wrote:Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA. From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PMTo: jboss-development@lists.sourceforge.netCc: QASubject: RE: [JBoss-dev] JBossCache 1.3.0.GA released I know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon. I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly? Thanks, -Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rajesh RajasekaranSent: Tuesday, April 04, 2006 6:04 AMTo: jboss-development@lists.sourceforge.netCc: QASubject: [JBoss-dev] JBossCache 1.3.0.GA releasedJBossCache 1.3.0.GA “Wasabi” has been released and is available for download athttp://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920 JBossCache 1.3.0.GA has also been updated in the repository. ThanksRajeshJBoss QA
RE: [JBoss-dev] JBossCache 1.3.0.GA released
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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manik SurtaniSent: Thursday, April 06, 2006 5:51 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] JBossCache 1.3.0.GA released This is a better case. The tutorial issue on its own was not strong enough, IMO. :) Ben, is this fixed in HEAD at the moment? Cheers, -- Manik Surtani [EMAIL PROTECTED] Lead, JBoss Cache Telephone: +44 7786 702 706 MSN: [EMAIL PROTECTED] Yahoo: maniksurtani AIM: maniksurtani Skype: maniksurtani On 5 Apr 2006, at 21:55, Ryan Campbell wrote: Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA. From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PMTo: jboss-development@lists.sourceforge.netCc: QASubject: RE: [JBoss-dev] JBossCache 1.3.0.GA released I know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon. I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly? Thanks, -Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rajesh RajasekaranSent: Tuesday, April 04, 2006 6:04 AMTo: jboss-development@lists.sourceforge.netCc: QASubject: [JBoss-dev] JBossCache 1.3.0.GA released JBossCache 1.3.0.GA “Wasabi” has been released and is available for download at http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920 JBossCache 1.3.0.GA has also been updated in the repository. Thanks Rajesh JBoss QA
Re: [JBoss-dev] JBossCache 1.3.0.GA released
Ok. Has the tutorial been fixed as well? --Manik Surtani[EMAIL PROTECTED]Lead, JBoss CacheTelephone: +44 7786 702 706MSN: [EMAIL PROTECTED]Yahoo: maniksurtaniAIM: maniksurtaniSkype: maniksurtani On 6 Apr 2006, at 12:36, 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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Manik SurtaniSent: Thursday, April 06, 2006 5:51 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] JBossCache 1.3.0.GA released This is a better case. The tutorial issue on its own was not strong enough, IMO. :) Ben, is this fixed in HEAD at the moment? Cheers, -- Manik Surtani [EMAIL PROTECTED] Lead, JBoss Cache Telephone: +44 7786 702 706 MSN: [EMAIL PROTECTED] Yahoo: maniksurtani AIM: maniksurtani Skype: maniksurtani On 5 Apr 2006, at 21:55, Ryan Campbell wrote: Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA.From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PMTo: jboss-development@lists.sourceforge.netCc: QASubject: RE: [JBoss-dev] JBossCache 1.3.0.GA releasedI know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon.I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly?Thanks,-Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rajesh RajasekaranSent: Tuesday, April 04, 2006 6:04 AMTo: jboss-development@lists.sourceforge.netCc: QASubject: [JBoss-dev] JBossCache 1.3.0.GA releasedJBossCache 1.3.0.GA “Wasabi” has been released and is available for download athttp://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920JBossCache 1.3.0.GA has also been updated in the repository.ThanksRajeshJBoss QA
Re: [JBoss-dev] JBossCache 1.3.0.GA released
Also, we need to branch 1.3.0 for this. Let me create one and I'll send you the branch tag. Too many half baked 1.4.0 features in HEAD now. --Manik Surtani[EMAIL PROTECTED]Lead, JBoss CacheTelephone: +44 7786 702 706MSN: [EMAIL PROTECTED]Yahoo: maniksurtaniAIM: maniksurtaniSkype: maniksurtani On 6 Apr 2006, at 12:36, 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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Manik SurtaniSent: Thursday, April 06, 2006 5:51 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] JBossCache 1.3.0.GA released This is a better case. The tutorial issue on its own was not strong enough, IMO. :) Ben, is this fixed in HEAD at the moment? Cheers, -- Manik Surtani [EMAIL PROTECTED] Lead, JBoss Cache Telephone: +44 7786 702 706 MSN: [EMAIL PROTECTED] Yahoo: maniksurtani AIM: maniksurtani Skype: maniksurtani On 5 Apr 2006, at 21:55, Ryan Campbell wrote: Is this (and the tutorial issue) not a good reason for 1.3.1.CR1? And then 1 week later, once we have a bug free release, we just rename (and retag it) as 1.3.1.GA.From: Ben Wang Sent: Tuesday, April 04, 2006 8:42 PMTo: jboss-development@lists.sourceforge.netCc: QASubject: RE: [JBoss-dev] JBossCache 1.3.0.GA releasedI know this not good timing. :-) But during my work on migrating ejb3 sfsb passivation using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have discovered two bugs. And I will need these two fixed so I can check in my code in head. So first option is to create a patch and use that. Second option is use the snapshot in JBossCache and couting on that 1.4 release will be out soon.I am leaning towards the second option such that if there is any future bug fixes or enahncement then I can create another shapshot right away. What do people think? And how do I do that properly?Thanks,-Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rajesh RajasekaranSent: Tuesday, April 04, 2006 6:04 AMTo: jboss-development@lists.sourceforge.netCc: QASubject: [JBoss-dev] JBossCache 1.3.0.GA releasedJBossCache 1.3.0.GA “Wasabi” has been released and is available for download athttp://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920JBossCache 1.3.0.GA has also been updated in the repository.ThanksRajeshJBoss QA
RE: [JBoss-dev] JBossCache 1.3.0.GA released
What tutorial? It is not broken,
AFAIK.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manik
SurtaniSent: Thursday, April 06, 2006 8:16 PMTo:
jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev]
JBossCache 1.3.0.GA released
Ok. Has the tutorial been fixed as well?
--
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 12:36, 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
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Manik SurtaniSent: Thursday, April 06, 2006
5:51 PMTo: jboss-development@lists.sourceforge.netSubject:
Re: [JBoss-dev] JBossCache 1.3.0.GA released
This is a better case. The tutorial issue on its own was not
strong enough, IMO. :)
Ben, is this fixed in HEAD at the moment?
Cheers,
--
Manik Surtani
[EMAIL PROTECTED]
Lead, JBoss Cache
Telephone: +44 7786 702 706
MSN: [EMAIL PROTECTED]
Yahoo: maniksurtani
AIM: maniksurtani
Skype: maniksurtani
On 5 Apr 2006, at 21:55, Ryan Campbell wrote:
Is this
(and the tutorial issue) not a good reason for 1.3.1.CR1?
And then 1
week later, once we have a bug free release, we just rename (and retag it)
as 1.3.1.GA.
From: Ben
Wang Sent:
Tuesday, April 04, 2006 8:42 PMTo:
jboss-development@lists.sourceforge.netCc:
QASubject: RE:
[JBoss-dev] JBossCache 1.3.0.GA released
I know this
not good timing. :-) But during my work on migrating ejb3 sfsb passivation
using JBossCache (http://jira.jboss.com/jira/browse/EJBTHREE-500), I have
discovered two bugs. And I will need these two fixed so I can check in my
code in head. So first option is to create a patch and use that. Second
option is use the snapshot in JBossCache and couting on that 1.4 release
will be out soon.
I am
leaning towards the second option such that if there is any future bug fixes
or enahncement then I can create another shapshot right away. What do
people think? And how do I do that properly?
Thanks,
-Ben
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of
Rajesh
RajasekaranSent:
Tuesday, April 04, 2006 6:04 AMTo:
jboss-development@lists.sourceforge.netCc:
QASubject:
[JBoss-dev] JBossCache 1.3.0.GA released
JBossCache 1.3.0.GA
“Wasabi” has been released and is available for download at
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920
JBossCache 1.3.0.GA has
also been updated in the repository.
Thanks
Rajesh
JBoss QA
RE: [JBoss-dev] JBossCache 1.3.0.GA released + a change to how we deal with java.util.properties
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
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
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-devel
RE: [JBoss-dev] JBossCache 1.3.0.GA released + a change to how we deal with java.util.properties
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.
