[
https://issues.apache.org/jira/browse/SAMZA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130776#comment-14130776
]
Yan Fang commented on SAMZA-40:
-------------------------------
{quote}
an sensible defaults make the config less verbose?
What about on/off switches for things like metrics and checkpointing? If don't
specify otherwise, you get the default metrics package and Kafka checkpointing.
{quote}
+1 as well. For something like metrics/checkpointing/Serde, having a default
setting to the core classes, such as
org.apache.samza.metrics.reporter.MetricsSnapshotReporterFactory , will make
the configuration less verbose and less error-prone (sometimes, the
class-not-found is just because typing in the wrong class name...).
Switching on/off sounds a good option for me. If the user explicitly sets the
metrics/checkpointing, the job will use user's setting, like what Samza has
now. If not, a user can simply turn the “switch" on and the job will use the
default setting.
{quote}
Support for validation during build and during runtime initialization to catch
errors early.
{quote}
Is there another ticket talking about validating the configuration before the
job starts? I think there is one but can not find it out now.
> Refactor Samza configuration
> ----------------------------
>
> Key: SAMZA-40
> URL: https://issues.apache.org/jira/browse/SAMZA-40
> Project: Samza
> Issue Type: Bug
> Components: container
> Affects Versions: 0.6.0
> Reporter: Chris Riccomini
> Labels: project
>
> Samza's configuration system has several problems that we need to resolved.
> * Want to auto-generate documentation based off of configuration.
> * Should support global defaults for a config property. Right now, we do
> config.getFoo.getOrElse() everywhere.
> * Should validate config up front, rather than thrown runtime exceptions
> randomly throughout the code.
> * We are mixing wiring and configuration together. How do other systems
> handle this?
> * We have fragmented configuration (anybody can define configuration). How do
> other systems handle this?
> * How to handle undefined configuration? How to make this interoperable with
> both Java and Scala (i.e. should we support Option in Scala)?
> * Should remain immutable.
> * Should remove implicits. It's just confusing.
> * Do we want to support complex types (list, map) for values, not just String?
> We need a design proposal for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
