I moved the code to data-model and used it in orchestrator. What are we going to do with un-used set of Exceptions ?
On Sun, May 18, 2014 at 5:58 PM, Chathuri Wimalasena <[email protected]>wrote: > +1 to move exception classes to data-models module. > > > On Sun, May 18, 2014 at 9:57 AM, Lahiru Gunathilake <[email protected]>wrote: > >> Hi all, >> >> When I went through the exception handling in thrift services I see we >> have bunch of exception types defined in thrift and non of them are really >> thrown in any of the service operations. >> All these exceptions are stored in airavata-api-stubs module and >> airavata-api-server is having a dependency to airavata-api-stubs. Having a >> dependency to stub from the service is little awkward to me in web services >> point but I am not sure about thrift. If this is wrong I think we have to >> move this common code to some other place. >> >> Issue comes when I try to implement orchestrator validateExperiment >> operation where I have to throw an experiment defined in airavata-api-stubs >> and it was little awkward to have a dependency to airavata-api-stubs from >> orchestrator-server and orchestrator-client. Same exception has to be >> thrown by the airavata-server's launchExperiment method. I think these >> exception classes and common code can go to data-models module which is >> shared across both the orchestrator and airavata-server thrift services. >> >> Please correct me if I am wrong. >> >> Lahiru >> >> -- >> System Analyst Programmer >> PTI Lab >> Indiana University >> > > -- System Analyst Programmer PTI Lab Indiana University
