On Tue, Jan 22, 2013 at 10:58 PM, Anjana Fernando <anj...@wso2.com> wrote:
> Hi guys, > > Sure, this can be put as a separated component. As Pradeep said, > internally in the Kernel, we just use JNDI lookups to get the data sources > (for Registry/UM), so we are not directly dependent on it, i.e. someone > could use the Carbon Kernel and another mechanism to register the JNDI data > sources. > > When this refactoring is done, do make sure that this component activates > properly before Registry/UM, because those JNDI data sources should be > there the earliest. The initialization happens in two parts, where the > ndatasource initializes enough to get the system data sources up (which are > read from *-datasources.xml), and after the Registry is initialized, it > in-turn uses the registry to read in user data sources and register them. > In the carbon core level we need only the first part which reads the datasources.xml file and register the data source with the JNDI. We can keep the Registry based one and the UI part in a separate carbon component. For the moment lets have only the datasource.xml read part and see how to proceed with other part. thanks, Amila. > > So then, the other issue mentioned by Amila for the data source component > to be independent of Axis2, we need a common clustering component which > defined an abstraction layer, where there probably can be pluggable > implementations like Axis2 Tribes clustering or something based on > Hazelcast and so on, so we will not bind to a specific library. I'm > guessing Azeez was working on the Hazelcast based implementation, he would > have more info on that. > > Cheers, > Anjana. > > > On Tue, Jan 22, 2013 at 3:55 AM, Amila Suriarachchi <am...@wso2.com>wrote: > >> >> >> On Tue, Jan 22, 2013 at 5:16 PM, Pradeep Fernando <prad...@wso2.com>wrote: >> >>> Hi Anjana, >>> >>> I went through the ndatasource code. There we get >>> ConfigurationContextSerice/ServerConfiguration/etc. While searching for >>> their usages found out that we use those references to get clustering >>> agents/registering AxisContextObservers/etc. >>> >>> How hard it is to decouple ndatasource implementation from other kernel >>> dependencies. (we can depend on caching and logging of course) >>> >>> Theoretically what this component does is, populate a datasource and >>> registering it against a JNDI lookup name. So we should be able to make >>> this component kernel independent. >>> >> >> This is the first part of making a minimal carbon kernel. We need to get >> rid of Axis2 dependencies for all carbon kernel components. Is it possible >> to implement this feature using some caching implementation like Hazlecast? >> >> thanks, >> Amila. >> >> >>> >>> your input is highly appreciated. >>> >>> thanks, >>> --Pradeep >>> >>> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> > > > > -- > *Anjana Fernando* > Associate Technical Lead > > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
