[
https://issues.apache.org/jira/browse/LENS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263942#comment-14263942
]
Himanshu Gahlaut edited comment on LENS-123 at 1/4/15 7:27 PM:
---------------------------------------------------------------
Have a look at below code and let me know if it limits extensibility:
{code:title=driver-site.xml}
<configuration>
<drivers>
<!-- properties of a postgress driver running on host1 -->
<driver>
<class>org.apache.lens.driver.PostgresDriver</class>
<pg_conf1>xyz1</pg_conf1>
<pg_conf2>pqr1</pg_conf2>
</driver>
<!-- properties of a db2 driver running on host1 -->
<driver>
<class>org.apache.lens.driver.DB2</class>
<db2_conf1>xyz2</db2_conf1>
<db2_conf2>pqr3</db2_conf2>
<db2_conf3>abc3</db2_conf3>
</driver>
<!-- properties of a postgress driver running on host2 -->
<driver>
<class>org.apache.lens.driver.PostgresDriver</class>
<db2_conf1>xyz2</db2_conf1>
<db2_conf2>pqr3</db2_conf2>
<db2_conf3>abc3</db2_conf3>
</driver>
</drivers>
</configuration>
{code}
{code:java}
// Lens server code (For extensibility. This code should not change on
addition of a new driver.)
XMLConfiguration xmlConf = new XMLConfiguration("driver-site.xml");
List<HierarchicalConfiguration> driverConfs =
xmlConf.configurationsAt("drivers.driver");
for (HierarchicalConfiguration driverConf : driverConfs) {
String className = driverConf.getString("class"); // get the
driver class which is an implementation of LensDriver interface
Class<?> clazz = Class.forName(className);
LensDriver driver = (LensDriver) clazz.newInstance(); // create an
instance of implementation of driver
driver.configure(driverConf); // call configure on it
// Store the driver instance for later use while query execution
}
{code}
// New PostgresDriver implements Configure method
{code:java}
public void configure(HierarchicalConfiguration driverConf) {
// Postgress Driver will read properties which are specific to driver
and use them to configure itself
System.out.println(driverConf.getString("pg_conf1"));
System.out.println(driverConf.getString("pg_conf2"));
}
{code}
Similary, add a driver element for db2 in driver-site.xml with new set of
properties. write a DB2 driver implementation class and add it in classpath
without changing lens server code.
{code:java}
public void configure(HierarchicalConfiguration driverConf) {
// DB2 Driver will read properties which are specific to it and use
them to configure itself
System.out.println(driverConf.getString("db2_conf1"));
System.out.println(driverConf.getString("db2_conf2"));
System.out.println(driverConf.getString("db2_conf3"));
}
{code}
While using a structured config, we don't even need the attributes driver name
and driver type. I just used them in earlier config file to enhance readability
and, if present, they can be used in logging in code while sending queries to a
driver instance to facilitate better logs.
Let me know if I missed something with respect to extensibility. Please keep
posting more doubts as well. We can together create a solution which is both
maintainable and extensible.
was (Author: himanshu.gahlaut):
Have a look at below code and let me know if it limits extensibility:
{code:title=driver-site.xml}
<configuration>
<drivers>
<!-- properties of a postgress driver running on host1 -->
<driver>
<class>org.apache.lens.driver.PostgresDriver</class>
<pg_conf1>xyz1</pg_conf1>
<pg_conf2>pqr1</pg_conf2>
</driver>
<!-- properties of a db2 driver running on host1 -->
<driver>
<class>org.apache.lens.driver.DB2</class>
<db2_conf1>xyz2</db2_conf1>
<db2_conf2>pqr3</db2_conf2>
<db2_conf3>abc3</db2_conf3>
</driver>
<!-- properties of a postgress driver running on host2 -->
<driver>
<class>org.apache.lens.driver.PostgresDriver</class>
<db2_conf1>xyz2</db2_conf1>
<db2_conf2>pqr3</db2_conf2>
<db2_conf3>abc3</db2_conf3>
</driver>
</drivers>
</configuration>
{code}
{code:java}
// Lens server code (For extensibility. This code should not change on
addition of a new driver.)
XMLConfiguration xmlConf = new XMLConfiguration("test.xml");
List<HierarchicalConfiguration> driverConfs =
xmlConf.configurationsAt("drivers.driver");
for (HierarchicalConfiguration driverConf : driverConfs) {
String className = driverConf.getString("class"); // get the
driver class which is an implementation of LensDriver interface
Class<?> clazz = Class.forName(className);
LensDriver driver = (LensDriver) clazz.newInstance(); // create an
instance of implementation of driver
driver.configure(driverConf); // call configure on it
// Store the driver instance for later use while query execution
}
{code}
{code:java}
public void configure(HierarchicalConfiguration driverConf) {
// Postgress Driver will read properties which are specific to driver
and use them to configure itself
System.out.println(driverConf.getString("pg_conf1"));
System.out.println(driverConf.getString("pg_conf2"));
}
{code}
Similary, add a driver element for db2 in driver-site.xml with new set of
properties. write a DB2 driver implementation class and add it in classpath
without changing lens server code.
{code:java}
public void configure(HierarchicalConfiguration driverConf) {
// DB2 Driver will read properties which are specific to it and use
them to configure itself
System.out.println(driverConf.getString("db2_conf1"));
System.out.println(driverConf.getString("db2_conf2"));
System.out.println(driverConf.getString("db2_conf3"));
}
{code}
While using a structured config, we don't even need the attributes driver name
and driver type. I just used them in earlier config file to enhance readability
and, if present, they can be used in logging in code while sending queries to a
driver instance to facilitate better logs.
Let me know if I missed something with respect to extensibility. Please keep
posting more doubts as well. We can together create a solution which is both
maintainable and extensible.
> Ability to load different instances of same driver class
> --------------------------------------------------------
>
> Key: LENS-123
> URL: https://issues.apache.org/jira/browse/LENS-123
> Project: Apache Lens
> Issue Type: Improvement
> Components: server
> Reporter: Amareshwari Sriramadasu
> Assignee: Himanshu Gahlaut
> Fix For: 2.0
>
>
> Currently we are loading only one driver instance per class. We should be
> able to load multiple different instances of a driver class.
> For example, There can be multiple HiveDrivers talking to different
> HiveServers sitting on each colo. Or different JDBCDrivers talking to
> different dbs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
