Return-Path: X-Original-To: apmail-sqoop-dev-archive@www.apache.org Delivered-To: apmail-sqoop-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0876E17B85 for ; Fri, 31 Oct 2014 22:24:34 +0000 (UTC) Received: (qmail 71808 invoked by uid 500); 31 Oct 2014 22:24:33 -0000 Delivered-To: apmail-sqoop-dev-archive@sqoop.apache.org Received: (qmail 71773 invoked by uid 500); 31 Oct 2014 22:24:33 -0000 Mailing-List: contact dev-help@sqoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@sqoop.apache.org Delivered-To: mailing list dev@sqoop.apache.org Received: (qmail 71762 invoked by uid 99); 31 Oct 2014 22:24:33 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Oct 2014 22:24:33 +0000 Date: Fri, 31 Oct 2014 22:24:33 +0000 (UTC) From: "Veena Basavaraj (JIRA)" To: dev@sqoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (SQOOP-1604) Base/ Marker class for Config and Configuration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SQOOP-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192622#comment-14192622 ] Veena Basavaraj edited comment on SQOOP-1604 at 10/31/14 10:24 PM: ------------------------------------------------------------------- I am curious Why do you prefer Object ? when we can have a typed class? Having generics in java ( even with type erasure) meant we can avoid a lot of these class cast exceptions. was (Author: vybs): I am curious Why do you prefer Object ? when we can have a typed class? > Base/ Marker class for Config and Configuration > ----------------------------------------------- > > Key: SQOOP-1604 > URL: https://issues.apache.org/jira/browse/SQOOP-1604 > Project: Sqoop > Issue Type: Bug > Affects Versions: 1.99.4 > Reporter: Veena Basavaraj > Assignee: Veena Basavaraj > Fix For: 2.0.0 > > > HDFS and Hbase connector code did not seem to have much functionality to in the initializer and destroyer, so provide a common empty class that connector developers can use if they have nothing to override. > It is pretty much difficult to have a empty initializer and destroyer classes with the current Initializer api > I wish our Initializer api was more like the below that enforced the typesafety much harder. > {code} > /** > * This allows connector to define initialization work for execution, > * for example, context configuration. > */ > public abstract class Initializer { > /** > * Initialize new submission based on given configuration properties. Any > * needed temporary values might be saved to context object and they will be > * promoted to all other part of the workflow automatically. > * > * @param context Initializer context object > * @param linkConfiguration link configuration object > * @param jobConfiguration job configuration object for the FROM and TO > * In case of the FROM initializer this will represent the FROM job configuration > * In case of the TO initializer this will represent the TO job configuration > */ > public abstract void initialize(InitializerContext context, L linkConfiguration, > J jobConfiguration); > {code} > We could have a base marker classes LinkConfiguration / JobConfiguration, FromJobConfiguration, ToConfiguration instead of the annotations, this way code like this would be more type safe rather than using object that can lead to a lot of class cast exception at runt time > {code} > // link config for the FROM part of the job > Object fromLinkConfig = ClassUtils.instantiate(fromConnector.getLinkConfigurationClass()); > ConfigUtils.fromConfigs(fromConnection.getConnectorLinkConfig().getConfigs(), fromLinkConfig); > // link config for the TO part of the job > Object toLinkConfig = ClassUtils.instantiate(toConnector.getLinkConfigurationClass()); > ConfigUtils.fromConfigs(toConnection.getConnectorLinkConfig().getConfigs(), toLinkConfig); > public Object getConnectorLinkConfig(Direction type) { > switch(type) { > case FROM: > return fromConnectorLinkConfig; > case TO: > return toConnectorLinkConfig; > default: > throw new SqoopException(DirectionError.DIRECTION_0000, "Direction: " + type); > } > } > public void setConnectorLinkConfig(Direction type, Object config) { > switch(type) { > case FROM: > fromConnectorLinkConfig = config; > break; > case TO: > toConnectorLinkConfig = config; > break; > default: > throw new SqoopException(DirectionError.DIRECTION_0000, "Direction: " + type); > } > } > /** > * All configuration objects > */ > Object fromConnectorLinkConfig; > Object toConnectorLinkConfig; > Object fromConfig; > Object toConfig; > Object d > > {code} > and instead of generic Class, we could have typed Class > before > {code} > /** > * @return Get link configuration group class > */ > @SuppressWarnings("rawtypes") > public abstract Class getLinkConfigurationClass(); > {code} > after > {code} > /** > * @return Get link configuration group class > */ > public abstract LinkConfiguration getLinkConfigurationClass(); > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)