Commons configuration not compatible with java.util.Properties

[Jorge Ferrer <jo...@gmail.com>]

Hi Oliver, Emmanuel and all,

I have seen the same problem several times when people move from the
traditional java.util.Properties to Commons Configuration: it has some
characteristics which make it not compatible with the properties
format they were used to. I'd like to make a proposal for how to solve
this. But first the details...

The most important problem is the use of commas to represent
multivalued properties. The latest case I've seen is one application
which read configuration which was later given to JGroups. Here is an
extract of the configuration:

cache.cluster.properties=UDP(bind_addr=127.0.0.1;mcast_addr=231.12.21.101;mcast_port=45566;ip
_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_me
mbers=3):MERGE2(min_interval=5000;max_interval=10000):FD_SOCK:VERIFY_SUSPECT(timeout=1500):pbc
ast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):UNICAST(tim
eout=300,600,1200,2400):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096;down_threa
d=false;up_thread=false):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print
_local_addr=true)

This property value was copied directly from the Jgroups doc but when
used through commons configuration it didn't work (because it was
commas so it is considered multivalued). And what was worst is that it
is not easy to find the cause of the problem.

I know that this may sound silly for people very used to Configuration
because all that is needed is to escape the commas. But I have faced
complains about commons configurations several times because of this:
it is not so easy to remember about escaping the commas if in many
other applications used (which use java.util.Properties) it is not
necessary.

I'd like to make a proposal to solve this issue without changing the
current behaviour: implement a java.util.Properties mode in Commons
Configuration. This mode should work the same as
get/setThrowExceptionOnMissing and if set to true all the semantics of
java.util.Properties would be kept. In this mode the commas will never
be parsed and the only way to set several values would be the
following:
property=value1
property=value2

What do you think?

--
Cheers,
Jorge Ferrer

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: Commons configuration not compatible with java.util.Properties

[Oliver Heger <ol...@t-online.de>]

Hi Jorge,

Jorge Ferrer wrote:

>Hi Oliver, Emmanuel and all,
>
>I have seen the same problem several times when people move from the
>traditional java.util.Properties to Commons Configuration: it has some
>characteristics which make it not compatible with the properties
>format they were used to. I'd like to make a proposal for how to solve
>this. But first the details...
>
>The most important problem is the use of commas to represent
>multivalued properties. The latest case I've seen is one application
>which read configuration which was later given to JGroups. Here is an
>extract of the configuration:
>
>cache.cluster.properties=UDP(bind_addr=127.0.0.1;mcast_addr=231.12.21.101;mcast_port=45566;ip
>_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_me
>mbers=3):MERGE2(min_interval=5000;max_interval=10000):FD_SOCK:VERIFY_SUSPECT(timeout=1500):pbc
>ast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):UNICAST(tim
>eout=300,600,1200,2400):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096;down_threa
>d=false;up_thread=false):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print
>_local_addr=true)
>
>This property value was copied directly from the Jgroups doc but when
>used through commons configuration it didn't work (because it was
>commas so it is considered multivalued). And what was worst is that it
>is not easy to find the cause of the problem.
>
>I know that this may sound silly for people very used to Configuration
>because all that is needed is to escape the commas. But I have faced
>complains about commons configurations several times because of this:
>it is not so easy to remember about escaping the commas if in many
>other applications used (which use java.util.Properties) it is not
>necessary.
>  
>
In fact I fell into this trap myself multiple times. Also with 
XMLConfiguration, which makes use of this delimiter in both attributes 
and elements, too. I personally never had a use case for this behavior. 
IMHO it is just a short cut, which may (and obviously does) cause 
trouble. But now it is too late to change... :-(

>I'd like to make a proposal to solve this issue without changing the
>current behaviour: implement a java.util.Properties mode in Commons
>Configuration. This mode should work the same as
>get/setThrowExceptionOnMissing and if set to true all the semantics of
>java.util.Properties would be kept. In this mode the commas will never
>be parsed and the only way to set several values would be the
>following:
>property=value1
>property=value2
>
>What do you think?
>
>  
>
Is the treatment of the comma the only incompatibility between 
java.util.Properties and Configuration you spotted? If this is the case, 
the name "java.util.Properties" mode is probably a bit misleading. We 
have already the static setDelimiter() method in AbstractConfiguration, 
which allows to disable this behavior. So the Properties compatibility 
mode would simply correspond to a call to 
AbstractConfiguration.setDelimiter((char) 0); It is also planed to 
support setting the delimiter on a per instance base.

Would an improved documentation solve the problem? I will add some notes 
to both the howtos and the javadocs.

BTW: Did you see the posting on the user list from today about 
unexpected behavior in XMLConfiguration? This is coincidence!

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org