Bertrand -
Thanks for responding. Regarding the doubling of the methods, normally I
wouldn't suggest it, but these new methods may be the only methods some
programmers ever use in Tika. I was thinking that their use will be so
common that the additional verbosity would be justified. Also, in my use
cases, I don't anticipate *ever* overriding the default configuration. My
two cents.
Good point about synchronizing the lazy instantiation. I hadn't thought
about that. We could also make one default configuration per thread using
threadlocal to avoid the overhead of synchronization, but I've heard that
synchronization is not as slow as it used to be, so that might be overkill.
- Keith
Bertrand Delacretaz wrote:
>
> On 9/25/07, kbennett <[EMAIL PROTECTED]> wrote:
>
>> On further thought, a static method returning the default configuration
>> might
>> be better than a no-arg constructor....
>
> Sounds good to me.
>
> I'm not sure about doubling the number of methods which use configs
> though, having to use config==null to get the default sounds
> reasonable. But that's not terribly important, if you find places
> where an additional method is useful I have no problem with that.
>
> + if (defaultConfig == null) {
> + URL url = new URL(DEFAULT_CONFIG_URL);
> + defaultConfig = new TikaConfig(url);
> + }
>
> I'd just make this synchronized(TikaConfig.class).
>
> -Bertrand
>
>
--
View this message in context:
http://www.nabble.com/Providing-a-Default-Tika-Configuration-tf4510478.html#a12873645
Sent from the Apache Tika - Development mailing list archive at Nabble.com.
