axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <>
Subject RE: Support needed for conditional stub/skeleton generation
Date Thu, 19 Feb 2004 14:56:19 GMT

Command line WSDL2Java and its API class (Emitter) are what I consider the
primary interface to WSDL2Java, probably because I don't use the ant task.
There should *never* be something added to the ant task that can't be done
from the command line.

The ant task is a convenience thingy that is an optional extra to Axis. :-)

I still feel you have a more complex solution than is needed.

- If --noimports isn't working, can you fix it?  File a bug with a test

-  I like the idea of excluding certain namespaces, but the 80% case would
be to turn all of them off, because I think most WSDLs only have a single
namespace for their Schema.  Can you come up with a syntax and API that
would give us this: --notypes and multiple --notypesforNS <namespace> or
maybe a namespace list.

Try coming up with a reasonable command line syntax, then extend it to the
Emitter API, *then* enhance the ant task to use the Emitter API.  This way
all the bases are covered.

I know the test framework is a pain but it sounds like you are on the right

Thanks for your help with Axis!

Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Jim Stafford [] 
Sent: Wednesday, February 18, 2004 7:40 PM
Subject: Re: Support needed for conditional stub/skeleton generation

I am not so sure that the WSDL2Java.main() command line approach has 
kept up with the Ant task and vice-versa. There seems to be code that is 
either contained or invoked in one that is not contained/invoked in/by 
the other. I was mainly working with the Ant task version, but would 
extend the implementation to the command line if that was truely being 
supported by all changes.

--nobeans would be one type of criteria that one might flag on. I 
initially added a specific include/exclude set of namespaces, but left 
room for a generic name/value property that could carry such a flag as 
exclude all Types.
        <property name="nobeans" value="true"/>
The JavaSelctiveGenerationFactory would have to be written or extended 
to honor that flag. 

Generating to a tmp directory and copying the desired classes defintely 
works and if I had thought of that to beging with, I could have saved a 
lot of time. However, on a beauty scale, I think the selective 
generation to the desired directory right from the begining would win 
out. Note that my attempts to use the existing "noimports=true" option 
failed. It always reports that the types for the non-generated classes 
are missing when generating the using classes. Otherwise we would have 
used imports as a way to control some of this.

Yes. One of the reasons I have been holding back on the submission is 
that I felt that it needed a good set of test cases and it extended into 
the root level documentation of the Ant task and command line (assuming 
that was included). I am learning the Axis test framework currently and 
believe the wsdl.filegen/conflict cases might be a good template to 
follow. Hopefully I can master enough of that to put out something 
reasonable soon. The documentation would be trivial to create compared 
to learning the test framework.

Tom Jordahl wrote:

>Wouldn't this be implemented as a switch to the command line WSDL2Java?
>--nobeans - turns off generation of JavaBeans for Schema types.
>This would prevent us from generating code that you don't want.
>Many users generate code in a directory, and then copy only the classes
>want and need to their build directories.  This gives maximum control over
>what generated artifacts are used.
>I seem to be missing why this seems much more complicated that I think it
>All that being said, we welcome your enhancements to WSDL2Java and its ant
>tasks.  I would like to see some good documentation on the 'how' and 'why'
>of the changes you describe go in to our tree at the same time the changes
>go in.
>Tom Jordahl
>Macromedia Server Development
>-----Original Message-----
>From: Jim Stafford [] 
>Sent: Wednesday, February 18, 2004 1:49 PM
>To: Axis Developer
>Subject: Support needed for conditional stub/skeleton generation
>We would like to have the ability to use our externally created beans 
>passed as data parameters within the WSDL->Java generated static 
>stub/skeletons. We understand and have addressed all the issues involved 
>with setting up serializers and deserializers, etc. However, there seems 
>to be a deficiency in the implementation of the WSDL to Java generation. 
>You cannot keep the WSDL to Java generation process from generating 
>classes passed by the generated interfaces in the current CVS code base. 
>There is a flag to turn off code generation for imported WSDL files, but 
>that fails. There is the ability to identify a custom 
>JavaGenerationFactory, but it cannot be passed any state information 
>though the Ant task.
>I have finished implementing a local changes to the CVS version of 
>org.apache.axis.wsdl.toJava and packages. 
>Namely I have changed (added the ability to 
>specify includes/excludes and general propeties as a factory 
>sub-element), (added the ability to carry the more robust 
>factory properties), extended JavaGenerationFactory (added the ability 
>to assign the NoopGenerator for identified namespaces), and added some 
>bean classes to carry the factory specification.
>Here's an example of our common Ant task:
><axis-wsdl2java url="${wsdl.dir}/${ws.file}"    ...    >
>   <mapping namespace="${ws.namespace1}"
>            package="${ws.namespace1.package}"/>
>   <factory classname="${factory}">
>       <exclude namespace="${ws.namespace1}"/>
>       ...
>   </factory>
>We are using this change locally and are happy with it. I need to write 
>up some JUnit test cases before submitting it (I assume). I may also 
>make a few more modifications (create Factory Methods in 
> to make it easier to extend). However, I wanted to 
>announce my need and intent to see what comments might be involved 
>before submitting the bug/enhacement request and CVS Patch file.
>Any comments? any suggestions?

View raw message