Hi Alek, Although there are classes generated by XML Schema, GFac uses some other bean classes (eg. HostDescription, ApplicationDeploymentDescription, ServiceDescription). So the idea is to generate these bean files from a code generator.
I will be able to submit a initial working version as a patch by next week. On Thu, Sep 1, 2011 at 2:56 PM, Aleksander Slominski <[email protected]>wrote: > The classes generated by Apache XmlBean should be Java Beans containing > proper get/set method for properties. In what context do you need POJO > classes? > > Best, > > Alek > > On Thu, Sep 1, 2011 at 10:38 AM, Lahiru Gunathilake <[email protected] > >wrote: > > > Hi Heshan, > > > > On Wed, Aug 31, 2011 at 9:39 AM, Heshan Suriyaarachchi < > > [email protected]> wrote: > > > > > Hi All, > > > > > > First of all I will explain what I initially started doing. I was going > > to > > > parse the XML Schema using Axiom and extract the important information > > from > > > the schema. Then a template will be created with the use of JET[1]. > When > > > generating POJOs the extracted information from the XML Schema will be > > > inserted to the generated class. > > > > > > While working on the above implementation I came across some concerns. > > > i) The initial objective of doing this was to create the POJO object > from > > > the XML Schema and the current POJOs that GFac is using does not > contain > > > all > > > the information in the XML Schema. eg. Consider the schema > > > HostDescription[2] and the POJO for the HostDescription[3]. > > > > > > ii) Since we are extracting only some elements from the schema, we need > > to > > > know what elements that we are going to extract. > > > > > > iii) The code generation will be based on the template that we create. > So > > > if > > > the Schema is changed or some additional property should be added to > the > > > POJO, then the template should be updated. Therefore, the code > generation > > > will not be that dynamic. So, the concern that I am having is that if > we > > > are > > > to move ahead in this path, why go through the pain of generating > > > templates, > > > just to modify them down the line. It’s better off to write the POJO by > > > hand. I think we are trying to introduce unnecessary complexity in this > > > approach. Please correct me if I am wrong. > > > > > I am +1 for this approach, I do not think the schema will change very > often > > so in general we will not having to change the templates often. Somehow > we > > need to switch to the correct approach of actually using gfac-schema and > > get > > rid of manually written POJOs. I think this approach is having less > > complexity. > > > > Regards > > Lahiru > > > > > > > > iv) One other suggestion is, instead of having manually written POJO > > > classes > > > written for the Schema, why not use the POJOs created by XMLBeans? May > be > > > there was a decision taken to move ahead with that approach. I would > > > appreciate if someone can shed some light into it. > > > > > > Following are some other observations: > > > > > > XML Beans > > > According to the current gfac-schema module, XML Beans is used to > > generate > > > the POJO objects from the GFac XML Schema. I went through the generated > > > classes and did not find a way to extract the list of properties stored > > in > > > a > > > particular POJO. It’s only exposing methods to get or set values > certain > > > properties. Since we can not extract the list of properties, it’ll be > > > difficult to generate a class from it because I need those information > to > > > be > > > inserted into the template. > > > > > > XJC (JaxB) > > > I tried out XJC as well. It’s also generating some POJOs as XML Beans. > I > > > came across some issues while generating POJOs for Schema’s which is > > having > > > imports. The approach to overcome that was to go ahead with XML > Catalogs. > > > Inorder to do that I had to modify the Schema. I did not want to modify > > the > > > Schema and I stopped it there. > > > > > > Axis2Code generator > > > As you might know Axis2Code generator too, uses it’s WSDL to Java tool > to > > > generate Java code. One other option is to look into whether we can use > > > that > > > in here. According to my initial understanding, it will take sometime > to > > > understand that code base and try to extract the logic that we want. > > > Furthermore, we might have to write XSLTs to generate the code as well. > > > > > > Your feedback is much appreciated. > > > > > > [1] - http://www.eclipse.org/modeling/m2t/?project=jet#jet > > > [2] - > > > > > > > > > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/schemas/HostDescription.xsd > > > [3] - > > > > > > > > > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/src/main/java/org/apache/airavata/core/gfac/type/HostDescription.java > > > > > > > > > On Mon, Aug 29, 2011 at 3:57 PM, Heshan Suriyaarachchi < > > > [email protected]> wrote: > > > > > > > Hi Raminder, > > > > > > > > I have not used JAXB before. I will invest some time and look into > JAXB > > > as > > > > well. > > > > > > > > Thanks for the suggestion. > > > > > > > > On Mon, Aug 29, 2011 at 3:29 PM, Raminderjeet Singh < > > > > [email protected]> wrote: > > > > > > > >> I will still recommend to look into JAXB or some library which can > > > handle > > > >> complex types of XSD. POJO's generated using JAXB was simple enough > > and > > > its > > > >> easy to parse the request also. > > > >> > > > >> Here is a simple schema i am working with and generated POJO's but > > this > > > is > > > >> very simple one > > > >> > > > >> > > > >> > > > > > > https://ogce.svn.sourceforge.net/svnroot/ogce/gateway-staging/ultrascan/US3RestServices/schema/GfacMessage.xsd > > > >> > > > >> > > > > > > https://ogce.svn.sourceforge.net/svnroot/ogce/gateway-staging/ultrascan/US3RestServices/src/main/java/org/ogce/gram/job/message/ > > > >> > > > >> > > > >> Thanks > > > >> Raminder > > > >> > > > >> On Aug 29, 2011, at 3:18 PM, Heshan Suriyaarachchi wrote: > > > >> > > > >> > Hi Raminder. > > > >> > > > > >> > Thanks for the feedback. > > > >> > > > > >> > In fact in the current GFac Schema implementation; XMLBeans is > used > > to > > > >> > generate java objects from the XML Schema. This is done using > > > >> > xmlbeans-maven-plugin. The main reason for opting for writing > > > something > > > >> > custom was that the generated POJO classes are complex and hard to > > > work > > > >> > with. The generated POJO should look something like [1]. > > > >> > > > > >> > [1] - > > > >> > > > > >> > > > > > > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/src/main/java/org/apache/airavata/core/gfac/type/ApplicationDeploymentDescription.java > > > >> > > > > >> > On Mon, Aug 29, 2011 at 3:04 PM, Raminderjeet Singh < > > > >> > [email protected]> wrote: > > > >> > > > > >> >> Heshan, > > > >> >> > > > >> >> You can look into JAXB[1] where you can use some thing like below > > to > > > >> >> convert the schema to POJO. I have not tried this with > hierarchical > > > >> XSD's or > > > >> >> XSD with extension which will be good thing to explore > > > >> >> > > > >> >> xjc schema/GfacMessage.xsd -p org.xxx.message -d src/main/java/ > > > >> >> > > > >> >> Thanks > > > >> >> Raminder > > > >> >> > > > >> >> [1] : > > > >> >> > > > >> > > > > > > http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/1.6/jaxb/xjc.html > > > >> >> > > > >> >> On Aug 29, 2011, at 2:12 PM, Heshan Suriyaarachchi wrote: > > > >> >> > > > >> >>> Hi Devs, > > > >> >>> > > > >> >>> Please see my inline comments. > > > >> >>> > > > >> >>> On Sun, Aug 28, 2011 at 9:30 AM, Suresh Marru < > [email protected]> > > > >> wrote: > > > >> >>> > > > >> >>>> Hi All, > > > >> >>>> > > > >> >>>> Looking through the JIRA tickets I see we have addressed some > of > > > the > > > >> >> issues > > > >> >>>> mentioned below and working on few others. Once we capture > > current > > > >> >> status, > > > >> >>>> as Alek mentioned, lets clearly layout a roadmap for this > release > > > and > > > >> >> also > > > >> >>>> for the graduation. Please add/modify to the list. > > > >> >>>> > > > >> >>>> On Jul 31, 2011, at 11:37 PM, Suresh Marru wrote: > > > >> >>>> > > > >> >>>>> Great to see all the progress in the last few weeks. As I see > > it, > > > >> here > > > >> >>>> is a recap here are the next steps before a release: > > > >> >>>>> > > > >> >>>>> * Standardize WS Messenger clients and integrate the axis2 > > ported > > > >> >> clients > > > >> >>>> to XBaya and GFac. > > > >> >>>> --Seems like mostly done, but I think we still need to > integrate > > > and > > > >> >> test > > > >> >>>> this with rest of Airavata. Some TODO's as I see it: > > > >> >>>> • Verify and test Tracking Library > > > >> >>>> • Provide notification Publish, Subscribe with tracking > > > schema. > > > >> >>>> • Change XBaya to use new tracking schema > > > >> >>>> • Add notification to Gfac using new tracking schema > > > >> >>>> • create a notification interface inGFac with Tracking as > > one > > > of > > > >> >> the > > > >> >>>> implementation (if gfac is used outside workflow context) > > > >> >>>>> * Discuss, standardize and update GFac application and > service > > > >> >>>> deployment description schema. > > > >> >>>> * The POJO schema is good for current development, but as > > per > > > >> the > > > >> >>>> discussion in mailing list, we still need to have XML schemas. > > May > > > be > > > >> we > > > >> >> can > > > >> >>>> write utility classes to convert from xml schema to POJO? > > > >> >>>> > > > >> >>> > > > >> >>> I would like to work on Converting XML Schema of GFac to POJO. > In > > > >> fact, I > > > >> >>> have already started working on this. > > > >> >>> > > > >> >>> Currently we have XML Schema defined in the GFac-Schema. The > idea > > > here > > > >> is > > > >> >> to > > > >> >>> create POJO's from the above XML Schema. Currently the POJO > which > > we > > > >> are > > > >> >>> using are not generated. ie. these POJOs are not generated > > > dynamically > > > >> >> from > > > >> >>> the XML Schema. > > > >> >>> > > > >> >>> Following is the way in which I am going to move ahead with the > > > >> >>> developement. > > > >> >>> > > > >> >>> I will write a parser to parse the Schema and extract the > > arguments > > > >> >> needed > > > >> >>> to create the POJO. Then with the use of JET [1] I will be > > > generating > > > >> the > > > >> >>> POJOs. > > > >> >>> > > > >> >>> [1] - http://www.eclipse.org/modeling/m2t/?project=jet#jet > > > >> >>> > > > >> >>>> * Integrate Axis2 based service interface to GFac-Core > > > >> >>>> * I see the basic axis2 interface is done and tested with > > SOAP > > > >> UI. > > > >> >>>> But I think we we still need to test with XBaya. > > > >> >>>> > > > >> >>>>> * Upgrade XBaya WSIF clients from XSUL to Axis2 based WSIF > > > clients. > > > >> >>>> * I think XSUL WSIF clients are working well, may be we > can > > > >> defer > > > >> >>>> AXIS2 clients for future? > > > >> >>>>> * Upgrade GSI Security libraries > > > >> >>>> * I think we should focus on the integrated all moving > > > >> components > > > >> >> of > > > >> >>>> Airavata and defer any individual component upgrades. > > > >> >>>>> * Provide simple to use samples to try out Airavata. > > > >> >>>> * We need to provide lot of samples and associated > > > documentation > > > >> >>>>> * Package, document and release airavata incubating release v > > 0.1 > > > >> >>>> * The builds have evolved, but we still need to have one > > click > > > >> >>>> integrated build and deploy > > > >> >>>> * The weakest point I think is documentation, once we get > a > > > >> >> feature > > > >> >>>> freeze, should we pause development and run a sprint of > > > >> documentation? > > > >> >>>> > > > >> >>>> Thanks, > > > >> >>>> Suresh > > > >> >>>> > > > >> >>>>> > > > >> >>>>> Please correct/update to the list. > > > >> >>>>> > > > >> >>>>> Cheers, > > > >> >>>>> Suresh > > > >> >>>>> > > > >> >>>>> On May 13, 2011, at 8:37 AM, Suresh Marru wrote: > > > >> >>>>> > > > >> >>>>>> Hi All, > > > >> >>>>>> > > > >> >>>>>> All of us clearly know what Airavata software is about in > > varying > > > >> >>>> details, but at the same time I realize not every one of us on > > the > > > >> list > > > >> >>>> have a full understanding of the architecture as a whole and > > > >> >> sub-components. > > > >> >>>> Along with inheriting the code donation, I suggest we focus on > > > >> bringing > > > >> >>>> every one to speed by means of high level and low level > > > architecture > > > >> >>>> diagrams. I will start a detailed email thread about this task. > > In > > > >> >> short, > > > >> >>>> currently the software assumes understanding of e-Science in > > > general > > > >> and > > > >> >>>> some details of Grid Computing. Our first focus should be to > > bring > > > >> the > > > >> >>>> software to a level any java developer can understand and > > > contribute. > > > >> >> Next > > > >> >>>> the focus can be to make it easy for novice users. > > > >> >>>>>> > > > >> >>>>>> I thought a good place to start might be to list out the high > > > level > > > >> >>>> goals and then focus on the first goal with detailed JIRA > tasks. > > I > > > am > > > >> >>>> assuming you will steer us with a orthogonal roadmap to > > graduation. > > > I > > > >> >> hope I > > > >> >>>> am not implying we need to meet the following goals to > graduate, > > > >> because > > > >> >>>> some of them are very open ended. Also, please note that > Airavata > > > may > > > >> >> have > > > >> >>>> some of these features already, I am mainly categorizing so we > > will > > > >> have > > > >> >> a > > > >> >>>> focused effort in testing, re-writing or new implementations. > > > >> >>>>>> > > > >> >>>>>> Airavata high level feature list: > > > >> >>>>>> > > > >> >>>>>> Phase 1: Construct, Execute and monitor workflows from > > > pre-deployed > > > >> >> web > > > >> >>>> services. The workflow enactment engine will be the inherent > > > Airavata > > > >> >>>> Workflow Interpreter. Register command line applications as web > > > >> >> services, > > > >> >>>> construct and execute workflows with these application > services. > > > The > > > >> >>>> applications may run locally, on Grid enabled resources or by > > > ssh'ing > > > >> to > > > >> >> a > > > >> >>>> remote resource. The client to test this phase workflows can be > > > >> Airavata > > > >> >>>> Workflow Client (XBaya) running as a desktop application. > > > >> >>>>>> > > > >> >>>>>> Phase 2: Execute all of phase 1 workflows on Apache ODE > engine > > by > > > >> >>>> generating and deploying BPEL. Develop and deploy gadget > > interfaces > > > >> to > > > >> >>>> Apache Rave container to support application registration, > > workflow > > > >> >>>> submission and monitoring components. Support applications > > running > > > on > > > >> >>>> virtual machine images to be deployed to Amazon EC2, EUCALYPTUS > > and > > > >> >> similar > > > >> >>>> infrastructure-as-a-service cloud deployments. > > > >> >>>>>> > > > >> >>>>>> Phase 3: Expand the compute resources to Elastic Map Reduce > > and > > > >> >> Hadoop > > > >> >>>> based executions. Focus on the data and metadata catalog > > > integration > > > >> >> like > > > >> >>>> Apache OODT. > > > >> >>>>>> > > > >> >>>>>> I will stop here, to allow us to discuss the same. Once we > > narrow > > > >> down > > > >> >>>> on the high level phase 1 goals, I will start a detailed > > discussion > > > >> on > > > >> >> where > > > >> >>>> the code is now and the steps to get to goal1. > > > >> >>>>>> > > > >> >>>>>> Comments, Barbs? > > > >> >>>>>> > > > >> >>>>>> Suresh > > > >> >>>>> > > > >> >>>> > > > >> >>>> > > > >> >>> > > > >> >>> > > > >> >>> -- > > > >> >>> Regards, > > > >> >>> Heshan Suriyaarachchi > > > >> >>> > > > >> >>> http://heshans.blogspot.com/ > > > >> >> > > > >> >> > > > >> > > > > >> > > > > >> > -- > > > >> > Regards, > > > >> > Heshan Suriyaarachchi > > > >> > > > > >> > http://heshans.blogspot.com/ > > > >> > > > >> > > > > > > > > > > > > -- > > > > Regards, > > > > Heshan Suriyaarachchi > > > > > > > > http://heshans.blogspot.com/ > > > > > > > > > > > > > > > > -- > > > Regards, > > > Heshan Suriyaarachchi > > > > > > http://heshans.blogspot.com/ > > > > > > > > > > > -- > > System Analyst Programmer > > PTI Lab > > Indiana University > > > -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/
