[ http://issues.apache.org/jira/browse/TUSCANY-120?page=comments#action_12413851 ]
Raymond Feng commented on TUSCANY-120: -------------------------------------- Some comments to Venkat's questions. Yes, it's the scenario that a java interface refereneces arguments or return value typed by static SDO. > 1) Comparing this with the output in test1.xsd, I understand that there are > a few attributes missing in the schema element, that relate to ecore. Also > for every SDO type there is an instance class attribute that points back to > the java class name of the SDO. Must this be fixed? Can we do this as part > of the Java2WSDL tool itself? > In simple cases, the java bean reflection against the generated SDO classes produces the same/similar result as by introspecting the SDO metadata. But if you have a XSD with SDO annotations, the pure java2wsdl will lose all the information. There're other cases like enumeration, constraint. > 2) With reference to the output pasted above can you please point out the > namespace related inconsistencies? i.e. what you see there against what you > actually expect to be there. > SDO spec defines the XSDHelper.generate() method to generate XSDs from existing SDO types. But it's not very clear how to handle the simple types, mapping to xsd namespace or sdo namespace? Frank may have some insights on this. If you look at the test1.xsd (without namespace mapping from sdo to xsd), all the String are sdo:String instead of xsd:string. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"; xmlns:doclit="http://www.example.org/creditscore/doclit/"; xmlns:sdo="commonj.sdo" ecore:documentRoot="DocumentRoot" ecore:nsPrefix="doclit" ecore:package="test1" targetNamespace="http://www.example.org/creditscore/doclit/";> <xsd:import namespace="commonj.sdo" schemaLocation="commonj.sdo"/> <xsd:element name="getCreditScoreRequest" type="doclit:Customer"/> <xsd:element name="getCreditScoreResponse" type="doclit:CreditReport"/> <xsd:complexType ecore:instanceClass="org.example.creditscore.doclit.CreditReport" name="CreditReport"> <xsd:sequence> <xsd:element name="score" type="sdo:Int"/> </xsd:sequence> </xsd:complexType> <xsd:complexType ecore:instanceClass="org.example.creditscore.doclit.Customer" name="Customer"> <xsd:sequence> <xsd:element name="ssn" type="sdo:String"/> <xsd:element name="firstName" type="sdo:String"/> <xsd:element name="lastName" type="sdo:String"/> </xsd:sequence> </xsd:complexType> </xsd:schema> > 3) My approach to this is that for this generation we should continue to use > the sca-tools i.e. Java2WSDL. We might extend it to handle things that are > not supported as of now say for the case of SDO types. But then, at the end > of it we will have this one tool to do generate XSDs and WSDL from Java. Is > this a right line of thought or are there other considerations that will > necessitate the development of another tool like the Java2XSDGenerator ? I agree, it will be supported in Java2WSDL. > Axis2 WS binding support for entryPoint without pre-existing WSDL > ------------------------------------------------------------------ > > Key: TUSCANY-120 > URL: http://issues.apache.org/jira/browse/TUSCANY-120 > Project: Tuscany > Type: Bug > Components: Java SCA Axis Binding > Versions: Java-Mx > Reporter: ant elder > Assignee: Raymond Feng > Fix For: Java-Mx > Attachments: java2wsdl-codegen.zip > > Where the entryPoint doesn't use interface.wsdl then the pre-existing WSDL > document shouldn't be required. Axis2 can generate WSDL at runtime based on > the service interface so the Axis2 binding can use that to support the > following: > <entryPoint name="AccountService"> > <interface.java > interface="org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService"/> > <binding.ws/> > <reference>AccountServiceComponent</reference> > </entryPoint> > See ML discussion: > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
