Hi Doug,

Thanks a lot for response. I am trying to write a little UI to modify
the nutch conf file to add/delete websites to crawl, and manage media
types, and maybe do  more later on. Looking for conf file on the
classpath would require me to manually add another classpath folder
where the webapp can look for the conf files. I am trying to avoid
that and let the user specify the folder to look at, either in the
init params of the webapp or user will be able to specifyin it after
the webapp has started.  Initially I want webapp to have less
deployment headaches.

It might be useful to add api to let a user specify conf file
location, especially if people are developing tools for nutch. A
constructor on NutchConf that takes in the nutch conf dir would be
sufficient for this.

Regards,
Paul


On 8/5/05, Doug Cutting <[EMAIL PROTECTED]> wrote:
> Classpath is used as it's the only way I know in Java to refer to the
> installation location.  (One can use the "java.home" system property to
> find the location of the java installation, but not the location of
> application code.)  Also, things on classpath are generally easier for
> servlets and applets to access than arbitrary files.  Finally, using
> classpath means that config files can easily be bundled into jar files
> with code.
> 
> That said, it might be useful to also check an environment variable.  We
> could check, e.g., NUTCH_CONF_DIR, if defined, before the classpath.
> 
> Doug
> 
> sub paul wrote:
> > Hi all,
> >
> > I was trying to find a way to load NutchConf by specifying the exact
> > location of the conf files. Is there a way to load the NutchConf
> > without actually adding the conf files to the classpath? I looked at
> > the api doc and I does not seem to have a way to do that.
> >
> > I am thinking extending NutchConf and overriding  public URL
> > getResource(String name);
> >
> > would that be a pretty good way of going about it?
> >
> > Also, does anyone see a need a case where we need to load conf files
> > that are not on classpath?
> >
> > Regards,
> > Paul
>

Reply via email to