You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by ax...@ws.apache.org on 2004/08/09 19:15:20 UTC
[jira] Created: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Mon, 9 Aug 2004 10:15 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Davanum Srinivas
Created: Sat, 21 Aug 2004 3:45 AM
Body:
Can you please run "cvs diff -u" from ws-axis/java directory and upload the txt? Makes it easy to apply the patch.
thanks,
dims
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXIS-1501?page=comments#action_37372
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 3:45 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Jongjin Choi
Created: Sat, 21 Aug 2004 3:33 AM
Body:
I made a patch to support jaxrpc-mapping in Axis when we start from WSDL.
These are the details for the patch:
(1) Single point to access contained element and attribute defined in shema type
This might be a part of big picuture ,'separating WSDL processing and code/xml generation'.
The contained element and attributes of complex type refered in serveral places in Axis code using
SchemaUtils.getContainedElementDeclarations() and SchemaUtils.getContainedAttribueTypes() method.
I refactored this and add new field to 'TypeEntry' class for these elements and attributes.
I added new class 'ContainedEntry' which is parent class for the contained element and attribute class.
Also the class for contained element and attribute were addded.
For contained element, existing 'ElemenetDecl' class is now derived from 'ContainedEntry' class.
For contained attribute, new class 'ContainedAttribute' is added. (is AttributeDecl better name?)
The 'TypeEntry' has two vectors, each holds the 'ElementDecl' and 'ContainedAttribute' objects.
(2) Single point of javifying java names from wsdl names for java type and its fields.
Especially, the JavaBeanWriter and JavaBeanHelperWriter access the contained element and
attributes and to generate code for that.
Currently, the wsdl-to-java name mapping for field of the generated class
occurs here in Writer not JavaGenertorFactory.
In my patch, all the wsdl-to-java name mapping for the generated class ant its fields
occurs in JavaGenerationFactory, and the JavaBeanWriter and JavaBeanHelperWriter use the information
through TypeEntry.
The wsdl-to-java name mapping logic exists in toJava.Emitter which enables to hook the default mapping when
we have input jax-rpc mapping file.
(3) Flag for generated classes in Type object in SymbolTable's typeTypeEntries
It can be used for jax-rpc mapping generation in EWS.
In o.a.axis.wsdl.symbolTable.Type, I added a boolean flag 'generated' which indicates that
the java class for this Type is generated during code generation phase.
The following is the pseudo code to generate the <java-xml-type-mapping> and its child <variable mapping>
using this patch. ('JaxRpcMappingBindingHelper' is a helper class that makes the JAXB object)
Map typeMap = symbolTable.getTypeIndex();
Set typeSet = typeMap.entrySet();
for (Iterator iter = typeSet.iterator(); iter.hasNext();) {
Map.Entry element = (Map.Entry) iter.next();
QName qName = (QName) element.getKey();
Type type = (Type) element.getValue();
if (type.isGenerated()) {
boolean isAnonymous = qName.getLocalPart().indexOf('>') >= 0;
String qNameScope = type.isSimpleType() ? "simpleType" : "complexType";
String className = type.getName();
JavaXmlTypeMappingType javaType = JaxRpcMappingBindingHelper.createJavaXmlTypeMapping(className,
isAnonymous, qName, qNameScope);
JaxRpcMappingBindingHelper.addJavaXmlTypeMapping(mapping, javaType);
List varMappings = javaType.getVariableMapping();
Vector elements = type.getContainedElements();
if (elements != null) {
for (int i = 0; i < elements.size(); i++) {
ElementDecl elem = (ElementDecl) elements.get(i);
String xmlName = Utils.getLastLocalPart(elem.getQName().getLocalPart());
String javaName = elem.getName();
VariableMappingType varMapping = JaxRpcMappingBindingHelper.createVariableMappingElement(javaName, Boolean.FALSE, xmlName);
varMappings.add(varMapping);
}
}
Vector attrs = type.getContainedAttributes();
if (attrs != null) {
for (int i = 0; i < attrs.size(); i++) {
ContainedAttribute attr = (ContainedAttribute) attrs.get(i);
String xmlName = Utils.getLastLocalPart(attr.getQName().getLocalPart());
String javaName = attr.getName();
VariableMappingType varMapping = JaxRpcMappingBindingHelper.createVariableMappingElement(javaName, Boolean.FALSE, xmlName);
varMappings.add(varMapping);
}
}
}
}
Thanks.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXIS-1501?page=comments#action_37370
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 3:33 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following issue has been updated:
Updater: Jongjin Choi (mailto:gunsnroz@hotmail.com)
Date: Sat, 21 Aug 2004 4:00 AM
Comment:
ContainedAttribute.java which is not included in previous diff file.
Changes:
Attachment changed to ContainedAttribute.java
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXIS-1501?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 4:00 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Jongjin Choi
Created: Sat, 21 Aug 2004 5:25 AM
Body:
Dims.
As you tell me, I compared the generated source codes after this patched applied with the ones without this patch.
The compared ones are the generated artifacts from all-tests.
(I compared the files in ws-axis/java/build/work using BeyondCompare from scootersoftware. If I missed something, please tell me.)
The result is very satisfactory.
The only differences are in generated BindingStub source. In initOperationDesc() of Stub source, the order of adding ser/deser differs. But the number and types/ser/deser registered are same as before. So, they are semantically identical, I think.
The names of generated bean/helper class and its member are same, too. (The only difference is generated date/time in comment area.^^)
There are no files additionally generated and missing ones after this patch applied. The number of generated files are same, too.
Thanks.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXIS-1501?page=comments#action_37380
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 5:25 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: AXIS-1208 and AXIS-1523
Posted by Shantanu Sen <ss...@pacbell.net>.
Sorry I forgot last week: this is my weekly attempt to
see if anyone will take notice regarding the patches
that I checked in for these bugs. I am willing to
provide any further help needed regarding these.
Thanks,
Shantanu
--- Shantanu Sen <ss...@pacbell.net> wrote:
>
> Trying to see if I get any response this time.
> Anything I can do to help review these and check
> them
> in before 1.2 becomes final?
>
> Thanks,
> Shantanu
>
> --- Shantanu Sen <ss...@pacbell.net> wrote:
>
> > I sent patches, diffs and test cases for the bugs
> > AXIS-1523 and AXIS-1208 last Friday. Can someone
> > please review them and check them in?
> >
> > Thanks,
> > Shantanu
> >
>
>
AXIS-1523
Posted by Shantanu Sen <ss...@pacbell.net>.
Any ideas if the patch that I supplied for this one will make it to the final?
Thanks,
Shantanu Sen
Re: AXIS-1208 and AXIS-1523
Posted by Shantanu Sen <ss...@pacbell.net>.
Trying to see if I get any response this time.
Anything I can do to help review these and check them
in before 1.2 becomes final?
Thanks,
Shantanu
--- Shantanu Sen <ss...@pacbell.net> wrote:
> I sent patches, diffs and test cases for the bugs
> AXIS-1523 and AXIS-1208 last Friday. Can someone
> please review them and check them in?
>
> Thanks,
> Shantanu
>
AXIS-1208 and AXIS-1523
Posted by Shantanu Sen <ss...@pacbell.net>.
I sent patches, diffs and test cases for the bugs
AXIS-1523 and AXIS-1208 last Friday. Can someone
please review them and check them in?
Thanks,
Shantanu
[jira] Updated: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following issue has been updated:
Updater: Jongjin Choi (mailto:gunsnroz@hotmail.com)
Date: Sat, 21 Aug 2004 4:01 AM
Comment:
ContainedEntry.java which is not included in the previous diff file.
Changes:
Attachment changed to ContainedEntry.java
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXIS-1501?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 4:01 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Srinath Perera
Created: Wed, 11 Aug 2004 5:03 AM
Body:
Yes the basic idea of the jaxrpcmapping.xml file is to let the developers to map the XML names to the programming language. But here the langauge is java. I belive everybody quite agreed on how the mapping take place XML->java. It make sense to automatically generate the wsdl file.
1) EWS and jaxrpcmapping.xml file
WSDL->java conversion
now the ews need jaxrpc mapping file and wsdl or not any one. This case I accept that it is better to generate the mapping file if it does not exists. If you can fix it you are well come and I will check them in. In other case let me know your thoughts and let us decide how to do it and I will try my best to implement it.
Java -> WSDL conversion
this case the jaxrpcmapping file is generated even now.
2) I accept the fact that the real place to provide the jaxrpcmapping support is the axis code itself. Does it a axis 1.x stuff or axis 2.0 stuff?
3)
>I suggest that all the wsdl/schema name to java name mapping should >be done in one place (javifyNames() in JavaGeneratorFactory)
absolutely. ideally the codes wsdl parsing,jaxrpc-mapping and code generation should be independent and they should interact through the standard interfaces. But that would call for major revised. I like to rasied this on the Axis 2.0 summit and discuss. to me it sound like 2.0 stuff.
4)We could put RemoteException in the interface I belive. (got to check does it mess up something but I quite positive)
5) we can remove the org.apache.axis.* depndncies by generating helpers. (-H if I rember correct) will that do.
6) I am quite sure we will discuss the JAX-RPC 2.0 and JAXB 2.0 in the Axis 2.0 summit. According MHO those would be 2.x stuff as they call oupon the heavy restuctring and trying to do them by fixing some places here and there will bring down the code quality.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXIS-1501?page=comments#action_37170
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Wed, 11 Aug 2004 5:03 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following issue has been updated:
Updater: Jongjin Choi (mailto:gunsnroz@hotmail.com)
Date: Sat, 21 Aug 2004 3:55 AM
Comment:
The is the same patch in one file. I made it by typeing "cvs diff -u" from ws-axis/java directory.
Changes:
Attachment changed to ws-axis-java-dir-diff.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXIS-1501?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 3:55 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
The following issue has been updated:
Updater: Jongjin Choi (mailto:gunsnroz@hotmail.com)
Date: Sat, 21 Aug 2004 3:34 AM
Comment:
the patch attached.
Changes:
Attachment changed to contained-elem-attr-patch.zip
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXIS-1501?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 3:34 AM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Posted by ax...@ws.apache.org.
Message:
The following issue has been closed.
Resolver: Davanum Srinivas
Date: Sat, 21 Aug 2004 8:12 PM
Applied Patch.
thanks,
dims
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1501
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1501
Summary: [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Type: Improvement
Status: Closed
Priority: Major
Resolution: FIXED
Project: Axis
Components:
WSDL processing
Versions:
current (nightly)
Assignee:
Reporter: Jongjin Choi
Created: Mon, 9 Aug 2004 10:15 AM
Updated: Sat, 21 Aug 2004 8:12 PM
Description:
Dear Axis developers.
This is a proposal for support standard jax-rpc mapping (especially <java-xml-type-mapping>)
and some related issues. In this proposal, I will address only to top-down case.
(I did not arrange my thought in bottom-up case)
I'm not native english speaker so the sentence may not be fluent. Please be patient.
--------------------------------------------------------------------------------------------------------------------
1. Rationale
The JSR-109 specification requires jax-rpc mapping file for portable web services provider/requester application archive.
It is a developer's role to write the jax-rpc mapping file but it is error-prone and tedious to write a jax-rpc mapping file by hand.
it would be helpful if the JSR-109 implementation provides a facility that generates jax-rpc mapping file automatically
in both top-down (from WSDL) and bottom-up (from Java) cases.
EWS project made a big progess in implementing open-source JSR-109 implementation
and we expect that other JCP standards(JSR-181, JAX-RPC 2.0) will be integrated with Axis
based on our experience on EWS.
With additional support of Axis for java-xml mapping,
generating <java-xml-type-mapping> in EWS seems can be streamlined and
the probable code duplication between Axis and EWS will be minimized.
2. Top-down (from WSDL to Java) case
2-1. support for schema type (and nested types) and its java mapping
org.apache.axis.wsdl.symbolTable package represents the entire wsdl model
and org.apache.axis.wsdl.toJava package do all code generation tasks for symbolTable's entries.
Each entry in symbolTable has its wsdl qname(name) and its corresponding java name
and the writers in toJava package use this information when generating java code.
The mapping of wsdl name to java name is toJava.JavaGeneratorFactory's javifyNames().
The only lack in mapping is for the nested types in TypeEntry that is mapped to member of generated JavaBeans.
This nested type and JavaBean's member name mapping is done in JavaBeanWriter and/or JavaBeanHelperWriter.
I suggest that all the wsdl/schema name to java name mapping should be done in one place
(javifyNames() in JavaGeneratorFactory)
and all other writers should generate java codes without additional xml to java name mapping.
To accomplish this, we need addtional members in TypeEntry class
that represents element and attribute which is defined in the type definition in the schema.
We may also need the member for xml value for complexType
which have simpleContents with extension or recstriction xsd simpleTypes.
These are corresponding to the @XmlElement, @XmlAttribute and @XmlValue in "8.9" in JAXB 2.0 early draft.
These properties are already passed to newly created JavaBeanWriter/JavaBeanHelperWriter in current Axis source.
(getBeanWriter() in JavaTypeWriter)
Also the TypeEntry class should have the flag that its corresponding java class should be genrated or not.
2-2. JavaBeanWriter / JavaBeanHelperWriter / JavaBeanFaultWriter / JavaDefinitionWriter and some other writers
As pointed out in 2-1, if the TypeEntry has all the wsdl/xml-to-java mapping for members of its generated JavaBean,
the other writers can use the information for its code generation without additional xml-to-java name mapping
and duplicate code between writers for naming mapping can be reduced.
2-3. EWS jax-rpc mapping generation
In EWS, the generation of <java-xml-type-mapping> and its child <variable-mapping> can be simple.
We need to lookup all the Types in symbolTable (which is accessible by wsdl-to-Java emiiter object)
and check if it has generated java classes and , if it has, generate <java-xml-type-mapping> for that class.
The other information needed in <java-xml-type-mapping> like the whether it is simple, complex or anonymous type,
I think, can be acquired directly by TypeEntry.
In EWS, we need not to generate jax-rpc mapping if the wsdl-to-java emitter has input jax-rpc mapping file.
If the input jax-rpc mapping provided, we may be able to apply the wsdl/xml-to-java name mapping
using JavaGeneratorFactory and/or toJava.Emitter's wsdl naming hook.
We may need to generate java-rpc mapping if the input jax-rpc mapping is not specified
and the output jax-rpc mapping file is specifed.
3. Other portability issue
3-1. JavaBeanWriter's generated code
The code generated by JavaBeanWriter should be portable as in JSR-109.
The generated code should not include axis class if possible.
Currently it use classes below org.apache.axis.* in its generated code for some case.
3-2. JavaBeanFaultWriter / JavaDefinitionWriter's generated code
The Exception classes generated by JavaBeanFaultWriter and JavaDefinitionWriter
should be portable, i.e. it should not extend AxisFault.
It hurts the portability of the generated code from WSDL.
3-3. Integration of other technology to Axis
I think It will help Apache Beehive's JSR-181, future JAX-RPC 2.0 and JAXB 2.0 implementation to be integrated to Axis.
-----------------------------------------------------------------------------------------------------------
Currently that's all. I hope we can make a consensus for this issue.
I think that it is related to discussion topic in Axis 2.0 submit. (Tight binding between WSDL processing and code generation).
Thanks for your interest
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira