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 >
