+1. Yep is what I meant. Thanks, Manoj
On Fri, Feb 21, 2014 at 1:19 AM, Anjana Fernando <[email protected]> wrote: > Hi guys, > > Yeah, the existing data source component does exactly that. When you > mention a data source in a *-datasources.xml file, you can make it > available as JNDI resource, that is what the following section of a data > source configuration does: > > <jndiConfig> > <name>{RES_NAME}</name> > <!-- optional properties --> > <environment> > <property name="java.naming.factory.initial">{ICS}</property> > <property name="java.naming.provider.url">{PROVIDER_URL}</property> > </environment> > </jndiConfig> > > And as Senaka mentioned, this is how registry and user-manager looks up > its data sources when the server is starting up. Hope this is what Manoj is > looking for. > > Cheers, > Anjana. > > > On Fri, Feb 21, 2014 at 1:00 AM, Senaka Fernando <[email protected]> wrote: > >> Hi Manoj, >> >> Please find the responses inline. >> >> On Thu, Feb 20, 2014 at 8:25 PM, Manoj Fernando <[email protected]> wrote: >> >>> Hi Senaka, >>> >>> What I meant was the scenario of me as an outside developer wanting to >>> add a new datasource for my own carbon component. Right now, just adding >>> the datasource into the xml doesn't make it available as a JNDI resource. >>> You need to do that extra step of reading the XML and attaching that onto >>> the InitialContext (AFAIK). It would be much nicer IMO to have those >>> datasources added into the initialcontext during bootstrap so that whatever >>> component needing to use any of them can simply use the JNDI key to >>> reference. >>> >> >> IINM, you should not be doing this. The JNDI referencing should work from >> any component, webapp etc. We have done nothing special @ the registry >> kernel for instance and if the JNDI referencing works in there it should >> work elsewhere too. Copied Anjana to get this clarified. >> >>> >>> The convenience on system properties would be similar. We can have a >>> config file under repository conf that will get automatically loaded as >>> system properties for any component that might need them. Yes I know we >>> can pass them as startup parameters, but it was basically a suggestion for >>> sysadmin/developer convenience. Nothing major... but just for convenience. >>> >> >> IMHO, it can be a convinience with regards to some use-cases and an >> inconvinience with regards to some others. I think we need to consider the >> pros and cons. There are things like clustering, environment-separation, >> which overrides what (i.e. JAVA_OPTS vs this file) etc that we need to >> think about. Will add some points later. >> >> Thanks, >> Senaka. >> >>> >>> Regards, >>> Manoj >>> >>> >>> On Thu, Feb 20, 2014 at 11:14 PM, Senaka Fernando <[email protected]>wrote: >>> >>>> Hi Manoj, >>>> >>>> Datasources can be referenced by JNDI key even now. This is how it >>>> works in Registry Kernel and UM. Is it done in some other way in carbon >>>> components? >>>> >>>> And, for system properties, you can pass these through the >>>> wso2server.sh/bat. I see no benefit of having a separate component to >>>> do just that. Am I missing something here? >>>> >>>> Thanks, >>>> Senaka. >>>> >>>> >>>> On Thu, Feb 20, 2014 at 6:37 PM, Manoj Fernando <[email protected]>wrote: >>>> >>>>> My thoughts were basically on the scenario of which a developer >>>>> (perhaps a client) may want to develop a new carbon component (for >>>>> example) >>>>> and use a separate datasource for persistence. If we can pre-load ALL >>>>> datasources into an initial context, we will not have to write the context >>>>> initialization code outside that component IMO. We can simply reference >>>>> the JNDI without having to modify any datasource init code. >>>>> >>>>> I think same applies for loading system properties. If we have a >>>>> carbon component which will pre-load all application specific system >>>>> properties, a component developer will just have to reference it. >>>>> >>>>> Regards, >>>>> Manoj >>>>> >>>>> >>>>> On Thu, Feb 20, 2014 at 5:25 PM, Sumedha Rubasinghe >>>>> <[email protected]>wrote: >>>>> >>>>>> We allow defining data sources @ two levels targeting two different >>>>>> audiences. >>>>>> >>>>>> Type1: >>>>>> Data sources defined in master-datasources.xml are used for server's >>>>>> internal storage requirements. This includes data source definitions like >>>>>> Registry database, User Store, etc. These data sources are modified by >>>>>> developers working on components for Carbon Servers. >>>>>> >>>>>> Type2: >>>>>> Then we also have data source defining capabilities for developers >>>>>> who will be using Carbon platform to write applications. This >>>>>> capabilities >>>>>> are exposed by WSO2 RSS (Relational Storage Server) & WSO2 AF. >>>>>> These data sources are dynamically loaded. >>>>>> >>>>>> So I feel it's acceptable for Type1 not to be loaded dynamically & >>>>>> Type2 to be loaded dynamically. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 20, 2014 at 4:20 PM, Manoj Fernando <[email protected]>wrote: >>>>>> >>>>>>> Was wondering if it makes sense to dynamically load ALL datasources >>>>>>> defined in master-datasources.xml during bootstrap (well... we could >>>>>>> perhaps build an enable/disable switch on the config). >>>>>>> >>>>>>> Will be a useful feature when we may want to segregate various >>>>>>> elements that need to be persisted at different stores. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Manoj >>>>>>> >>>>>>> -- >>>>>>> Manoj Fernando >>>>>>> Director - Solutions Architecture >>>>>>> >>>>>>> Contact: >>>>>>> LK - +94 112 145345 >>>>>>> Mob: +94 773 759340 >>>>>>> www.wso2.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> /sumedha >>>>>> b : bit.ly/sumedha >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Manoj Fernando >>>>> Director - Solutions Architecture >>>>> >>>>> Contact: >>>>> LK - +94 112 145345 >>>>> Mob: +94 773 759340 >>>>> www.wso2.com >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com >>>> >>>> >>>> >>>> * Member; Apache Software Foundation; http://apache.org >>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>> >>>> >>>> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In: >>>> http://linkedin.com/in/senakafernando >>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Manoj Fernando >>> Director - Solutions Architecture >>> >>> Contact: >>> LK - +94 112 145345 >>> Mob: +94 773 759340 >>> www.wso2.com >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >> Senior Technical Lead; WSO2 Inc.; http://wso2.com >> >> >> >> * Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > > > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- Manoj Fernando Director - Solutions Architecture Contact: LK - +94 112 145345 Mob: +94 773 759340 www.wso2.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
