Hi, I just created a JIRA new features issue ( http://jira.codehaus.org/browse/CASTOR-2016). Since I was half way, I didn't finish SchemaGenerator. So that class is completely commented out.
I later understood that first looking at a method based on introspection and later plugin in annotations suppport is waste of time and useless. Because annotations defined in JAXB2 are rich enough to not look at just method signatures, I now started to concentrate on annotations in the first steps itself. Also now I am implementing from the scratch I am having little bit of difficulty understanding how the rules are defined in JAXB2 spec. These days working on to understand it and to use JAM to load it. Thanks, SD On 6/5/07, Werner Guttmann <[EMAIL PROTECTED]> wrote:
How about creating a new Jira issue and attach whatever you have currently (as incomplete it might be) for us to comment upon, make suggestions, .... ? Werner Sachith Dhanushka wrote: > Hi Werner, > > I am sorry and it seems I haven't conveyed my idea well. > > This is what I was trying to do. The Java2WSDL tool was looking at a set > of java classes and building the memory model using Apache WS Commons > XmlSchema model. I was trying to use the same logic, that were written > in that project, and build the object model using classes found in > org.exolab.castor.schema package. That is why I asked whether there are > samples on using Castor schema model. Sorry if my poor english conveyed > something else. > > This is how I will approach the problem as you wanted see a design. > > I will use JAM library to look at a set of java classes, and build the > schema model (no I won't write the schema writer). > > My first phase is to ignore all the annotations for the time being and > only look at classes, methods and the parameters. Every class will be a > complex type in the schema. All the parameters and the faults of the > methods will be processed accordingly to generate schema for them too. > So only the bean classes will get Complex types and the others will be > simple types. > > The second phase will be to incorporate JAXB2 annotations to this > process to make it JAXB2 compliant. > > Those are the thoughts that I have in my mind now. Please let me know > your comments and suggestions. > > Thanks, > SD > > On 6/4/07, *Werner Guttmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Sachith, > > it's a shame you've wasted so much time on trying to port something to > Castor when most of the base classes you are going to need is already in > place. > > As already pointed out a few times, Castor has already a set of classes > that model an XML schema in form of Java classes. Take a look at > Castor's source code in the SVN repository, and in src/main/java you are > going to find a package named > > org.exolab.castor.schema > > which has plenty of classes you will be required to use, incl. e.g. a > Schema class in that very package. Once you've built an instance of this > class (and all its children objects, representing element definitions, > complex type definitions, etc.), you'll use the SchemaWriter to > serialize that in-memory Schema instance to an actual schema file. > > What you've to come up with is a *design* first that showcases your > ideas how you go about creating such an in-memory Schema object instance > from a given set of Java classes (considering JAXB annotations as well). > > In other words, no coding for the time being, just some general > thoughts > that showcase your ideas and design. > > Thanks > Werner > > Sachith Dhanushka wrote: > > Thanks Werner for the helpful hints. > > > > I was looking at Java2WSDL in a open source web services project. > They > > were trying to create a schema out of a given set of java classes, in > > the process of creating the WSDL file. I took their code and was > trying > > to port that to Schema model in Castor. I did this for about 2 > weeks now > > and > > now I feel like I am wasting my time as that code is bit > complicated than requried. > > > > > > So now I am changing my approach completely and I am starting to write > > it from the scratch, dumping all the code and just taking some > > experience from it. > > > > I will be able to come up with a small working version by the end of > > this week. > > > > Just updating on the progress and what I am doing :) > > > > Thanks, > > SD > > > > On 6/1/07, *Werner Guttmann* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> > wrote: > > > > Sachith, > > > > please see inline. > > > > Werner > > > > Sachith Dhanushka wrote: > > > Hi, > > > > > > I am now digging in to Schema model to populate information > from the > > > JAXB classes. I am writing code to look at the JAXB generated > > classes, > > > using JAM, and create a schema model. In the first pass I > will not > > look > > > at the annotations. First pass will be to look at only the > java > > object > > > and dedude the schema. In the second phase, I will look at JAXB > > > annotations and employ those information also to build the > model. > > I have > > > few questions in doing that. > > > > > > 1. Is there a code which already looks at a set of java > classes and > > > building a schema model? I am asking this as I do not want to > > re-invent > > > the same thing. > > Not to my knowledge. What is in place is classes like the > Introspector > > or the XMLMappingLoader that build Castor-internal descriptor > classes > > from a class file and/or a class mapping. Especially the > Introspector > > should be worthwhile to analyse. You might remember Joachim's > email a > > few days ago where he pointed out that it might be an option > to create a > > new kind of Introspector (specific to JAXB) that will be > capable to > > analyse Java code plus JAXB annotations and create an internal > > descriptor from it (similar to what the current Introspector > does). > > > > In a second step, it should be pretty straight-forward to come > up with > > code that creates a hierarchy of objects from the schema > package before > > serializing this to a XML schema file. > > > > > 2. Is there any aid like a document to learn a bit about > schema model? > > In pure therory, yes. Google for the XML schema primer. > Castor-specific, > > no, not really. But having worked on the code generation side > myself > > for > > quite some months now, it should be pretty straight-forward to > map the > > existing classes in the schema package to actual XML schema > constructs. > > > > > So far the only help was to look at the code in Marshallers and > > > Un-Marshallers. I just want to know just the basics to make > sure > > the way I am using it correct. > > Odd. I don't think that the (Un-)Marshaller uses any of these > classes > > (schema package). Those classes (such as ElementDecl and > Schema) are - > > to my knowledge - used in ... > > > > a) the XML code gernator (aka source generator) to read an > actual XML > > schema fiel into a hierarchy of object instances of this package. > > > > b) the XMLInstance2Schema tool that creates an XML schema from an > > actual > > XML document instance. > > > > Whilst none of these two use cases represent a full 'solution' > to your > > problem, both should clearly highlight the usage of these > schema.* > > classes. > > > > > > > > 3. When I was coding with JAM, I found same set of classes > appearing > > > inside castor also. What are these? Does that mean > > > there is a similar code already in the code base? > > Sorry, your question is not really clear to me. > > > > > > 4. Where will be my code go? Any suggestions for the module > and java > > > package name? > > Any suggestions wrt to the package name ? There's alraedy an > existing > > SVN module, details of which I'll post in a few hours. > > > > > Please help me to find answers to the above questions. > > > > > > Thanks, > > > SD > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
