As per the discussions with the Airavata devs, it was decided not to go ahead with the approach that I mentioned earlier. Please refer the thread "Using XMLBean generated POJO classes within Airavata commons module" on [airavat-dev]list for more information.
Thanks, Heshan. On Fri, Sep 2, 2011 at 8:48 AM, Heshan Suriyaarachchi < [email protected]> wrote: > 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/ > -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/
