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 ... 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/ >
