axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <>
Subject Re: AXIS chat log for 9 October, 2001
Date Wed, 10 Oct 2001 15:56:36 GMT
So we've agreed to:
1.  remove --package
2.  add some sort of command line argument for the namespace-to-package
3.  look for a mapping properties file
4.  2 takes precedence over 3

So now we have to decide
2.  What does the command line argument look like?  How about
    --NStoPkg <ns0> <pkg0> -N <ns1> <pkg1> ... -N <nsN> <pkgN>
3.  What's the name of this file?  Are the
pairs in the file <namespace>=<package>?  What happens if the namespace
string contains "=" or whitespace?  Does java.util.Properties handle it?
Maybe the pairs should be <package>=<namespace>?

About your last point, Berin, I disagree with you.  I believe, via imports,
you can have multiple WSDL definitions and, therefore, multiple namespaces
for the WSDL things in the definitions.  Here's an example from section
2.1.2 of the WSDL spec.  The namespace for the service and the binding is
"" and the namespace for the portType
is "".  WSDL4J supports this.

           <?xml version="1.0"?>
           <schema targetNamespace=""

               <element name="TradePriceRequest">
                           <element name="tickerSymbol" type="string"/>
               <element name="TradePrice">
                           <element name="price" type="float"/>

           <?xml version="1.0"?>
           <definitions name="StockQuote"


              <import namespace=""

               <message name="GetLastTradePriceInput">
                   <part name="body" element="xsd1:TradePriceRequest"/>

               <message name="GetLastTradePriceOutput">
                   <part name="body" element="xsd1:TradePrice"/>

               <portType name="StockQuotePortType">
                   <operation name="GetLastTradePrice">
                      <input message="tns:GetLastTradePriceInput"/>
                      <output message="tns:GetLastTradePriceOutput"/>

           <?xml version="1.0"?>
           <definitions name="StockQuote"


              <import namespace=""

               <binding name="StockQuoteSoapBinding" type
                   <soap:binding style="document" transport
                   <operation name="GetLastTradePrice">
                      <soap:operation soapAction
                          <soap:body use="literal"/>
                          <soap:body use="literal"/>

               <service name="StockQuoteService">
                   <documentation>My first service</documentation>
                   <port name="StockQuotePort" binding
                      <soap:address location

Russell Butek

Berin Loritsch <> on 10/10/2001 10:29:02 AM

Please respond to

Subject:  Re: AXIS chat log for 9 October, 2001

Russell Butek wrote:
> Berin wrote:
> > At the end of the meeting--about the time it looked like everyone got
> > kicked off, I proposed that we drop the support for declaring the
> multiple
> > namespace mappings on the command line and just do it in the file.
> >
> I'm torn, here.  If the user only has one namespace, it'll be a real pain
> to force them to create a properties file just for that one namespace.
> the other hand, we're already in danger of going overboard with Wsdl2java
> arguments.
> We COULD do the following:
> 1.  Provide the -N flag (in whatever form we choose).
> 2.  Make Wsdl2java look for a mapping properties file in the current
> directory and, if it exists, use it.
> 3.  If both the file and the -N are used, -N takes precedence over the
> file.  In other words, if x=y exists in the file and x=z exists in the -N
> argument, then the mapping will be x=z.

This is precisely the approach that Cocoon uses for its CLI.  It is a
pretty standard convention and I am for it.

> > PS
> > If you don't want to handcode the parsing for multiple namespace
> mappings,
> > the CLIUtil will allow you to do the following:
> >
> > -N<ns0>=<pkg0> -N<ns1>=<pkg1> ... -N<nsN>=<pkgN>
> >
> > This allows the CLI utility to give you multiple parameters that it
> parses.
> > For 1 or 2 mappings, doing it on the command line is fine.  For more
> > that, I would probably opt for the file approach.
> >
> > As to the --package parameter that would be for everything in the
> > namespace (<wsdl:definitions targetnamespace="..." .../>).  Or, we drop
> > it completely and use the mapping approach above exclusively.
> There can be more than one wsdl:definitions targetNamespace if you're
> importing WSDL from WSDL.  So what would --package refer to?  Only the
> targetNamespace of the immediate WSDL's definition?  That's starting to
> sound a bit contrived, that's why I favor removing it if we come up with
> another means of providing a namespace->package mapping.  (That and the
> fact that we're getting argument-heavy.)

Sounds good.

BTW, it was my understanding that WSDL imports were only to have more
for the current definitions tag.  The concept being that implementation
embedded in the WSDL document (i.e. stuff not necessary for a client to use
service) can be placed in a separate file.

If you are using XInclude as the mechanism for for WSDL imports, the
XML document MUST conform to WSDL markup.  I didn't think it was possible
embed a "definitions" element inside another one.  In fact, I would argue
XInclude processing should be done before WSDL4J gets a hold of the content
through a SAX stream [easier to do XInclude] or through finding all the
in a nodelist).

XInclude was never meant to change the schema.  The idea is to keep
portions of
XML in a separate file so they can be incorporated into one whole document.
does allow you to declare the namespace and prefix of the embedded document
that it makes sense.

By enforcing this approach, we simplify our lives, and force users to write
WSDL docs.

View raw message