[
https://issues.apache.org/jira/browse/HADOOP-15007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351626#comment-16351626
]
Steve Loughran commented on HADOOP-15007:
-----------------------------------------
We use string constants for all other XML configuration values: it works.
h3. We do not need to embrace a service loader mechanism or other more complex
mechanism purely because it was felt that it offered slighly better compile
time safety for strings whose primary use is in XML files.
Anu, this is a distraction. I appreciate the overall idea, and, despite the
fact that my first experiments ended i stack traces, I can see the benefit.
But I believe type safety is overkill, using service loaders not only even more
overkill, but based on the FileSystem service loader experience, a route to
more stack traces.
Imagine, for example, a tag for a config option which is found in a optional
JAR. You are going to have problems whenever that XML file is read and the JAR
isn't there. Or somehow the same enum is >1 JAR: something will have to handle
that. Yes, code can be added for this, but all that ends up happening is more
and more code to test, maintain and fix.
Please, stop trying to argue this. I'm not going to be convinced. Sorry.
> Stabilize and document Configuration <tag> element
> --------------------------------------------------
>
> Key: HADOOP-15007
> URL: https://issues.apache.org/jira/browse/HADOOP-15007
> Project: Hadoop Common
> Issue Type: Improvement
> Components: conf
> Affects Versions: 3.1.0
> Reporter: Steve Loughran
> Assignee: Ajay Kumar
> Priority: Blocker
>
> HDFS-12350 (moved to HADOOP-15005). Adds the ability to tag properties with a
> <tag> value.
> We need to make sure that this feature is backwards compatible & usable in
> production. That's docs, testing, marshalling etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
