[ 
https://issues.apache.org/jira/browse/LENS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946577#comment-14946577
 ] 

Puneet Gupta edited comment on LENS-123 at 10/7/15 9:27 AM:
------------------------------------------------------------

Approach-1**********************************************************
        -Folders
                --Driver 
                        ---driver1
                                ----driver1-site.xml
                        ---driver2
                                ----driver2-site.xml

        DriverFactory 
                scans Individual Driver folders and reads site.xml to get 
Driver class Name 
                Inits Driver via reflection 
                The Initialized driver reads <default-driver>-site.xml and 
<driver>-site.xml 
        
Pros 
                - Plug and play 
                - Everything specific to a driver is contained in Driver's own 
directory

        Cons 
                - <driver>-site.xml is read twice , once by factory to get 
driver class and once by driver itself 
                - if we have 5 jdbc drivers, We would be reading the same class 
name mapping 5 times (once from each driver site.xml) 

Approach-2**********************************************************
                -Folders
                        --Driver 
                                ---hive 
                                        ----driver1
                                                -----driver1-site.xml
                                        ----driver2
                                                -----driver2-site.xml
                                ---jdbc
                                        ----driver1
                                                -----driver1-site.xml
                
DriverFactory 
                        The lens-site.xml has a mapping for triver type and 
class Name  
(hive:org.apache.lens.driver.hive.HiveDriver,jdbc:org.apache.lens.driver.jdbc.JDBCDriver)
                       
                        DriverFactroy initailizes drivers for each listed type.

                Pros
                        - <driver>-site.xml will be read only once . 

                Cons 
                        - Driver type and folder name should match 
                        - Partially plug and play. New drivers form same type 
can be added without making any configuration changes. But a new driver type 
will have to be updated in lens-site.xml first . 
   

Approach-3 **********************************************************
                -Folders 
                        --Driver 
                                ---driver1
                                        ----driver1-site.xml
                                ---driver2
                                        ----driver2-site.xml

                DriverFactory 
                        reads driver-site.xml (a new configration which is in 
CONF directory along with lens-site.xml). All drivers need to be registered 
here first. Registeration can have driver_type,driver_folder(optional if path 
is diff from implied path),driver_class. 
                        DriverFactroy initializes each registered driver.

                Pros
                        - Clean approach . No preconditions (like in approach 2 
, driver type folder name should match registered driver type in lens-site.xml)

                Cons 
                        - Not plug and play. Have to update the driver-site.xml 
for each new driver 





was (Author: puneet884):
Approach-1**********************************************************
        -Folders
                --Driver 
                        ---driver1
                                ----driver1-site.xml
                        ---driver2
                                ----driver2-site.xml

        DriverFactory 
                scans Individual Driver folders and reads site.xml to get 
Driver class Name 
                Inits Driver via reflection 
                The Initialized driver reads <default-driver>-site.xml and 
<driver>-site.xml 
        Pros 
                - Plug and play 
                - Everything specific to a driver is contained in Driver's own 
directory

        Cons 
                - <driver>-site.xml is read twice , once by factory to get 
driver class and once by driver itself 
                - if we have 5 jdbc drivers, We would be reading the same class 
name mapping 5 times (once from each driver site.xml) 

Approach-2**********************************************************
                Folders
                        -Driver 
                                --hive 
                                        ---driver1
                                                ----driver1-site.xml
                                        ---driver2
                                                ----driver2-site.xml
                                --jdbc
                                        ---driver1
                                                ----driver1-site.xml
                DriverFactory 
                        The lens-site.xml has a mapping for triver type and 
class Name  
(hive:org.apache.lens.driver.hive.HiveDriver,jdbc:org.apache.lens.driver.jdbc.JDBCDriver)
                       
                        DriverFactroy initailizes drivers for each listed type.
                Pros
                        - <driver>-site.xml will be read only once . 
                Cons 
                        - Driver type and folder name should match 
                        - Partially plug and play. New drivers form same type 
can be added without making any configuration changes. But a new driver type 
will have to be updated in lens-site.xml first . 
   

Approach-3 **********************************************************
                -Folders 
                        --Driver 
                                ---driver1
                                        ----driver1-site.xml
                                ---driver2
                                        ----driver2-site.xml

                DriverFactory 
                        reads driver-site.xml (a new configration which is in 
CONF directory along with lens-site.xml). All drivers need to be registered 
here first. Registeration can have driver_type,driver_folder(optional if path 
is diff from implied path),driver_class. 
                        DriverFactroy initializes each registered driver.

                Pros
                        - clean approach . No preconditions (like in approach 2 
, driver type folder name should match registered driver type in lens-site.xml)
                Cons 
                        - Not plug and play. Have to update the driver-site.xml 
for each new driver 




> 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: New Feature
>          Components: server
>            Reporter: Amareshwari Sriramadasu
>            Assignee: Puneet Gupta
>              Labels: Hackathon-July
>
> 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)

Reply via email to