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
Hi Manoj,
Are you discussing this WRT a mult-regional deployment of stores? Or is it
in the context of something else?
Thanks,
Senaka.
On Thu, Feb 20, 2014 at 12:50 PM, Manoj Fernando man...@wso2.com wrote:
Was wondering if it makes sense to dynamically load ALL datasources
defined in
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
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
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
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
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
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
On Friday, February 21, 2014, Kasun Gajasinghe
kas...@wso2.comjavascript:_e(%7B%7D,'cvml','kas...@wso2.com');
wrote:
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
Hi Manoj,
Just having a dependency in the pom.xml does not guarantee the ordering, it
is a build time dependency .. maybe you're using some other OSGi service
which in-turn transitively uses the ndatasource OSGi service somewhere, or
else, most probably, it is by chance, that your bundle is
Hi all,
$Subject happens in current released packs. We are addressing this issue in
M12(next milestone).
Current pom.xml as below. We have to make sure that below highlighted
entries are not changed by developers even by mistakes.
modelVersion4.0.0/modelVersion
groupIdorg.wso2.af/groupId
*
11 matches
Mail list logo
