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 <[email protected]> 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 <[email protected]>wrote: > >> >> >> On Friday, February 21, 2014, Kasun Gajasinghe <[email protected]> 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 <[email protected]>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 <[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 >>> >>> *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 Maharachchi* >> Senior Technical Lead >> WSO2, Inc.; http://wso2.com >> >> Blog: http://maharachchi.blogspot.com >> Mobile: +94719371446 >> >> >> >> _______________________________________________ >> 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 > > -- *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
