Hi Lahiru, I agree we need to have this within the data-model instead of the stubs. But did you move the generated code? Instead we need to shuffle the thrift description for these errors accordingly. I will be happy to make the change.
Suresh On May 19, 2014, at 11:54 AM, Lahiru Gunathilake <[email protected]> wrote: > 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
