[Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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 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 -- *[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.orgE-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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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.comwrote: 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
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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.comwrote: 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.orgE-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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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. 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. 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.comwrote: 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.orgE-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
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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.comwrote:
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.comwrote:
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.comwrote:
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
___
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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.comwrote:
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.comwrote:
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.comwrote:
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
[Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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 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?
You can delay the bundle activation by using a osgi service dependency to
ndatasource core (if it has registered one). Then the bundle won't get
activated until ndatasource core is active.
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
*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
--
*Amila Maharachchi*
Senior Technical Lead
WSO2, Inc.; http://wso2.com
Blog: http://maharachchi.blogspot.com
Mobile: +94719371446
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Dynamically load data sources defined on master-datasources.xml on startup
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 getting activated
after ndatasource.
Cheers,
Anjana.
On Fri, Feb 21, 2014 at 8:57 AM, Manoj Fernando man...@wso2.com wrote:
I didn't really face that issue, but thanks for pointing out. Since I used
the dependency config from the previous throttle component on my pom.xml,
the activation order would have worked correctly.
Regards,
Manoj
On Fri, Feb 21, 2014 at 8:45 AM, Amila Maha Arachchi ami...@wso2.comwrote:
On Friday, February 21, 2014, Kasun Gajasinghe 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 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?
You can delay the bundle activation by using a osgi service dependency to
ndatasource core (if it has registered one). Then the bundle won't get
activated until ndatasource core is active.
Regards,
KasunG
On Fri, Feb 21, 2014 at 1:19 AM, Anjana Fernando anj...@wso2.comwrote:
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.comwrote:
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.comwrote:
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
*Kasun Gajasinghe*
Software Engineer;
WSO2 Inc.; http://wso2.com
,
*email: *
*kasung AT spamfree wso2.com http://wso2.com ** cell: **+94 (77)
678-0813 %2B94%20%2877%29%20678-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
--
*Amila
[Architecture] [AppFactory] Changing the artefact Id in pom.xml breaks the AF functionality
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 * artifactIdbar/artifactId* * version1.0.0/version* * packagingwar/packaging* namebar/name descriptionbar/description *Why AF functionality breaks if someone changed the above highlighted entries?* We set the applicationId as the artifact Id. This is the unique identifier for applications developed using AF. Currently this applicationId is being used in many places in AF code base. Examples, to provision application in source repository, issue tracker and in build tool, to isolate application from another application in the context of resource isolation, security. And version is used to identify correct branch, issues related to given branch and so on. In future, application resource versioning too come into the picture. If we change the packaging type, it causes failures at deployment time where we identify application type using packaging type. This cause us to prevent users modifying above entries. How to achieve this? 1. We inform the user that these entries are non-modifiable by adding a comment in pom.xml. But this won't handle mistakes by the developers. 2. We can implement a git pre-commit hook to validate if above entries are changed and abort committing. 3. For non-buildable application types such as jaggery, php we remove the entire pom.xml when generating the initial code.(currently pom.xml is present in jaggery apps). Another related issue where current AF functionality breaks is when developers change the current application context by introducing it in web.xml. However this is not supported by web app deployer. So we do not need to consider this scenario. And since we support uploading war files to AF and create an application, we do the validation to make sure that war file name is matched with applicationId. If that is different, we get the confirmation from user to change the war file name or applicationId without moving forward. This might cause usability issues such as not being able to get a friendly name for their applications in case of single tenant contains lot of applications. However, we are planning to provide URL mapping functionality so application can be accessed with an end user friendly link. Please share your thought on this. thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
