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; ext: 51736*;


*M: +94 77 322 1818 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

Reply via email to