Hi Thanuja, +1 for this approach. For the analytics use case especially, the requirement is for the datasources component to fully work in a non-carbon, non-OSGi environment; hence our request to have the relevant services exposed via SPI.
We are not using JNDI to look up datasources at the moment, and consequently that functionality is not critical to us at the moment. What's important is the ability for us to specify an absolute path (from the non-carbon JVM) the location of datasource definitions, and then for the datasources component to natively read and expose the datasource from within this JVM. On a related note, I believe that the secure vault component will also need to go through the same treatment. Thanks. On 5 December 2016 at 15:01, Thanuja Uruththirakodeeswaran < thanu...@wso2.com> wrote: > Hi All, > > I'm currently working on $subject. The carbon datasource component > registers the JNDIContextManager and DataSourceReader services before > initializing datsources using DataSourceManager in an OSGi environment as > in [1]. In order to make the carbon datasource component to be used in > non-OSGi environment as well, the same services have to be made available > using Java SPI before the non-OSGi client makes use of it. > > > - In the existing implementation the DataSourceReader service can be > loaded to non-OSGi environment when initializing datasources using > DataSourceManager's initDataSources()[2] which calls > loadDataSourceProviders()[3] to load the Service Providers of > DataSourceReader SPI. > > > > - In order to register JNDIContextManager service in non-OSGi > environment, the carbon-jndi component implementation has to be modified. > I'm planning to a have separate service provider for JNDIContextManager SPI > so that it can be used in non-OSGi environment like we are using the > JNDIContextManagerImpl[4] for OSGi environment. Then the particular service > provider can be loaded using ServiceLoader and used to do datasource lookup > using the Context in non-OSGi environment. Is this the correct approach to > acces JNDI service in non-OSGi environment? Please give your suggestions. > > [1]. https://github.com/wso2/carbon-datasources/blob/master/ > components/org.wso2.carbon.datasource.core/src/main/java/ > org/wso2/carbon/datasource/core/internal/DataSourceListenerComponent.java > [2]. https://github.com/wso2/carbon-datasources/blob/master/ > components/org.wso2.carbon.datasource.core/src/main/java/ > org/wso2/carbon/datasource/core/DataSourceManager.java#L107-L111 > [3]. https://github.com/wso2/carbon-datasources/blob/master/ > components/org.wso2.carbon.datasource.core/src/main/java/ > org/wso2/carbon/datasource/core/DataSourceManager.java#L177-L182 > [4]. https://github.com/wso2/carbon-jndi/blob/master/compone > nts/org.wso2.carbon.jndi/src/main/java/org/wso2/carbon/ > jndi/internal/osgi/JNDIContextManagerImpl.java > > Thanks. > -- > Thanuja Uruththirakodeeswaran > Software Engineer > WSO2 Inc.;http://wso2.com > lean.enterprise.middleware > > mobile: +94 774363167 <+94%2077%20436%203167> > > <http://wso2.com/signature> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Gokul Balakrishnan Senior Software Engineer, WSO2, Inc. http://wso2.com M +94 77 5935 789 | +44 7563 570502 <+44%207563%20570502>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
