On Tue, Sep 20, 2011 at 4:56 PM, Aleksander Slominski <[email protected]>wrote:
> I think XML schema should be authoritative as it allows to check contract > (is XML config valid) and to use other than Java tools to manipulate XML. > > Ideally POJOs should be generated from XML Schema and if it can nto be done > then we should keep it documented why ... > +1 Lahiru > > Thanks, > > Alek > > On Tue, Sep 20, 2011 at 9:56 AM, Heshan Suriyaarachchi < > [email protected]> wrote: > > > Hi Patanachai, > > > > Thanks for providing detailed explanations to my questions. Please refer > my > > inline comments. > > > > On Tue, Sep 20, 2011 at 1:21 AM, [email protected] < > > [email protected]> wrote: > > > > > Hi Heshan, > > > > > > I will try to answer your question. I don't quite get what you mean by > > > "improve Schema or keep POJO as it is" (in 2,3). > > > Does it means "to improve XML Schema with a different approach to solve > > the > > > problem" or "to improve XML Schema to generated a class as POJO is" ? > > > > > I am asking the question whether to improve the Schema to solve the > problem > > OR use the current Schema as it is and keep the additional > functionalities > > on POJOs only? We should come to a conclusion on how to proceed forward. > > > > If I understood correctly, "to improve XML Schema to generated a class > as > > POJO is" means that you are kind of expecting the XML Schema generated > POJO > > to be as same as the current POJO that we are using (eg. HostDescription) > ? > > IMV I dont think that is possible. You can not ask XMLBeans to generate a > > custom class template (as in HostDescription.java) that we want. When we > > give a XML Schema to XMLBeans, it will generate a set of POJOs which they > > are expecting to generate. We can use those generated POJOs and > manipulate > > XML within our codebase. Please refer the sample [2] which I added to > > demonstrate the use of current XMLBean generated POJOs. > > > > > However, If we use XML schema, we should not maintain POJOs anymore (we > > > will > > > use Class which is generated from XMLBean only). > > > > > Can you refer the patch, I attached for [1] and see whether we can go > ahead > > with an approach like that? In that patch, we are updating the > > HostDescription POJO to use the XMLBean generated POJOs. > > > > > > > > > > > 1) Right now, there is no other way to create these descriptions (Host, > > > Application, Service) except by coding, which is the current test case. > > > Ideally, these descriptions will created and inserted into "Repository" > > > from > > > users via some GUI (Swing XBaya, web base, etc.). GFac will loaded > these > > > descriptions from "Repository" and used it to execute application. > > > > > > > > > 2) I think we should extend XML Schema to support those attributes. > > Either > > > building a new solution or generating a exact POJO is fine. > > > The problem, POJO tries to solve here, is we need to determine how to > > > choose > > > a correct "Provider" to execute an application. Ideally, Gfac uses > object > > > type to decide what and how to do with the service. For example, If > > actual > > > type of ApplicationDeploymentDescription is ShellApplicationDeployment, > > it > > > will use LocalProvider to execute job on localhost or SSHProvider to > > > execute > > > job on a remote host. If it is GramApplicationDeployment, it will use > > > GramProvider to submit a job to a Gram Endpoint. > > > > > > > > > 3) This one is a bigger problem. Right now, Parameter Class is used as > > > "Actual" Input and Output Definition to GFAC-Service. For example, if > we > > > have a integer array type as input and output, from the POJO, we will > > > have *IntegerArrayParameter > > > *Class. This object will be constructed and passed as an input to > > > GFac-Service. Ideally, user give an input via GUI as a string e.g. > > > [1,3,4,5,8,10] or (1,2,3,4,5), this input is parsed and converted to * > > > IntegerArrayParameter* by a method defined in > > > *IntegerArrayParameter*itself. With the same problem, we also need to > > > consider how to convert the > > > output from application package (scientific application) to Java > Object, > > so > > > that it can be used in GFac. There are many points in the execution > flow > > > where a string and java object is converted back and forth > > (Serialization). > > > I think that XML scheme has "pattern" attribute but I don't know if it > > fits > > > in this model. > > > > > > 4) I'm not sure. If we want, we can add "OS" as an attribute to Host > > > Description or we can cut out support for Windows. However, if you > change > > > all data in a test case in GFac-Core (*PropertiesBasedServiceImplTest*) > > to > > > Windows format. If your machine running a test case is Windows, It will > > > work (because Java Class is used to launch a process and it supports > > > Windows). > > > For example, > > > setExecutable("c:\\windows\\echo.bat") > > > setTmpDir("c:\\temp") > > > setWorkingDir("c:\\user\\a") > > > setInputDir("c:\\user\\a\\mydocument\\input") > > > setOutputDir("c:\\user\\a\\mydocument\\output") > > > > > > > > > > > > -- > > > Best Regards, > > > Patanachai Tangchaisin > > > > > > > > > > > -- > > Regards, > > Heshan Suriyaarachchi > > > > http://heshans.blogspot.com/ > > > -- System Analyst Programmer PTI Lab Indiana University
