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 bu...@apache.org on 2004/02/24 14:27:16 UTC

DO NOT REPLY [Bug 27186] New: - Enhance wsdl2java generation to selectively generate classes

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27186>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27186

Enhance wsdl2java generation to selectively generate classes

           Summary: Enhance wsdl2java generation to selectively generate
                    classes
           Product: Axis
           Version: 1.2 Alpha
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: jcstaff@apl.jhu.edu


This enhancement request and posted solution has to do with the desire for a
straight forward way to deletively generate certain classes from a WSDL file, so
that we can use externally generated beans with our generated static
stubs/skeletion code.

One has the ability to create any number of namespaces within the WSDL and
assign each namespace a separate java package. The current approach is to have
the code generation generate all ocde to a temproary directory and then copy out
the classes that are needed and leave behind the classes that are externally
generated.

The requested/supplied approach adds a few additional options to the WSDL to
Java generation. An nsexclude option specifically excludes named namespaces from
being generated and a nsinclude option specifically includes named namespaces
(defaults to all that were not excluded) in the generated code.

This might have been done as a custom JavaGeneratorFactory excedpt that the
current design of the wsdl to java generation does not allow properties to be
defined/passed to the factory. A third parameter was added to the candidate
solution which allows an undefined name/value set of properties to be assigned
to the emitter and usable by the custom factory.