Re: codec - thread safe
On 09/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote: On 10/8/07, sebb [EMAIL PROTECTED] wrote: Which methods do you actually need? If you only need BCodec, then that (and Base64 which it calls) look to be thread-safe, so you only need to instantiate it once for each different charset. Yes, I sort of figured that out for myself already when I first started the conversation with Henri. Now thanks for your help, I got another pair of eyes confirming this. So I am good in my case. But all the discussion has been more about the in general case. I just feel that, 1. Codec as a commons library, it should not be this hard to find out about information like this. It should be either this or that, find out for yourself is no good situation. As someone else pointed out earlier, we could use a better documentation. Agreed. It should be stated clearly whether or not the code is thread-safe. 2. It'd be nice for the biz method implementations to be thread safe (Ideally in a high performance manner as a value add-on of using a commons brand library such that user doesn't have to be too creative as some of the suggestions given in this discussion to achieve performance). Most of them may already be thread safe. And as it seems agreed by all that it's not hard to make them that way if not. For a library such as codec, I agree that it should be thread-safe by design. Where this is not possible, the unsafe classes should be clearly identified. I don't think it makes sense to separate methods into biz and the rest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: codec - thread safe
sebb wrote: On 09/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote: On 10/8/07, sebb [EMAIL PROTECTED] wrote: Which methods do you actually need? If you only need BCodec, then that (and Base64 which it calls) look to be thread-safe, so you only need to instantiate it once for each different charset. Yes, I sort of figured that out for myself already when I first started the conversation with Henri. Now thanks for your help, I got another pair of eyes confirming this. So I am good in my case. But all the discussion has been more about the in general case. I just feel that, 1. Codec as a commons library, it should not be this hard to find out about information like this. It should be either this or that, find out for yourself is no good situation. As someone else pointed out earlier, we could use a better documentation. Agreed. It should be stated clearly whether or not the code is thread-safe. I attached a patch to this bug. My solution here was to add static methods called createThreadSafeCodec on all the classes that are thread safe. For a few, this simply returns an instance of the object. For others, it returns an instance of the object that overrides the dangerous set* methods. That way, if anyone tried to use it in an unsafe manner, they will deterministically get an error. My patch also adds a blurb in package.html basically saying this. 2. It'd be nice for the biz method implementations to be thread safe (Ideally in a high performance manner as a value add-on of using a commons brand library such that user doesn't have to be too creative as some of the suggestions given in this discussion to achieve performance). Most of them may already be thread safe. And as it seems agreed by all that it's not hard to make them that way if not. For a library such as codec, I agree that it should be thread-safe by design. Where this is not possible, the unsafe classes should be clearly identified. I don't think it makes sense to separate methods into biz and the rest. I agree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Commons Configuration - Problem with Variable Interpolation and StringArray
I'm able to use Jakarta Commons Configuration with .properties files and
String[] properties, but when I use variable interpolation to refer to a
String[] property, it only returns the first element. Example:
.properties file contents:
test.email.addresses = [EMAIL PROTECTED],
[EMAIL PROTECTED]
test.email.recipients = ${test.email.addresses}
Code:
String[] testEmailAddresses = config.getStringArray(test.email.addresses);
String[] testEmailRecipients =
config.getStringArray(test.email.recipients);
System.out.println(testEmailAddresses = +
ArrayUtils.toString(testEmailAddresses));
System.out.println(testEmailRecipients = +
ArrayUtils.toString(testEmailRecipients));
Output:
testEmailAddresses =
[EMAIL PROTECTED],[EMAIL PROTECTED]
testEmailRecipients = [EMAIL PROTECTED]
Shouldn't testEmailRecipients get the same String[] value as
testEmailAddresses? Am I doing something wrong, or can't this be done?
Is there a special recursive variable interpolation character for arrays?
- Jim
__
James Watkin
ACIS Software Development
UCLA Anderson School
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
org.apache.commons.lang.time.DateUtils.parseDate Leniency
org.apache.commons.lang.time.DateUtils.parseDate appears to use SimpleDateFormat to do its parsing with setLenient(true). This will result in the acceptance of a date string like 20012007 against a pattern like MMdd. This parsing will actually return a date of Fri Aug 01 00:00:00 PDT 2008. A suggestion for a future enhancement might be to create an additional method for DateUtils named parseStrictDate, or something similar, which applies setLenient(false) to its internal SimpleDateFormat parser. - Jim __ James Watkin ACIS Software Development UCLA Anderson School [EMAIL PROTECTED] Voice: 1-310-825-5030 Fax: 1-310-825-4835 __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
