common.text package update

[julien1]

I worked on the common.text package in order to:

1/ introduce concept of CharWriter (similar to java.lang.CharSequence but for write operations).

2/ introduce CharEncoder which defines an interface for encoding char stream to char stream.

3/ reimplement FastURLEncoder in a more reliable and faster way (java.netURLEncoder is broken and slow).

4/ implement FastURLDecoder for decoding x-www-formurl-encoded strings in a reliable and fast way (java.netURLDecoder is broken and slow).

5/ added TextTools (similar to other XXXTools).

[julien1]

I reimplemented QueryStringParser to use the new FastURLDecoder and also to be more fault tolerant. The previous version actually did not have any test unit testing......

Thanks Thomas for aligning 2.6 with those changes.

[antoine_h]

Hello,

I looked at the FastURLDecoder and the way it is used in the JSF backing beans, such as :
org.jboss.portal.core.identity.ui.EditProfileAction

Main question : FastURLDecoder is not multi thread safe ?

then, in the EditProfileAction, it is used like that :

private final static FastURLDecoder decoder = FastURLDecoder.getUTF8Instance();

and getUTF8Instance returns the same static instance of FastURLDecoder.

then, in case two threads call the encode() method at the same time... there will be some mixing in the data, and bad result. no ?

I am not very used to these multi thread safe issues, but it seems to me that :
- either the FastURLDecoder should be programmed to be threads safe
- either it should not be used as a static in a jsf backing bean

did I missed something ?

[julien1]

It is thread safe, the fields of the class are accessed in write operations in the class constructor.

In the decode operations the fields are read only.