I believe the issue here is that the JNDi context won't be available for a
carbon component/bundle until the org.wso2.carbon.ndatasource.core bundle
is activated during server startup. Any bundle that gets activated before
this bundle won't see the JNDi contexts. I think Manoj is facing that issue
here.
AFAIK, there isn't a way to specify the bundle order. So, one option is to
write a o.w.c.core.ServerStartupHandler which will get invoked after the
server starts up successfully. By that time, the JNDi contexts etc. will be
available. Is there any other option?
Regards,
KasunG
On Fri, Feb 21, 2014 at 1:19 AM, Anjana Fernando <anj...@wso2.com> 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 <sen...@wso2.com> wrote:
>
>> Hi Manoj,
>>
>> Please find the responses inline.
>>
>> On Thu, Feb 20, 2014 at 8:25 PM, Manoj Fernando <man...@wso2.com> 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 <sen...@wso2.com>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 <man...@wso2.com>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
>>>>> <sume...@wso2.com>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 <man...@wso2.com>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
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> /sumedha
>>>>>> b : bit.ly/sumedha
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> 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
>>>>> Architecture@wso2.org
>>>>> 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
>>>> Architecture@wso2.org
>>>> 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
>>> Architecture@wso2.org
>>> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Kasun Gajasinghe*
Software Engineer;
WSO2 Inc.; http://wso2.com
,
*email: *
*kasung AT spamfree wso2.com <http://wso2.com> ** cell: **+94 (77)
678-0813*
*linked-in: *http://lk.linkedin.com/in/gajasinghe
*blog: **http://kasunbg.org* <http://kasunbg.org>
*twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
