On Jul 2, 2013, at 2:19 PM, Saminda Wijeratne <[email protected]> wrote:
> Are we not going to allow using the GFac libraries as standalone tool? It > could be useful for devs who dont want to use the workflow context to run > applications. I would vote against direct use of GFac API from clients. We need to brainstorm and decide on the component level API's and their implications once we discuss Airavata 1.0( may be also 2.0) roadmaps. In short, I see the need for GFac API's to evolve to facilitate more dynamism and multi-phased interactions between workflow interpreter and GFac. I think we should limit all client integrations to Airavata API so we can put in extra effort to ensure backward compatibility is maintained within major versions. Suresh > On Tue, Jul 2, 2013 at 9:53 AM, Lahiru Gunathilake <[email protected]>wrote: > >> It's not required now. Please remove it. >> >> >> Lahiru >> >> On Tuesday, July 2, 2013, Amila Jayasekara wrote: >> >>> Hi All, >>> >>> In GFacUtils I see methods like follows; >>> >>> public static void >> updateApplicationJobStatusUpdateTime(JobExecutionContext >>> context, String jobId, Date statusUpdateTime){ >>> AiravataAPI airavataAPI = >>> context.getGFacConfiguration().getAiravataAPI(); >>> if(airavataAPI != null){ >>> try { >>> >>> >> airavataAPI.getProvenanceManager().updateApplicationJobStatusUpdateTime(jobId, >>> statusUpdateTime); >>> } catch (AiravataAPIInvocationException e) { >>> log.error("Error in updating application job status time >>> "+statusUpdateTime.toString()+" for job Id "+jobId+"!!!", e); >>> } >>> } >>> } >>> >>> Any particular reason to have "if(airavataAPI != null)" condition ? >>> >>> Thanks >>> Amila >>> >> >> >> -- >> System Analyst Programmer >> PTI Lab >> Indiana University >>
