You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nutch.apache.org by Doğacan Güney <do...@gmail.com> on 2007/06/08 17:30:16 UTC
Re: Plugins initialized all the time!
On 5/31/07, Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
>
> > Actually thinking a bit further into this, I kind of agree with you. I
> > initially thought that the best approach would be to change
> > PluginRepository.get(Configuration) to PluginRepository.get() where
> > get() just creates a configuration internally and initializes itself
> > with it. But then we wouldn't be passing JobConf to PluginRepository
> > but PluginRepository would do something like a
> > NutchConfiguration.create(), which is probably wrong.
> >
> > So, all in all, I've come to believe that my (and Nicolas') patch is a
> > not-so-bad way of fixing this. It allows us to pass JobConf to
> > PluginRepository and stops creating new PluginRepository-s again and
> > again...
> >
> > What do you think?
>
> IMO a better way would be to add a proper equals() method to Hadoop's
> Configuration object (and hashcode) that would call
> getProps().equals(o.getProps()). So that you could use them as keys...
> Every class which is a map from keys to values has "equals & hashcode"
> (Properties, HashMap, etc.).
>
> Another nice thing would be to be able to "freeze" a configuration
> object, preventing anyone from modifying it.
>
>
I found that there is already an issue for this problem - NUTCH-356. I
will update it with most recent discussions.
--
Doğacan Güney
Re: Plugins initialized all the time!
Posted by Briggs <ac...@gmail.com>.
I should have used the word "encapsulate" instead of "store". :-)
On 6/8/07, Briggs <ac...@gmail.com> wrote:
> Well, you could always 'freeze' it, just create a decorator for it. So,
> create a new Configuration (call it ImmutableConfiguration) store the
> original configuration object in it, and delegate the methods appropriately.
> Wouldn't that work?
>
>
>
>
>
> On 6/8/07, Doğacan Güney <do...@gmail.com> wrote:
> > On 5/31/07, Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
> > >
> > > > Actually thinking a bit further into this, I kind of agree with you. I
> > > > initially thought that the best approach would be to change
> > > > PluginRepository.get(Configuration) to PluginRepository.get() where
> > > > get() just creates a configuration internally and initializes itself
> > > > with it. But then we wouldn't be passing JobConf to PluginRepository
> > > > but PluginRepository would do something like a
> > > > NutchConfiguration.create(), which is probably wrong.
> > > >
> > > > So, all in all, I've come to believe that my (and Nicolas') patch is a
> > > > not-so-bad way of fixing this. It allows us to pass JobConf to
> > > > PluginRepository and stops creating new PluginRepository-s again and
> > > > again...
> > > >
> > > > What do you think?
> > >
> > > IMO a better way would be to add a proper equals() method to Hadoop's
> > > Configuration object (and hashcode) that would call
> > > getProps().equals(o.getProps()). So that you could use them as keys...
> > > Every class which is a map from keys to values has "equals & hashcode"
> > > (Properties, HashMap, etc.).
> > >
> > > Another nice thing would be to be able to "freeze" a configuration
> > > object, preventing anyone from modifying it.
> > >
> > >
> >
> > I found that there is already an issue for this problem - NUTCH-356. I
> > will update it with most recent discussions.
> >
> > --
> > Doğacan Güney
> >
>
>
>
> --
>
> "Conscious decisions by conscious minds are what make reality real"
--
"Conscious decisions by conscious minds are what make reality real"
Re: Plugins initialized all the time!
Posted by Briggs <ac...@gmail.com>.
Well, you could always 'freeze' it, just create a decorator for it. So,
create a new Configuration (call it ImmutableConfiguration) store the
original configuration object in it, and delegate the methods appropriately.
Wouldn't that work?
On 6/8/07, Doğacan Güney <do...@gmail.com> wrote:
>
> On 5/31/07, Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
> >
> > > Actually thinking a bit further into this, I kind of agree with you. I
> > > initially thought that the best approach would be to change
> > > PluginRepository.get(Configuration) to PluginRepository.get() where
> > > get() just creates a configuration internally and initializes itself
> > > with it. But then we wouldn't be passing JobConf to PluginRepository
> > > but PluginRepository would do something like a
> > > NutchConfiguration.create(), which is probably wrong.
> > >
> > > So, all in all, I've come to believe that my (and Nicolas') patch is a
> > > not-so-bad way of fixing this. It allows us to pass JobConf to
> > > PluginRepository and stops creating new PluginRepository-s again and
> > > again...
> > >
> > > What do you think?
> >
> > IMO a better way would be to add a proper equals() method to Hadoop's
> > Configuration object (and hashcode) that would call
> > getProps().equals(o.getProps()). So that you could use them as keys...
> > Every class which is a map from keys to values has "equals & hashcode"
> > (Properties, HashMap, etc.).
> >
> > Another nice thing would be to be able to "freeze" a configuration
> > object, preventing anyone from modifying it.
> >
> >
>
> I found that there is already an issue for this problem - NUTCH-356. I
> will update it with most recent discussions.
>
> --
> Doğacan Güney
>
--
"Conscious decisions by conscious minds are what make reality real"