Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 95220 invoked by uid 500); 20 Oct 2001 09:49:54 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 95201 invoked from network); 20 Oct 2001 09:49:49 -0000 Date: Sat, 20 Oct 2001 02:49:28 -0700 From: Ravi Kumar Subject: Re: AXIS chat log for 9 October, 2001 To: axis-dev@xml.apache.org Message-id: <3BD148A8.5D324ED@borland.com> Organization: Inprise Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <47FD4196C273D411950300508BCF1978013B1CCB@S0001EXC0006> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Any final resolution on the command line options for Wsdl2Java? Leave the --package switch ?? Add additional mapings to the command line? Augment with a file input or not? Rgds Ravi Tom Jordahl wrote: > Geeze - leave you guys alone for 2 days and look what happens... :-) > > Let me prefix this by saying I haven't read through the chat log yet. > > -1 on the removal of the --package switch. I believe this is a reasonable > switch that will be useful to the 80-90% of the users who don't know much > about namespaces, but do know where they want the emitted files from > Wsdl2java to go in their client application. Other tools (GLUE, > SilverStream, etc) also use a similar switch. > > I am also not in favor of our utility having a config file (!!) for > generating results. This seems complicated (what's the file format?), error > prone (where does the file live?), and hard to document (I need a comfit > file for what exactly?). > > Are we keeping in mind the Use Case for Wsdl2java? I am writing an > application that does many things, one of which is to use a web service. I > get the WSDL for the service, run the tool on it, and incorporate that code > in to my code base. I can use the web service via the stub, I include > axis.jar in my classpath, then I go on with my coding. Do I really want to > map namespace's here? Am I missing a use case that is going to be more > common? > > This is just my opinion, I am probably missing the point... :-) > > -- > Tom Jordahl > > -----Original Message----- > From: Russell Butek [mailto:butek@us.ibm.com] > Sent: Wednesday, October 10, 2001 11:57 AM > To: axis-dev@xml.apache.org > Subject: Re: AXIS chat log for 9 October, 2001 > > So we've agreed to: > 1. remove --package > 2. add some sort of command line argument for the namespace-to-package > mappings > 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 -N ... -N > 3. What's the name of this file? wsdl2java.mapping.properties? Are the > pairs in the file =? What happens if the namespace > string contains "=" or whitespace? Does java.util.Properties handle it? > Maybe the pairs should be =? > > 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 > "http://example.com/stockquote/service" and the namespace for the portType > is "http://example.com/stockquote/definitions". WSDL4J supports this. > > http://example.com/stockquote/stockquote.xsd > > > xmlns="http://www.w3.org/2000/10/XMLSchema"> > > > > > > > > > > > > > > > > > > http://example.com/stockquote/stockquote.wsdl > > > > targetNamespace="http://example.com/stockquote/definitions" > xmlns:tns="http://example.com/stockquote/definitions" > xmlns:xsd1="http://example.com/stockquote/schemas" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns="http://schemas.xmlsoap.org/wsdl/"> > > location > ="http://example.com/stockquote/stockquote.xsd"/> > > > > > > > > > > > > > > > > > > http://example.com/stockquote/stockquoteservice.wsdl > > > > targetNamespace="http://example.com/stockquote/service" > xmlns:tns="http://example.com/stockquote/service" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:defs="http://example.com/stockquote/definitions" > xmlns="http://schemas.xmlsoap.org/wsdl/"> > > location > ="http://example.com/stockquote/stockquote.wsdl"/> > > ="defs:StockQuotePortType"> > ="http://schemas.xmlsoap.org/soap/http"/> > > ="http://example.com/GetLastTradePrice"/> > > > > > > > > > > > My first service > ="tns:StockQuoteBinding"> > ="http://example.com/stockquote"/> > > > > > Russell Butek > butek@us.ibm.com > > Berin Loritsch on 10/10/2001 10:29:02 AM > > Please respond to axis-dev@xml.apache.org > > To: axis-dev@xml.apache.org > cc: > 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. > On > > 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= -N= ... -N= > > > > > > 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 > than > > > that, I would probably opt for the file approach. > > > > > > As to the --package parameter that would be for everything in the > target > > > namespace (). 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 > information > for the current definitions tag. The concept being that implementation > details > embedded in the WSDL document (i.e. stuff not necessary for a client to use > the > service) can be placed in a separate file. > > If you are using XInclude as the mechanism for for WSDL imports, the > resulting > XML document MUST conform to WSDL markup. I didn't think it was possible > to > embed a "definitions" element inside another one. In fact, I would argue > the > XInclude processing should be done before WSDL4J gets a hold of the content > (either > through a SAX stream [easier to do XInclude] or through finding all the > elements > 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. > It > does allow you to declare the namespace and prefix of the embedded document > so > that it makes sense. > > By enforcing this approach, we simplify our lives, and force users to write > legal > WSDL docs.