axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXIS-1501) [EWS, AXIS2] A proposal for xml-to-java name mapping in Axis and EWS (WSDL --> Java)
Date Sat, 21 Aug 2004 10:45:19 GMT
The following comment has been added to this issue:

     Author: Davanum Srinivas
    Created: Sat, 21 Aug 2004 3:45 AM
Can you please run "cvs diff -u" from ws-axis/java directory and upload the txt? Makes it
easy to apply the patch.

View this comment:

View the issue:

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 -->
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Axis
             WSDL processing
             current (nightly)

   Reporter: Jongjin Choi

    Created: Mon, 9 Aug 2004 10:15 AM
    Updated: Sat, 21 Aug 2004 3:45 AM

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
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

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message