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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
