commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <>
Subject Re: [configuration] File locator
Date Wed, 08 Dec 2004 13:11:49 GMT
Emmanuel Bourg <> writes:

>Henning P. Schmiedehausen wrote:

>>>If we have Loccators,  IMO there is no need to keep the base path and 
>>>file name stuff in file based configurations. These are things a 
>> +1 !

>-1 to remove the file name from the method signature, I'll explain 
>later. +1 to remove the base path, but I haven't figured how to do it 
>yet ;) Using the base path as a locator parameter, just like the 
>classloader for the ClasspathLocator is most likely the solution. But it 
>doesn't fit well with the LocatorUtils.getDefaultLocator() method.

I'm willing to keep this because we already have it. I'd still like to
see the internal implementation folded onto the Locator so that the
C'tor itself is just a convenience method, not something with real
implementation differences.

>> +1.  With throws, please. We will have to deal with exceptions anyway
>> and it is the job of the application to do so.

>I'm not sure about that, I had no need for exceptions in my 
>implementation, when I dealt with exception it meant the file could not 
>be located, and the locator returned a null URL.

>An alternative is to throw a ConfigurationNotFound exception extending 
>ConfigurationException instead of returning null, but I'm not fond of this.

Must think more about this. Maybe Oliver has some ideas.

>> Yes. But in this case, I want to have a C'tor which takes the
>> parameters directly.

>I agree for the same reasons, it's nice to be "digester friendly" with 
>setters, but that doesn't prevent us from adding a non empty 
>constructor. It may even be possible to make digester use the 
>constructor directly with a specific rule (if it doesn't already exist).

Yes, but the digester syntax sucks. :-) Using a non-parameter c'tor
and setters is much easier (BTDT).

>> and have the configuration classes take a Locator object in its
>> C'tor. But Emmanuel does not like this.

>Indeed, as I explained, once you write

>new MyConcreteLocator("basepath", "file")

>The locator is no longer a strategy to locate the file, it becomes an 
>object defining the location of the file (i.e it could replace the URL). 
>The same strategy should also be reusable for several configurations, 
>and this is not possible once the file name is bound to the locator, the 
>locator must remain "stateless".

So let's redefine the meaning of Locator? I'd very much like to
capsule the details of a configuration resource into an object. Things
like "load from classpath", "use this class loader", "this is the base
path", "use this resource name" and so on. I agree, that this _should_
be all URL. However, some of the implementation details are simply not
caught here (like the class loader issue).

I understand that you want to reuse the "Locator stategy object" for
multiple invocations. This is not possible with the idea that Oliver
and I seem to share. 

So we might simply not want to call it "Locator" but something
different. I have a strong feeling that, if we start to drag around a
"filename, locator" pair, we will regret this later.

And we will get an Interface signature of URL locate(String filename)
e.g. which will be horked if a Locator implementation needs more or
less parameters (this custom ClassLoader e.g.). And then you will have
to add setters to this custom Locator implementation and have state

The only thing (IMHO) to get around this is to run "locate()" without
parameters and apply state to the Locator object.

Or we give up the idea of an unified Locator interface and just say
"plug in any method that returns URL".


Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH        +49 9131 50 654 0

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message