• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • Reporter: teck
  • September 02, 2011
  • 0
  • Watchers: 2
  • September 06, 2011

Description

source: http://forums.terracotta.org/forums/posts/list/5905.page

The way properties attributes are loaded from ehcache.xml can be problematic. For example consider this config elements:

{noformat}

{noformat}

That will get expanded (on windows) to something like this before XML parsing:

{noformat}

{noformat}

And then when passed to Properties.load() (in net.sf.ehcache.util.PropertyUtil.parseProperties()) you’ll end up a Properties object with this mapping:

{noformat} “path” = “C:Usersbob/path” {noformat}

Properties.load() will just silently ignore invalid escape characters.

I think we need to stop using Properties.load() for creating the Properties instance (doing our own splitting of the key/value paira). Although if someone is depending on getting expansion of something like “\n” or “\t” in there we will break them. Or if they are relying on any of the other fancy bits of parsing logic that properties files can have (see javadoc).

I think it best to keep it simple, do our parsing, not support any escape characters, and let people define a different property delimiter if they need a comma in their properties

Comments

Tim Eck 2011-09-02

Greg should probably decide what to do with this since the fix involves potentially deciding to break existing configs

Fiona OShea 2011-09-06

Greg what are your thoughts on this?