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
