[
https://issues.apache.org/jira/browse/HADOOP-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557471#action_12557471
]
Konstantin Shvachko commented on HADOOP-2385:
---------------------------------------------
JobConf does not set hdfs parameters, but I agree users might want to
set/access inter-component parameters.
My idea was to use carefully designed hierarchy of configuration classes and
interfaces.
Like TaskTrackerConfiguration can be inherited from DFSClientConfiguration.
But I see the static approach you propose is simpler.
This means that the configuration classes should be public then, right?
And it doesn't matter where the get/setters are. Particularly we can combine
all of them in one class
or even place them in the Configuration class. Is it what you want?
> I don't find the argument that FSNamesystem is already too big compelling.
Yes the size is not important. What I meant is that we keep placing logically
independent
code inside e.g. FSNamesystem, which makes it bigger, while it could easily be
made a separate class.
And configuration is just an example of such logically independent part.
If you write a converter for a parameter or add a verification constraint -
these changes belong to
the configuration only, namely to the implementation of getters, why modify
FSNamesystem if it only calls them.
> Validate configuration parameters
> ---------------------------------
>
> Key: HADOOP-2385
> URL: https://issues.apache.org/jira/browse/HADOOP-2385
> Project: Hadoop
> Issue Type: Improvement
> Components: dfs
> Affects Versions: 0.16.0
> Reporter: Robert Chansler
>
> Configuration parameters should be fully validated before name nodes or data
> nodes begin service.
> Required parameters must be present.
> Required and optional parameters must have values of proper type and range.
> Undefined parameters must not be present.
> (I was recently observing some confusion whose root cause was a mis-spelled
> parameter.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
