You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by R Bruce Hoffman <br...@iseries-admin.net> on 2007/01/16 19:23:23 UTC
wsdl2java generates incorrect/incomplete code
I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly create
skeleton code and Axiom or XmlBeans artifacts correctly for, what seems
to be, relatively simple wsdl and xsd's.
Below is the xsd and wsdl information. I have used FC4, FC5, Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
I am being told that the wsdl and xsd information is valid (by the
original developers). Both NetBeans 5.5 and Eclipse (under WDSCi) seem
to agree that they are at least valid.
When I run wsdl2java with ADB binding, the message parts all end up in
the default package with empty package statements ("package ;"). The
ExtensionMapper.java ends up in an (invalid) null package. (It's named
"null" and on the output src path.)
All of the types, after the first array type, are listed with "This was
an array!" in the comments, but have no array declarations in their
_type_nn classes... the [] markers are not produced after the first
repeating element.
I have looked at trying to clean up this code to make it usable, but I
would think that Axis2 should be producing code that, at the very least,
would compile through the ant build if the wsdl2java succeeds, which it
does complete in this case. If not, it should probably give me an error
in the generation of the ADB code.
Maybe its something simple or I'm just a dope, or both, but I am lost.
Re: wsdl2java generates incorrect/incomplete code
Posted by Amila Suriarachchi <am...@gmail.com>.
>
>
> > The XmlBeans binding still throws an Exception though.
>
>
> ohh thanks for remining this. I will work on it.
>
> It seems to be an xml beans problem. can you take an xmlbeans 2.2.0release and try to compile your wsdl using the scomp command comes with the
xmlbeans release.
--
Amila Suriarachchi,
WSO2 Inc.
Re: wsdl2java generates incorrect/incomplete code
Posted by Amila Suriarachchi <am...@gmail.com>.
On 1/23/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
>
> uhhhh, ok, but could you elaborate on what the problem was that this
> nightly build might fix?
there were three things
1. there was a problem in URLProcessor. it did not correctly convert the
namespaces like urn:/fih/1_0 correctly.
2. there was a problem in handling element refering to other elements having
maxOccures > 1
eg. <xs:element ref="DateTimeReferenceSegment" minOccurs="0"
maxOccurs="10"/>
3. there was a problem handling simple types restriction with base type as
QName with several enumerations.
actually this a problem with addressing name space.
On Tue, 2007-01-23 at 18:56 +0530, Amila Suriarachchi wrote:
> > sorry for the late reply. I had to wait until axis2 1.1 brach changes
> > were merged to axis2 trunk.
> > I fixed your problems in axis2_truck and you can take a nightly build
> > to test it.
> >
> > amila.
> >
>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: wsdl2java generates incorrect/incomplete code
Posted by Amila Suriarachchi <am...@gmail.com>.
On 1/23/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
>
> Well, I see that when I used the Snapshot from the Jan 23, that yes, the
> ADB binding completes, places the ExtensionMapper in the proper class
> and all the source did finally compile.
>
> The XmlBeans binding still throws an Exception though.
ohh thanks for remining this. I will work on it.
On Tue, 2007-01-23 at 11:39 -0500, R Bruce Hoffman wrote:
> > uhhhh, ok, but could you elaborate on what the problem was that this
> > nightly build might fix?
> >
> >
> > On Tue, 2007-01-23 at 18:56 +0530, Amila Suriarachchi wrote:
> > > sorry for the late reply. I had to wait until axis2 1.1 brach changes
> > > were merged to axis2 trunk.
> > > I fixed your problems in axis2_truck and you can take a nightly build
> > > to test it.
> > >
> > > amila.
> > >
> >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
Well, I see that when I used the Snapshot from the Jan 23, that yes, the
ADB binding completes, places the ExtensionMapper in the proper class
and all the source did finally compile.
The XmlBeans binding still throws an Exception though.
On Tue, 2007-01-23 at 11:39 -0500, R Bruce Hoffman wrote:
> uhhhh, ok, but could you elaborate on what the problem was that this
> nightly build might fix?
>
>
> On Tue, 2007-01-23 at 18:56 +0530, Amila Suriarachchi wrote:
> > sorry for the late reply. I had to wait until axis2 1.1 brach changes
> > were merged to axis2 trunk.
> > I fixed your problems in axis2_truck and you can take a nightly build
> > to test it.
> >
> > amila.
> >
>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
uhhhh, ok, but could you elaborate on what the problem was that this
nightly build might fix?
On Tue, 2007-01-23 at 18:56 +0530, Amila Suriarachchi wrote:
> sorry for the late reply. I had to wait until axis2 1.1 brach changes
> were merged to axis2 trunk.
> I fixed your problems in axis2_truck and you can take a nightly build
> to test it.
>
> amila.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Amila Suriarachchi <am...@gmail.com>.
sorry for the late reply. I had to wait until axis2 1.1 brach changes were
merged to axis2 trunk.
I fixed your problems in axis2_truck and you can take a nightly build to
test it.
amila.
On 1/18/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
>
> Anne,
>
> Thank you very much for taking the time to produce such a detailed answer.
>
> The details are a little depressing for someone with software that
> relies on being able to dynamically consume web services. For various
> reasons, we don't support all possible wsdl-described services at
> present, so it's not fatal that the lack of support for consistent
> policy attachment makes some additional service types unsupported,
> e.g. those that depend on policies you have to be told about
> out-of-band, We'll have to track both the various standardization and
> implementation efforts and see what develops.
>
> Jeff
>
> On 1/18/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > See inline...
> >
> > On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > > Anne,
> > >
> > > As usual, you are a fount of useful information. Thanks for all you
> > > do to explain the various SOA standards to the world.
> > >
> > > Questions:
> > >
> > > 1. What schema is supposed to be provided by ?xsd.
> >
> > Keep in mind that the URL query is a non-standard convention. Most
> > systems support the "?wsdl" query, but very few support either "?xsd"
> > or "?policy".
> >
> > But, assuming that an endpoint does support the "?xsd" query
> > convention, then it should return a schema that defines the input and
> > output messages supported by the endpoint. (This convention would be
> > especially helpful for RESTful services that don't provide a WSDL
> > definition.)
> >
> > >
> > > a. Is it the schema containing the declarations of the types or
> > > elements used as message parts?
> >
> > It should define the complete body message structures, which ought to
> > be defined as root elements. Types or message parts aren't sufficient.
> > If you are using RPC style, then you would have to depend on the WSDL
> > to provide the information required to define the message structure.
> > (RPC style only defines types, not the root element of the message.)
> >
> > >
> > > b. What if that information is contained in several schemas?
> >
> > A message contains a single element ( a root element); therefore, that
> > element must be defined in a single schema (although it can certainly
> > import or include other schemas). For this convention to work, though,
> > all message structures supported by the endpoint must be defined in a
> > single schema. For efficiency sake, you probably want to make sure
> > that the "?xml" query returns the actual schemas and doesn't return a
> > bunch of imports that then requires a bunch more queries.
> >
> > > c. Does this access schemas contained in the types section of the
> > > wsdl and/or imports from those schemas?
> >
> > The convention is that it returns a schema that describes the input
> > and output messages. How it goes about getting that schema is an
> > implementation feature of the system supporting the convention. If
> > Axis2 chose to implement this convention, it might require the
> > developer to provide the schema as a configuration parameter, or it
> > might automatically generate the schema by extracting the appropriate
> > info from the WSDL.
> >
> > >
> > > 2. Starting from a correct and consistent wsdl descriptor, is there a
> > > deterministic algorithm that finds all the policy metadata?
> >
> > Only if the WSDL embeds all policy information via
> > WS-PolicyAttachment. There is no requirement that the policies must be
> > attached to the WSDL. The preferred method for retrieving all metadata
> > is to use WS-MetadataExchange.
> >
> > > a. If the policies are embedded in the wsdl and/or referenced in
> > > the wsdl, does extracting all the embedded ones and retrieving all the
> > > references (recursively if that's necessary), will that be all of the
> > > policies that apply?
> >
> > Again, only if the WSDL embeds all policy information.
> >
> > > b. Will there be any policies that apply that are not referenced
> > > or embedded in the wsdl?
> >
> > It's possible. As a best practice, it's a good idea to attach all
> > applicable policies to the WSDL.
> >
> > > c. If policies must be retrieved from a UDDI repository, is that
> > > repository referenced in the wsdl or is there some out-of-band process
> > > that must be followed to determine its existence?
> >
> > I've never seen an extension to WSDL that provides a means to
> > reference a UDDI bindingTemplate (the UDDI entry that represents a
> > service endpoint). Keep in mind that typically, you're querying UDDI
> > to find a service, its endpoints, and its metadata. If you already
> > have the endpoint, then you should be able to query the endpoint to
> > get its metadata using WS-MetedataExchange.
> >
> > I suppose we could define another query convention: append "?uddi" to
> > the access point URL, and it should return a link to the UDDI
> > bindingTemplate that describes it.
> >
> > (FYI: UDDI is a registry, not a repository. It does not host the
> > policies (or WSDLs or XSDs), it simply provides pointers to all the
> > metadata that apply to the service.
> >
> > > d. Similarly for access via ?policy.
> >
> > If the service endpoint follows this convention, then the "?policy"
> > query should return a WS-Policy file that contains all policies that
> > apply to the service.
> >
> > > 3. Do the queries service-endpoint?policy and service-endpoint?xsd
> > > produce exceptions when not implemented, or do they produce some empty
> > > result? If they produce a result, is it guaranteed that the result
> > > contains or references (perhaps recursively) all the policies or
> > > schemas needed to consume the web service?
> >
> > The convention hasn't been standardized. What happens today when you
> > issue a "?wsdl" query to a service that doesn't support the
> > convention? My guess is that you would get a 404 Not Found.
> >
> > > 4. Do you ever need to use more than one of the various methods
> > > (query-url, wsdl-cracking, Ws-MetadataExchange or UDDI) of obtaining
> > > the metadata, or is any one that doesn't fail equivalent to any other
> > > that doesn't fail?
> >
> > If the service follows the conventions properly, then you should be
> > able to get all metadata using any one of the methods. But I
> > absolutely would not depend on any service implementing any of these
> > conventions properly today. None of these conventions has been
> > standardized yet.
> >
> > The one closest to standardization is WS-PolicyAttachment (which
> > enables "WSDL-cracking" and UDDI), but keep in mind that only a few
> > systems support WS-Policy at this time, and most systems that do
> > support WS-Policy only use it for security and maybe reliability
> > policies.
> >
> > WS-MetadataExchange has not yet been submitted to a standards body.
> >
> > I've never seen anyone attempt to document the url-query convention.
> >
> > >
> > > Jeff
> > >
> > > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > > The way it supposed to work is thus:
> > > >
> > > > - A web service has various metadata files associated with it:
> > > > - WSDL defines the supported interfaces, MEPs, and bindings
> > > > - XSD defines the message formats
> > > > - WS-Policy defines its constraints and capabilities
> > > > (policies can be embedded in the WSDL or attached via UDDI)
> > > > - You have various means to locate the metadata
> > > > - Look it up via UDDI (all metadata should be registered,
> > > > WS-PolicyAttachment defines how policies are attached via
> UDDI)
> > > > - Query the service for its metadata using WS-MetadataExchange
> > > > - Query the service access point, appending "?wsdl", "?xsd", and
> "?policy"
> > > > to the URL and hope that the service supports this convention
> > > >
> > > > Anne
> > > > On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > > > > Anne,
> > > > >
> > > > > So if you want to dynamically consume web services based on the
> wsdl
> > > > > alone, the WS-Policy constructs have to be embedded there and the
> > > > > client machinery has to know how to process them to determine what
> > > > > headers are required, if any? Is this the way it's supposed to
> work?
> > > > >
> > > > > Is the alternative to get the WS-Policy requirements from some
> > > > > different repository? Is there a regular scheme related to UDDI
> or
> > > > > something that provides this?
> > > > >
> > > > > Jeff
> > > > >
> > > > > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > > > > Bruce,
> > > > > >
> > > > > ...
> > > > > > But I reiterate my earlier comment. I strongly discourage you
> from
> > > > > > defining headers in the WSDL. The WSDL represents the
> information that
> > > > > > the application should be responsible for. Typically headers are
> added
> > > > > > to the message and processed by the middleware, not by the
> > > > > > application. Therefore the requirement for headers should be
> specified
> > > > > > separately -- preferably using WS-Policy, even though it isn't
> final
> > > > > > yet.
> > > > > >
> > > > > > I also *strongly* recommend that you not define your own header
> > > > > > formats, but rather that you conform to standard SOAP extensions
> -- in
> > > > > > your case WS-Addressing and WS-Security. (You've used standard
> element
> > > > > > definitions from WS-Addressing and XML Signature, but you
> haven't
> > > > > > followed the standard header formats for using these elements.)
> > > > > >
> > > > > > Axis2 can automatically manage WS-Addressing and WS-Security
> headers
> > > > > > for you, and they will do so in an interoperable way. But you
> mustn't
> > > > > > define the headers in the WSDL -- you must configure them in the
> > > > > > config file.
> > > > > >
> > > > > > Anne
> > > > > >
> > > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net>
> wrote:
> > > > > > > First, let me sincerely thank you for your rapid response.
> > > > > > >
> > > > > > > I had originally questioned the other developers on that
> repeated import
> > > > > > > of the namespace and been told it was ok. I probably have to
> be more
> > > > > > > forceful when my gut says it's wrong... but, as you can
> probably tell, I
> > > > > > > am new to this WSDL stuff.. previous services I have deployed
> were from
> > > > > > > POJOs and not defined by or through WSDL, and I am no xml
> expert either.
> > > > > > >
> > > > > > > At least I have ammo to go back to them and have their manager
> apply the
> > > > > > > "2 by 4" process... ;-)
> > > > > > >
> > > > > > > Next here are the other two xsd's that I had left off.
> > > > > > >
> > > > > > > again, thanks.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > > > > Bruce,
> > > > > > > >
> > > > > > > > Giving the WSDL a quick look, I noticed that it is not
> valid. I don't
> > > > > > > > know if this is what's causing your problem, but it's a good
> place to
> > > > > > > > start.
> > > > > > > >
> > > > > > > > In your WSDL <types> section, you attempt to import the same
> namespace
> > > > > > > > twice. This is not allowed. If the namespace is defined in
> multiple
> > > > > > > > schemas, and your goal is to import both schemas, then you
> must define
> > > > > > > > a schema with the same target namespace and <xs:include> the
> schemas
> > > > > > > > into the namespace. e.g.:
> > > > > > > >
> > > > > > > > <xs:schema
> targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="qualified">
> > > > > > > > <xs:include
> > > > > > > > schemaLocation="1.0/receive-
> purchase-order-request.xsd"/>
> > > > > > > > <xs:include
> > > > > > > > schemaLocation="1.0/receive-
> purchase-order-reply.xsd"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > Another error that I found: you must not specify the
> parameterOrder
> > > > > > > > attribute in the <wsdl:operation> definition when using
> document
> > > > > > > > style. (It is only used with RPC style.)
> > > > > > > >
> > > > > > > > As a general practice, it's a bad idea to define headers in
> your WSDL,
> > > > > > > > especially if you are using standard headers. (The XMLBeans
> error
> > > > > > > > indicates that you are using WS-Addressing and DSIG.) You
> should
> > > > > > > > define your header requirements using WS-Policy and
> configuration
> > > > > > > > files.
> > > > > > > >
> > > > > > > > Also, in regards to schema you did provide
> > > > > > > > (targetNamespace="urn:/fih/purchase-order"), some best
> practices
> > > > > > > > advice:
> > > > > > > >
> > > > > > > > - Avoid using anonymous types. Rather than defining
> structures as
> > > > > > > > elements, define them as named types, and then define
> elements as
> > > > > > > > those types. e.g.:
> > > > > > > >
> > > > > > > > Do this:
> > > > > > > >
> > > > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element
> ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > > > <xs:element
> ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > <xs:element name="BaselineItemDataLoop"
> type="baselineItemDataLoop"/>
> > > > > > > >
> > > > > > > > Rather than this:
> > > > > > > >
> > > > > > > > <xs:element name="BaselineItemDataLoop">
> > > > > > > > <xs:complexType>
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element
> ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > > > <xs:element
> ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > </xs:element>
> > > > > > > >
> > > > > > > > And I recommend being cautious about defining each element
> as a global
> > > > > > > > element. The only elements that really should be defined as
> global
> > > > > > > > elements are those elements that will be the root of a
> document. i.e,
> > > > > > > > rather than defining "BaselineItemDataSegment" as a gloal
> element and
> > > > > > > > referencing it from the type definition, define the element
> within the
> > > > > > > > type definition and reference its type, e.g.:
> > > > > > > >
> > > > > > > >
> > > > > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0"
> schema files.
> > > > > > > > (You sent us the "http://www.fih.org/XML/WD0" namespace
> schema, instead.)
> > > > > > > >
> > > > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element
> name="BaselineItemDataSegment"
> > > > > > > > type="baselineItemDataSegment
> > > > > > > > minOccurs="0"/>
> > > > > > > > <xs:element
> name="ReferenceIdentificationSegment"
> > > > > > >
> > type="referenceIdentificationSegment"
> > > > > > > > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > Anne
> > > > > > > >
> > > > > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net>
> wrote:
> > > > > > > > > Sure... sorry.
> > > > > > > > >
> > > > > > > > > Also, when using xmlbeans binding, I get the following
> error:
> > > > > > > > >
> > > > > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd',
> relative to
> > > > > > > > >
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > > Retrieving schema at
> > > > > > > > > '
> http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd',
> relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > > > Retrieving schema at
> > > > > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/',
> relative to
> > > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > > > Retrieving schema at '1.0/receive-
> purchase-order-request.xsd', relative
> > > > > > > > > to
> > > > > > > > >
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative
> to
> > > > > > > > >
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-
> purchase-order-request.xsd'.
> > > > > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd',
> relative to
> > > > > > > > >
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and
> systemId
> > > > > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId
> [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId
> [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId
> > > > > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > > > >
> [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-
> core-schema.xsd]
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId
> > > > > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and
> systemId
> > > > > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > > > > Jan 16, 2007 1:39:58 PM
> org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > > INFO: Resolving schema with publicId [
> http://www.fih.org/XML/WD0] and
> > > > > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > > > > Exception in thread "main"
> > > > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > > > > java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(
> CodeGenerationEngine.java:224)
> > > > > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(
> WSDL2Code.java:32)
> > > > > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(
> WSDL2Java.java:21)
> > > > > > > > > Caused by: java.lang.RuntimeException:
> > > > > > > > > java.lang.reflect.InvocationTargetException
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(
> XMLBeansExtension.java:92)
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(
> CodeGenerationEngine.java:177)
> > > > > > > > > ... 2 more
> > > > > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > > > > > > > > at
> > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> > > > > > > > > at
> > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> > > > > > > > > at java.lang.reflect.Method.invoke(Method.java
> :585)
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(
> XMLBeansExtension.java:82)
> > > > > > > > > ... 3 more
> > > > > > > > > Caused by: java.lang.RuntimeException:
> org.apache.xmlbeans.XmlException:
> > > > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1:
> error:
> > > > > > > > > cvc-enumeration-valid: string value 'none' is not a valid
> enumeration
> > > > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(
> CodeGenerationUtility.java:242)
> > > > > > > > > ... 8 more
> > > > > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1:
> error:
> > > > > > > > > cvc-enumeration-valid: string value 'none' is not a valid
> enumeration
> > > > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > > > at
> > > > > > > > >
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(
> SchemaTypeSystemCompiler.java:225)
> > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > > > > > > > > at
> > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> > > > > > > > > at
> > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> > > > > > > > > at java.lang.reflect.Method.invoke(Method.java
> :585)
> > > > > > > > > at
> > > > > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java
> :667)
> > > > > > > > > at
> > > > > > > > >
> org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(
> CodeGenerationUtility.java:160)
> > > > > > > > > ... 8 more
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi
> wrote:
> > > > > > > > > > Can you attach your fih-header.xsd file?
> > > > > > > > > >
> > > > > > > > > > On 1/16/07, R Bruce Hoffman <
> bruce.hoffman@iseries-admin.net> wrote:
> > > > > > > > > > I just can't seem to get Axis2 1.1.1
> wsdl2java.sh to properly
> > > > > > > > > > create
> > > > > > > > > > skeleton code and Axiom or XmlBeans artifacts
> correctly for,
> > > > > > > > > > what seems
> > > > > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > > > > >
> > > > > > > > > > Below is the xsd and wsdl information. I have
> used FC4, FC5,
> > > > > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a
> snapshot before
> > > > > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and
> 10.
> > > > > > > > > >
> > > > > > > > > > I am being told that the wsdl and xsd
> information is valid (by
> > > > > > > > > > the
> > > > > > > > > > original developers). Both NetBeans 5.5 and
> Eclipse (under
> > > > > > > > > > WDSCi) seem
> > > > > > > > > > to agree that they are at least valid.
> > > > > > > > > >
> > > > > > > > > > When I run wsdl2java with ADB binding, the
> message parts all
> > > > > > > > > > end up in
> > > > > > > > > > the default package with empty package
> statements
> > > > > > > > > > ("package ;"). The
> > > > > > > > > > ExtensionMapper.java ends up in an (invalid)
> null package.
> > > > > > > > > > (It's named
> > > > > > > > > > "null" and on the output src path.)
> > > > > > > > > >
> > > > > > > > > > All of the types, after the first array type,
> are listed with
> > > > > > > > > > "This was
> > > > > > > > > > an array!" in the comments, but have no array
> declarations in
> > > > > > > > > > their
> > > > > > > > > > _type_nn classes... the [] markers are not
> produced after the
> > > > > > > > > > first
> > > > > > > > > > repeating element.
> > > > > > > > > >
> > > > > > > > > > I have looked at trying to clean up this code to
> make it
> > > > > > > > > > usable, but I
> > > > > > > > > > would think that Axis2 should be producing code
> that, at the
> > > > > > > > > > very least,
> > > > > > > > > > would compile through the ant build if the
> wsdl2java succeeds,
> > > > > > > > > > which it
> > > > > > > > > > does complete in this case. If not, it should
> probably give me
> > > > > > > > > > an error
> > > > > > > > > > in the generation of the ADB code.
> > > > > > > > > >
> > > > > > > > > > Maybe its something simple or I'm just a dope,
> or both, but I
> > > > > > > > > > am lost.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
> axis-user-unsubscribe@ws.apache.org
> > > > > > > > > > For additional commands, e-mail:
> axis-user-help@ws.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Amila Suriarachchi,
> > > > > > > > > > WSO2 Inc.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> axis-user-unsubscribe@ws.apache.org
> > > > > > > > > For additional commands, e-mail:
> axis-user-help@ws.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> axis-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: wsdl2java generates incorrect/incomplete code
Posted by Jeff Greif <jg...@alumni.princeton.edu>.
Anne,
Thank you very much for taking the time to produce such a detailed answer.
The details are a little depressing for someone with software that
relies on being able to dynamically consume web services. For various
reasons, we don't support all possible wsdl-described services at
present, so it's not fatal that the lack of support for consistent
policy attachment makes some additional service types unsupported,
e.g. those that depend on policies you have to be told about
out-of-band, We'll have to track both the various standardization and
implementation efforts and see what develops.
Jeff
On 1/18/07, Anne Thomas Manes <at...@gmail.com> wrote:
> See inline...
>
> On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > Anne,
> >
> > As usual, you are a fount of useful information. Thanks for all you
> > do to explain the various SOA standards to the world.
> >
> > Questions:
> >
> > 1. What schema is supposed to be provided by ?xsd.
>
> Keep in mind that the URL query is a non-standard convention. Most
> systems support the "?wsdl" query, but very few support either "?xsd"
> or "?policy".
>
> But, assuming that an endpoint does support the "?xsd" query
> convention, then it should return a schema that defines the input and
> output messages supported by the endpoint. (This convention would be
> especially helpful for RESTful services that don't provide a WSDL
> definition.)
>
> >
> > a. Is it the schema containing the declarations of the types or
> > elements used as message parts?
>
> It should define the complete body message structures, which ought to
> be defined as root elements. Types or message parts aren't sufficient.
> If you are using RPC style, then you would have to depend on the WSDL
> to provide the information required to define the message structure.
> (RPC style only defines types, not the root element of the message.)
>
> >
> > b. What if that information is contained in several schemas?
>
> A message contains a single element ( a root element); therefore, that
> element must be defined in a single schema (although it can certainly
> import or include other schemas). For this convention to work, though,
> all message structures supported by the endpoint must be defined in a
> single schema. For efficiency sake, you probably want to make sure
> that the "?xml" query returns the actual schemas and doesn't return a
> bunch of imports that then requires a bunch more queries.
>
> > c. Does this access schemas contained in the types section of the
> > wsdl and/or imports from those schemas?
>
> The convention is that it returns a schema that describes the input
> and output messages. How it goes about getting that schema is an
> implementation feature of the system supporting the convention. If
> Axis2 chose to implement this convention, it might require the
> developer to provide the schema as a configuration parameter, or it
> might automatically generate the schema by extracting the appropriate
> info from the WSDL.
>
> >
> > 2. Starting from a correct and consistent wsdl descriptor, is there a
> > deterministic algorithm that finds all the policy metadata?
>
> Only if the WSDL embeds all policy information via
> WS-PolicyAttachment. There is no requirement that the policies must be
> attached to the WSDL. The preferred method for retrieving all metadata
> is to use WS-MetadataExchange.
>
> > a. If the policies are embedded in the wsdl and/or referenced in
> > the wsdl, does extracting all the embedded ones and retrieving all the
> > references (recursively if that's necessary), will that be all of the
> > policies that apply?
>
> Again, only if the WSDL embeds all policy information.
>
> > b. Will there be any policies that apply that are not referenced
> > or embedded in the wsdl?
>
> It's possible. As a best practice, it's a good idea to attach all
> applicable policies to the WSDL.
>
> > c. If policies must be retrieved from a UDDI repository, is that
> > repository referenced in the wsdl or is there some out-of-band process
> > that must be followed to determine its existence?
>
> I've never seen an extension to WSDL that provides a means to
> reference a UDDI bindingTemplate (the UDDI entry that represents a
> service endpoint). Keep in mind that typically, you're querying UDDI
> to find a service, its endpoints, and its metadata. If you already
> have the endpoint, then you should be able to query the endpoint to
> get its metadata using WS-MetedataExchange.
>
> I suppose we could define another query convention: append "?uddi" to
> the access point URL, and it should return a link to the UDDI
> bindingTemplate that describes it.
>
> (FYI: UDDI is a registry, not a repository. It does not host the
> policies (or WSDLs or XSDs), it simply provides pointers to all the
> metadata that apply to the service.
>
> > d. Similarly for access via ?policy.
>
> If the service endpoint follows this convention, then the "?policy"
> query should return a WS-Policy file that contains all policies that
> apply to the service.
>
> > 3. Do the queries service-endpoint?policy and service-endpoint?xsd
> > produce exceptions when not implemented, or do they produce some empty
> > result? If they produce a result, is it guaranteed that the result
> > contains or references (perhaps recursively) all the policies or
> > schemas needed to consume the web service?
>
> The convention hasn't been standardized. What happens today when you
> issue a "?wsdl" query to a service that doesn't support the
> convention? My guess is that you would get a 404 Not Found.
>
> > 4. Do you ever need to use more than one of the various methods
> > (query-url, wsdl-cracking, Ws-MetadataExchange or UDDI) of obtaining
> > the metadata, or is any one that doesn't fail equivalent to any other
> > that doesn't fail?
>
> If the service follows the conventions properly, then you should be
> able to get all metadata using any one of the methods. But I
> absolutely would not depend on any service implementing any of these
> conventions properly today. None of these conventions has been
> standardized yet.
>
> The one closest to standardization is WS-PolicyAttachment (which
> enables "WSDL-cracking" and UDDI), but keep in mind that only a few
> systems support WS-Policy at this time, and most systems that do
> support WS-Policy only use it for security and maybe reliability
> policies.
>
> WS-MetadataExchange has not yet been submitted to a standards body.
>
> I've never seen anyone attempt to document the url-query convention.
>
> >
> > Jeff
> >
> > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > The way it supposed to work is thus:
> > >
> > > - A web service has various metadata files associated with it:
> > > - WSDL defines the supported interfaces, MEPs, and bindings
> > > - XSD defines the message formats
> > > - WS-Policy defines its constraints and capabilities
> > > (policies can be embedded in the WSDL or attached via UDDI)
> > > - You have various means to locate the metadata
> > > - Look it up via UDDI (all metadata should be registered,
> > > WS-PolicyAttachment defines how policies are attached via UDDI)
> > > - Query the service for its metadata using WS-MetadataExchange
> > > - Query the service access point, appending "?wsdl", "?xsd", and "?policy"
> > > to the URL and hope that the service supports this convention
> > >
> > > Anne
> > > On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > > > Anne,
> > > >
> > > > So if you want to dynamically consume web services based on the wsdl
> > > > alone, the WS-Policy constructs have to be embedded there and the
> > > > client machinery has to know how to process them to determine what
> > > > headers are required, if any? Is this the way it's supposed to work?
> > > >
> > > > Is the alternative to get the WS-Policy requirements from some
> > > > different repository? Is there a regular scheme related to UDDI or
> > > > something that provides this?
> > > >
> > > > Jeff
> > > >
> > > > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > > > Bruce,
> > > > >
> > > > ...
> > > > > But I reiterate my earlier comment. I strongly discourage you from
> > > > > defining headers in the WSDL. The WSDL represents the information that
> > > > > the application should be responsible for. Typically headers are added
> > > > > to the message and processed by the middleware, not by the
> > > > > application. Therefore the requirement for headers should be specified
> > > > > separately -- preferably using WS-Policy, even though it isn't final
> > > > > yet.
> > > > >
> > > > > I also *strongly* recommend that you not define your own header
> > > > > formats, but rather that you conform to standard SOAP extensions -- in
> > > > > your case WS-Addressing and WS-Security. (You've used standard element
> > > > > definitions from WS-Addressing and XML Signature, but you haven't
> > > > > followed the standard header formats for using these elements.)
> > > > >
> > > > > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > > > > for you, and they will do so in an interoperable way. But you mustn't
> > > > > define the headers in the WSDL -- you must configure them in the
> > > > > config file.
> > > > >
> > > > > Anne
> > > > >
> > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > First, let me sincerely thank you for your rapid response.
> > > > > >
> > > > > > I had originally questioned the other developers on that repeated import
> > > > > > of the namespace and been told it was ok. I probably have to be more
> > > > > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > > > > am new to this WSDL stuff.. previous services I have deployed were from
> > > > > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > > > > >
> > > > > > At least I have ammo to go back to them and have their manager apply the
> > > > > > "2 by 4" process... ;-)
> > > > > >
> > > > > > Next here are the other two xsd's that I had left off.
> > > > > >
> > > > > > again, thanks.
> > > > > >
> > > > > >
> > > > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > > > Bruce,
> > > > > > >
> > > > > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > > > > know if this is what's causing your problem, but it's a good place to
> > > > > > > start.
> > > > > > >
> > > > > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > > > > schemas, and your goal is to import both schemas, then you must define
> > > > > > > a schema with the same target namespace and <xs:include> the schemas
> > > > > > > into the namespace. e.g.:
> > > > > > >
> > > > > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="qualified">
> > > > > > > <xs:include
> > > > > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > > > > <xs:include
> > > > > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > Another error that I found: you must not specify the parameterOrder
> > > > > > > attribute in the <wsdl:operation> definition when using document
> > > > > > > style. (It is only used with RPC style.)
> > > > > > >
> > > > > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > > > > especially if you are using standard headers. (The XMLBeans error
> > > > > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > > > > define your header requirements using WS-Policy and configuration
> > > > > > > files.
> > > > > > >
> > > > > > > Also, in regards to schema you did provide
> > > > > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > > > > advice:
> > > > > > >
> > > > > > > - Avoid using anonymous types. Rather than defining structures as
> > > > > > > elements, define them as named types, and then define elements as
> > > > > > > those types. e.g.:
> > > > > > >
> > > > > > > Do this:
> > > > > > >
> > > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > > > > >
> > > > > > > Rather than this:
> > > > > > >
> > > > > > > <xs:element name="BaselineItemDataLoop">
> > > > > > > <xs:complexType>
> > > > > > > <xs:sequence>
> > > > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > > </xs:element>
> > > > > > >
> > > > > > > And I recommend being cautious about defining each element as a global
> > > > > > > element. The only elements that really should be defined as global
> > > > > > > elements are those elements that will be the root of a document. i.e,
> > > > > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > > > > referencing it from the type definition, define the element within the
> > > > > > > type definition and reference its type, e.g.:
> > > > > > >
> > > > > > >
> > > > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > > > > >
> > > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="BaselineItemDataSegment"
> > > > > > > type="baselineItemDataSegment
> > > > > > > minOccurs="0"/>
> > > > > > > <xs:element name="ReferenceIdentificationSegment"
> > > > > > > type="referenceIdentificationSegment"
> > > > > > > minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > Anne
> > > > > > >
> > > > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > > Sure... sorry.
> > > > > > > >
> > > > > > > > Also, when using xmlbeans binding, I get the following error:
> > > > > > > >
> > > > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > Retrieving schema at
> > > > > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > > Retrieving schema at
> > > > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > > > > to
> > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId
> > > > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId
> > > > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > > > Exception in thread "main"
> > > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > > > > at
> > > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > > > > Caused by: java.lang.RuntimeException:
> > > > > > > > java.lang.reflect.InvocationTargetException
> > > > > > > > at
> > > > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > > > > at
> > > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > > > > ... 2 more
> > > > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > > > at
> > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > > at
> > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > > at
> > > > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > > > > ... 3 more
> > > > > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > > at
> > > > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > > > > ... 8 more
> > > > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > > at
> > > > > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > > > at
> > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > > at
> > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > > at
> > > > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > > > > at
> > > > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > > > > ... 8 more
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > > > > Can you attach your fih-header.xsd file?
> > > > > > > > >
> > > > > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > > > > create
> > > > > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > > > > what seems
> > > > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > > > >
> > > > > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > > > > >
> > > > > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > > > > the
> > > > > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > > > > WDSCi) seem
> > > > > > > > > to agree that they are at least valid.
> > > > > > > > >
> > > > > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > > > > end up in
> > > > > > > > > the default package with empty package statements
> > > > > > > > > ("package ;"). The
> > > > > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > > > > (It's named
> > > > > > > > > "null" and on the output src path.)
> > > > > > > > >
> > > > > > > > > All of the types, after the first array type, are listed with
> > > > > > > > > "This was
> > > > > > > > > an array!" in the comments, but have no array declarations in
> > > > > > > > > their
> > > > > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > > > > first
> > > > > > > > > repeating element.
> > > > > > > > >
> > > > > > > > > I have looked at trying to clean up this code to make it
> > > > > > > > > usable, but I
> > > > > > > > > would think that Axis2 should be producing code that, at the
> > > > > > > > > very least,
> > > > > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > > > > which it
> > > > > > > > > does complete in this case. If not, it should probably give me
> > > > > > > > > an error
> > > > > > > > > in the generation of the ADB code.
> > > > > > > > >
> > > > > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > > > > am lost.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Amila Suriarachchi,
> > > > > > > > > WSO2 Inc.
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Anne Thomas Manes <at...@gmail.com>.
See inline...
On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> Anne,
>
> As usual, you are a fount of useful information. Thanks for all you
> do to explain the various SOA standards to the world.
>
> Questions:
>
> 1. What schema is supposed to be provided by ?xsd.
Keep in mind that the URL query is a non-standard convention. Most
systems support the "?wsdl" query, but very few support either "?xsd"
or "?policy".
But, assuming that an endpoint does support the "?xsd" query
convention, then it should return a schema that defines the input and
output messages supported by the endpoint. (This convention would be
especially helpful for RESTful services that don't provide a WSDL
definition.)
>
> a. Is it the schema containing the declarations of the types or
> elements used as message parts?
It should define the complete body message structures, which ought to
be defined as root elements. Types or message parts aren't sufficient.
If you are using RPC style, then you would have to depend on the WSDL
to provide the information required to define the message structure.
(RPC style only defines types, not the root element of the message.)
>
> b. What if that information is contained in several schemas?
A message contains a single element ( a root element); therefore, that
element must be defined in a single schema (although it can certainly
import or include other schemas). For this convention to work, though,
all message structures supported by the endpoint must be defined in a
single schema. For efficiency sake, you probably want to make sure
that the "?xml" query returns the actual schemas and doesn't return a
bunch of imports that then requires a bunch more queries.
> c. Does this access schemas contained in the types section of the
> wsdl and/or imports from those schemas?
The convention is that it returns a schema that describes the input
and output messages. How it goes about getting that schema is an
implementation feature of the system supporting the convention. If
Axis2 chose to implement this convention, it might require the
developer to provide the schema as a configuration parameter, or it
might automatically generate the schema by extracting the appropriate
info from the WSDL.
>
> 2. Starting from a correct and consistent wsdl descriptor, is there a
> deterministic algorithm that finds all the policy metadata?
Only if the WSDL embeds all policy information via
WS-PolicyAttachment. There is no requirement that the policies must be
attached to the WSDL. The preferred method for retrieving all metadata
is to use WS-MetadataExchange.
> a. If the policies are embedded in the wsdl and/or referenced in
> the wsdl, does extracting all the embedded ones and retrieving all the
> references (recursively if that's necessary), will that be all of the
> policies that apply?
Again, only if the WSDL embeds all policy information.
> b. Will there be any policies that apply that are not referenced
> or embedded in the wsdl?
It's possible. As a best practice, it's a good idea to attach all
applicable policies to the WSDL.
> c. If policies must be retrieved from a UDDI repository, is that
> repository referenced in the wsdl or is there some out-of-band process
> that must be followed to determine its existence?
I've never seen an extension to WSDL that provides a means to
reference a UDDI bindingTemplate (the UDDI entry that represents a
service endpoint). Keep in mind that typically, you're querying UDDI
to find a service, its endpoints, and its metadata. If you already
have the endpoint, then you should be able to query the endpoint to
get its metadata using WS-MetedataExchange.
I suppose we could define another query convention: append "?uddi" to
the access point URL, and it should return a link to the UDDI
bindingTemplate that describes it.
(FYI: UDDI is a registry, not a repository. It does not host the
policies (or WSDLs or XSDs), it simply provides pointers to all the
metadata that apply to the service.
> d. Similarly for access via ?policy.
If the service endpoint follows this convention, then the "?policy"
query should return a WS-Policy file that contains all policies that
apply to the service.
> 3. Do the queries service-endpoint?policy and service-endpoint?xsd
> produce exceptions when not implemented, or do they produce some empty
> result? If they produce a result, is it guaranteed that the result
> contains or references (perhaps recursively) all the policies or
> schemas needed to consume the web service?
The convention hasn't been standardized. What happens today when you
issue a "?wsdl" query to a service that doesn't support the
convention? My guess is that you would get a 404 Not Found.
> 4. Do you ever need to use more than one of the various methods
> (query-url, wsdl-cracking, Ws-MetadataExchange or UDDI) of obtaining
> the metadata, or is any one that doesn't fail equivalent to any other
> that doesn't fail?
If the service follows the conventions properly, then you should be
able to get all metadata using any one of the methods. But I
absolutely would not depend on any service implementing any of these
conventions properly today. None of these conventions has been
standardized yet.
The one closest to standardization is WS-PolicyAttachment (which
enables "WSDL-cracking" and UDDI), but keep in mind that only a few
systems support WS-Policy at this time, and most systems that do
support WS-Policy only use it for security and maybe reliability
policies.
WS-MetadataExchange has not yet been submitted to a standards body.
I've never seen anyone attempt to document the url-query convention.
>
> Jeff
>
> On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > The way it supposed to work is thus:
> >
> > - A web service has various metadata files associated with it:
> > - WSDL defines the supported interfaces, MEPs, and bindings
> > - XSD defines the message formats
> > - WS-Policy defines its constraints and capabilities
> > (policies can be embedded in the WSDL or attached via UDDI)
> > - You have various means to locate the metadata
> > - Look it up via UDDI (all metadata should be registered,
> > WS-PolicyAttachment defines how policies are attached via UDDI)
> > - Query the service for its metadata using WS-MetadataExchange
> > - Query the service access point, appending "?wsdl", "?xsd", and "?policy"
> > to the URL and hope that the service supports this convention
> >
> > Anne
> > On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > > Anne,
> > >
> > > So if you want to dynamically consume web services based on the wsdl
> > > alone, the WS-Policy constructs have to be embedded there and the
> > > client machinery has to know how to process them to determine what
> > > headers are required, if any? Is this the way it's supposed to work?
> > >
> > > Is the alternative to get the WS-Policy requirements from some
> > > different repository? Is there a regular scheme related to UDDI or
> > > something that provides this?
> > >
> > > Jeff
> > >
> > > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > > Bruce,
> > > >
> > > ...
> > > > But I reiterate my earlier comment. I strongly discourage you from
> > > > defining headers in the WSDL. The WSDL represents the information that
> > > > the application should be responsible for. Typically headers are added
> > > > to the message and processed by the middleware, not by the
> > > > application. Therefore the requirement for headers should be specified
> > > > separately -- preferably using WS-Policy, even though it isn't final
> > > > yet.
> > > >
> > > > I also *strongly* recommend that you not define your own header
> > > > formats, but rather that you conform to standard SOAP extensions -- in
> > > > your case WS-Addressing and WS-Security. (You've used standard element
> > > > definitions from WS-Addressing and XML Signature, but you haven't
> > > > followed the standard header formats for using these elements.)
> > > >
> > > > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > > > for you, and they will do so in an interoperable way. But you mustn't
> > > > define the headers in the WSDL -- you must configure them in the
> > > > config file.
> > > >
> > > > Anne
> > > >
> > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > First, let me sincerely thank you for your rapid response.
> > > > >
> > > > > I had originally questioned the other developers on that repeated import
> > > > > of the namespace and been told it was ok. I probably have to be more
> > > > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > > > am new to this WSDL stuff.. previous services I have deployed were from
> > > > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > > > >
> > > > > At least I have ammo to go back to them and have their manager apply the
> > > > > "2 by 4" process... ;-)
> > > > >
> > > > > Next here are the other two xsd's that I had left off.
> > > > >
> > > > > again, thanks.
> > > > >
> > > > >
> > > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > > Bruce,
> > > > > >
> > > > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > > > know if this is what's causing your problem, but it's a good place to
> > > > > > start.
> > > > > >
> > > > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > > > schemas, and your goal is to import both schemas, then you must define
> > > > > > a schema with the same target namespace and <xs:include> the schemas
> > > > > > into the namespace. e.g.:
> > > > > >
> > > > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="qualified">
> > > > > > <xs:include
> > > > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > > > <xs:include
> > > > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > Another error that I found: you must not specify the parameterOrder
> > > > > > attribute in the <wsdl:operation> definition when using document
> > > > > > style. (It is only used with RPC style.)
> > > > > >
> > > > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > > > especially if you are using standard headers. (The XMLBeans error
> > > > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > > > define your header requirements using WS-Policy and configuration
> > > > > > files.
> > > > > >
> > > > > > Also, in regards to schema you did provide
> > > > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > > > advice:
> > > > > >
> > > > > > - Avoid using anonymous types. Rather than defining structures as
> > > > > > elements, define them as named types, and then define elements as
> > > > > > those types. e.g.:
> > > > > >
> > > > > > Do this:
> > > > > >
> > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > <xs:sequence>
> > > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > > > >
> > > > > > Rather than this:
> > > > > >
> > > > > > <xs:element name="BaselineItemDataLoop">
> > > > > > <xs:complexType>
> > > > > > <xs:sequence>
> > > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > </xs:element>
> > > > > >
> > > > > > And I recommend being cautious about defining each element as a global
> > > > > > element. The only elements that really should be defined as global
> > > > > > elements are those elements that will be the root of a document. i.e,
> > > > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > > > referencing it from the type definition, define the element within the
> > > > > > type definition and reference its type, e.g.:
> > > > > >
> > > > > >
> > > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > > > >
> > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="BaselineItemDataSegment"
> > > > > > type="baselineItemDataSegment
> > > > > > minOccurs="0"/>
> > > > > > <xs:element name="ReferenceIdentificationSegment"
> > > > > > type="referenceIdentificationSegment"
> > > > > > minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > Anne
> > > > > >
> > > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > Sure... sorry.
> > > > > > >
> > > > > > > Also, when using xmlbeans binding, I get the following error:
> > > > > > >
> > > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Retrieving schema at
> > > > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > Retrieving schema at
> > > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > > > to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
> > > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
> > > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > > Exception in thread "main"
> > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > > > at
> > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > > > Caused by: java.lang.RuntimeException:
> > > > > > > java.lang.reflect.InvocationTargetException
> > > > > > > at
> > > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > > > at
> > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > > > ... 2 more
> > > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > > at
> > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > at
> > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > at
> > > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > > > ... 3 more
> > > > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > at
> > > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > > > ... 8 more
> > > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > at
> > > > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > > at
> > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > at
> > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > at
> > > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > > > at
> > > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > > > ... 8 more
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > > > Can you attach your fih-header.xsd file?
> > > > > > > >
> > > > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > > > create
> > > > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > > > what seems
> > > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > > >
> > > > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > > > >
> > > > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > > > the
> > > > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > > > WDSCi) seem
> > > > > > > > to agree that they are at least valid.
> > > > > > > >
> > > > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > > > end up in
> > > > > > > > the default package with empty package statements
> > > > > > > > ("package ;"). The
> > > > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > > > (It's named
> > > > > > > > "null" and on the output src path.)
> > > > > > > >
> > > > > > > > All of the types, after the first array type, are listed with
> > > > > > > > "This was
> > > > > > > > an array!" in the comments, but have no array declarations in
> > > > > > > > their
> > > > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > > > first
> > > > > > > > repeating element.
> > > > > > > >
> > > > > > > > I have looked at trying to clean up this code to make it
> > > > > > > > usable, but I
> > > > > > > > would think that Axis2 should be producing code that, at the
> > > > > > > > very least,
> > > > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > > > which it
> > > > > > > > does complete in this case. If not, it should probably give me
> > > > > > > > an error
> > > > > > > > in the generation of the ADB code.
> > > > > > > >
> > > > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > > > am lost.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Amila Suriarachchi,
> > > > > > > > WSO2 Inc.
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Jeff Greif <jg...@alumni.princeton.edu>.
Anne,
As usual, you are a fount of useful information. Thanks for all you
do to explain the various SOA standards to the world.
Questions:
1. What schema is supposed to be provided by ?xsd.
a. Is it the schema containing the declarations of the types or
elements used as message parts?
b. What if that information is contained in several schemas?
c. Does this access schemas contained in the types section of the
wsdl and/or imports from those schemas?
2. Starting from a correct and consistent wsdl descriptor, is there a
deterministic algorithm that finds all the policy metadata?
a. If the policies are embedded in the wsdl and/or referenced in
the wsdl, does extracting all the embedded ones and retrieving all the
references (recursively if that's necessary), will that be all of the
policies that apply?
b. Will there be any policies that apply that are not referenced
or embedded in the wsdl?
c. If policies must be retrieved from a UDDI repository, is that
repository referenced in the wsdl or is there some out-of-band process
that must be followed to determine its existence?
d. Similarly for access via ?policy.
3. Do the queries service-endpoint?policy and service-endpoint?xsd
produce exceptions when not implemented, or do they produce some empty
result? If they produce a result, is it guaranteed that the result
contains or references (perhaps recursively) all the policies or
schemas needed to consume the web service?
4. Do you ever need to use more than one of the various methods
(query-url, wsdl-cracking, Ws-MetadataExchange or UDDI) of obtaining
the metadata, or is any one that doesn't fail equivalent to any other
that doesn't fail?
Jeff
On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> The way it supposed to work is thus:
>
> - A web service has various metadata files associated with it:
> - WSDL defines the supported interfaces, MEPs, and bindings
> - XSD defines the message formats
> - WS-Policy defines its constraints and capabilities
> (policies can be embedded in the WSDL or attached via UDDI)
> - You have various means to locate the metadata
> - Look it up via UDDI (all metadata should be registered,
> WS-PolicyAttachment defines how policies are attached via UDDI)
> - Query the service for its metadata using WS-MetadataExchange
> - Query the service access point, appending "?wsdl", "?xsd", and "?policy"
> to the URL and hope that the service supports this convention
>
> Anne
> On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> > Anne,
> >
> > So if you want to dynamically consume web services based on the wsdl
> > alone, the WS-Policy constructs have to be embedded there and the
> > client machinery has to know how to process them to determine what
> > headers are required, if any? Is this the way it's supposed to work?
> >
> > Is the alternative to get the WS-Policy requirements from some
> > different repository? Is there a regular scheme related to UDDI or
> > something that provides this?
> >
> > Jeff
> >
> > On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > Bruce,
> > >
> > ...
> > > But I reiterate my earlier comment. I strongly discourage you from
> > > defining headers in the WSDL. The WSDL represents the information that
> > > the application should be responsible for. Typically headers are added
> > > to the message and processed by the middleware, not by the
> > > application. Therefore the requirement for headers should be specified
> > > separately -- preferably using WS-Policy, even though it isn't final
> > > yet.
> > >
> > > I also *strongly* recommend that you not define your own header
> > > formats, but rather that you conform to standard SOAP extensions -- in
> > > your case WS-Addressing and WS-Security. (You've used standard element
> > > definitions from WS-Addressing and XML Signature, but you haven't
> > > followed the standard header formats for using these elements.)
> > >
> > > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > > for you, and they will do so in an interoperable way. But you mustn't
> > > define the headers in the WSDL -- you must configure them in the
> > > config file.
> > >
> > > Anne
> > >
> > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > First, let me sincerely thank you for your rapid response.
> > > >
> > > > I had originally questioned the other developers on that repeated import
> > > > of the namespace and been told it was ok. I probably have to be more
> > > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > > am new to this WSDL stuff.. previous services I have deployed were from
> > > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > > >
> > > > At least I have ammo to go back to them and have their manager apply the
> > > > "2 by 4" process... ;-)
> > > >
> > > > Next here are the other two xsd's that I had left off.
> > > >
> > > > again, thanks.
> > > >
> > > >
> > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > Bruce,
> > > > >
> > > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > > know if this is what's causing your problem, but it's a good place to
> > > > > start.
> > > > >
> > > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > > schemas, and your goal is to import both schemas, then you must define
> > > > > a schema with the same target namespace and <xs:include> the schemas
> > > > > into the namespace. e.g.:
> > > > >
> > > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="qualified">
> > > > > <xs:include
> > > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > > <xs:include
> > > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > > </xs:schema>
> > > > >
> > > > > Another error that I found: you must not specify the parameterOrder
> > > > > attribute in the <wsdl:operation> definition when using document
> > > > > style. (It is only used with RPC style.)
> > > > >
> > > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > > especially if you are using standard headers. (The XMLBeans error
> > > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > > define your header requirements using WS-Policy and configuration
> > > > > files.
> > > > >
> > > > > Also, in regards to schema you did provide
> > > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > > advice:
> > > > >
> > > > > - Avoid using anonymous types. Rather than defining structures as
> > > > > elements, define them as named types, and then define elements as
> > > > > those types. e.g.:
> > > > >
> > > > > Do this:
> > > > >
> > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > <xs:sequence>
> > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > > >
> > > > > Rather than this:
> > > > >
> > > > > <xs:element name="BaselineItemDataLoop">
> > > > > <xs:complexType>
> > > > > <xs:sequence>
> > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:element>
> > > > >
> > > > > And I recommend being cautious about defining each element as a global
> > > > > element. The only elements that really should be defined as global
> > > > > elements are those elements that will be the root of a document. i.e,
> > > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > > referencing it from the type definition, define the element within the
> > > > > type definition and reference its type, e.g.:
> > > > >
> > > > >
> > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > > >
> > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > <xs:sequence>
> > > > > <xs:element name="BaselineItemDataSegment"
> > > > > type="baselineItemDataSegment
> > > > > minOccurs="0"/>
> > > > > <xs:element name="ReferenceIdentificationSegment"
> > > > > type="referenceIdentificationSegment"
> > > > > minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > Anne
> > > > >
> > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > Sure... sorry.
> > > > > >
> > > > > > Also, when using xmlbeans binding, I get the following error:
> > > > > >
> > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Retrieving schema at
> > > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > Retrieving schema at
> > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > > to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId
> > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId
> > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > Exception in thread "main"
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > > Caused by: java.lang.RuntimeException:
> > > > > > java.lang.reflect.InvocationTargetException
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > > ... 2 more
> > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > > ... 3 more
> > > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > at
> > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > > ... 8 more
> > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > at
> > > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > at
> > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > > at
> > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > > ... 8 more
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > > Can you attach your fih-header.xsd file?
> > > > > > >
> > > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > > create
> > > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > > what seems
> > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > >
> > > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > > >
> > > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > > the
> > > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > > WDSCi) seem
> > > > > > > to agree that they are at least valid.
> > > > > > >
> > > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > > end up in
> > > > > > > the default package with empty package statements
> > > > > > > ("package ;"). The
> > > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > > (It's named
> > > > > > > "null" and on the output src path.)
> > > > > > >
> > > > > > > All of the types, after the first array type, are listed with
> > > > > > > "This was
> > > > > > > an array!" in the comments, but have no array declarations in
> > > > > > > their
> > > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > > first
> > > > > > > repeating element.
> > > > > > >
> > > > > > > I have looked at trying to clean up this code to make it
> > > > > > > usable, but I
> > > > > > > would think that Axis2 should be producing code that, at the
> > > > > > > very least,
> > > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > > which it
> > > > > > > does complete in this case. If not, it should probably give me
> > > > > > > an error
> > > > > > > in the generation of the ADB code.
> > > > > > >
> > > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > > am lost.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Amila Suriarachchi,
> > > > > > > WSO2 Inc.
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Anne Thomas Manes <at...@gmail.com>.
The way it supposed to work is thus:
- A web service has various metadata files associated with it:
- WSDL defines the supported interfaces, MEPs, and bindings
- XSD defines the message formats
- WS-Policy defines its constraints and capabilities
(policies can be embedded in the WSDL or attached via UDDI)
- You have various means to locate the metadata
- Look it up via UDDI (all metadata should be registered,
WS-PolicyAttachment defines how policies are attached via UDDI)
- Query the service for its metadata using WS-MetadataExchange
- Query the service access point, appending "?wsdl", "?xsd", and "?policy"
to the URL and hope that the service supports this convention
Anne
On 1/17/07, Jeff Greif <jg...@alumni.princeton.edu> wrote:
> Anne,
>
> So if you want to dynamically consume web services based on the wsdl
> alone, the WS-Policy constructs have to be embedded there and the
> client machinery has to know how to process them to determine what
> headers are required, if any? Is this the way it's supposed to work?
>
> Is the alternative to get the WS-Policy requirements from some
> different repository? Is there a regular scheme related to UDDI or
> something that provides this?
>
> Jeff
>
> On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > Bruce,
> >
> ...
> > But I reiterate my earlier comment. I strongly discourage you from
> > defining headers in the WSDL. The WSDL represents the information that
> > the application should be responsible for. Typically headers are added
> > to the message and processed by the middleware, not by the
> > application. Therefore the requirement for headers should be specified
> > separately -- preferably using WS-Policy, even though it isn't final
> > yet.
> >
> > I also *strongly* recommend that you not define your own header
> > formats, but rather that you conform to standard SOAP extensions -- in
> > your case WS-Addressing and WS-Security. (You've used standard element
> > definitions from WS-Addressing and XML Signature, but you haven't
> > followed the standard header formats for using these elements.)
> >
> > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > for you, and they will do so in an interoperable way. But you mustn't
> > define the headers in the WSDL -- you must configure them in the
> > config file.
> >
> > Anne
> >
> > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > First, let me sincerely thank you for your rapid response.
> > >
> > > I had originally questioned the other developers on that repeated import
> > > of the namespace and been told it was ok. I probably have to be more
> > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > am new to this WSDL stuff.. previous services I have deployed were from
> > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > >
> > > At least I have ammo to go back to them and have their manager apply the
> > > "2 by 4" process... ;-)
> > >
> > > Next here are the other two xsd's that I had left off.
> > >
> > > again, thanks.
> > >
> > >
> > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > Bruce,
> > > >
> > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > know if this is what's causing your problem, but it's a good place to
> > > > start.
> > > >
> > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > schemas, and your goal is to import both schemas, then you must define
> > > > a schema with the same target namespace and <xs:include> the schemas
> > > > into the namespace. e.g.:
> > > >
> > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="qualified">
> > > > <xs:include
> > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > <xs:include
> > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > </xs:schema>
> > > >
> > > > Another error that I found: you must not specify the parameterOrder
> > > > attribute in the <wsdl:operation> definition when using document
> > > > style. (It is only used with RPC style.)
> > > >
> > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > especially if you are using standard headers. (The XMLBeans error
> > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > define your header requirements using WS-Policy and configuration
> > > > files.
> > > >
> > > > Also, in regards to schema you did provide
> > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > advice:
> > > >
> > > > - Avoid using anonymous types. Rather than defining structures as
> > > > elements, define them as named types, and then define elements as
> > > > those types. e.g.:
> > > >
> > > > Do this:
> > > >
> > > > <xs:complexType name="baselineItemDataLoop">
> > > > <xs:sequence>
> > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > >
> > > > Rather than this:
> > > >
> > > > <xs:element name="BaselineItemDataLoop">
> > > > <xs:complexType>
> > > > <xs:sequence>
> > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:element>
> > > >
> > > > And I recommend being cautious about defining each element as a global
> > > > element. The only elements that really should be defined as global
> > > > elements are those elements that will be the root of a document. i.e,
> > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > referencing it from the type definition, define the element within the
> > > > type definition and reference its type, e.g.:
> > > >
> > > >
> > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > >
> > > > <xs:complexType name="baselineItemDataLoop">
> > > > <xs:sequence>
> > > > <xs:element name="BaselineItemDataSegment"
> > > > type="baselineItemDataSegment
> > > > minOccurs="0"/>
> > > > <xs:element name="ReferenceIdentificationSegment"
> > > > type="referenceIdentificationSegment"
> > > > minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > Anne
> > > >
> > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > Sure... sorry.
> > > > >
> > > > > Also, when using xmlbeans binding, I get the following error:
> > > > >
> > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Retrieving schema at
> > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > Retrieving schema at
> > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > [/fih/1.0/fih-header.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId
> > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId
> > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > Exception in thread "main"
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > Caused by: java.lang.RuntimeException:
> > > > > java.lang.reflect.InvocationTargetException
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > ... 2 more
> > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > at
> > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > ... 3 more
> > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > value for type of processContents attribute in xs:wildcard
> > > > > at
> > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > ... 8 more
> > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > value for type of processContents attribute in xs:wildcard
> > > > > at
> > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > at
> > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > at
> > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > at
> > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > ... 8 more
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > Can you attach your fih-header.xsd file?
> > > > > >
> > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > create
> > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > what seems
> > > > > > to be, relatively simple wsdl and xsd's.
> > > > > >
> > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > >
> > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > the
> > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > WDSCi) seem
> > > > > > to agree that they are at least valid.
> > > > > >
> > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > end up in
> > > > > > the default package with empty package statements
> > > > > > ("package ;"). The
> > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > (It's named
> > > > > > "null" and on the output src path.)
> > > > > >
> > > > > > All of the types, after the first array type, are listed with
> > > > > > "This was
> > > > > > an array!" in the comments, but have no array declarations in
> > > > > > their
> > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > first
> > > > > > repeating element.
> > > > > >
> > > > > > I have looked at trying to clean up this code to make it
> > > > > > usable, but I
> > > > > > would think that Axis2 should be producing code that, at the
> > > > > > very least,
> > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > which it
> > > > > > does complete in this case. If not, it should probably give me
> > > > > > an error
> > > > > > in the generation of the ADB code.
> > > > > >
> > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > am lost.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Amila Suriarachchi,
> > > > > > WSO2 Inc.
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Jeff Greif <jg...@alumni.princeton.edu>.
Anne,
So if you want to dynamically consume web services based on the wsdl
alone, the WS-Policy constructs have to be embedded there and the
client machinery has to know how to process them to determine what
headers are required, if any? Is this the way it's supposed to work?
Is the alternative to get the WS-Policy requirements from some
different repository? Is there a regular scheme related to UDDI or
something that provides this?
Jeff
On 1/17/07, Anne Thomas Manes <at...@gmail.com> wrote:
> Bruce,
>
...
> But I reiterate my earlier comment. I strongly discourage you from
> defining headers in the WSDL. The WSDL represents the information that
> the application should be responsible for. Typically headers are added
> to the message and processed by the middleware, not by the
> application. Therefore the requirement for headers should be specified
> separately -- preferably using WS-Policy, even though it isn't final
> yet.
>
> I also *strongly* recommend that you not define your own header
> formats, but rather that you conform to standard SOAP extensions -- in
> your case WS-Addressing and WS-Security. (You've used standard element
> definitions from WS-Addressing and XML Signature, but you haven't
> followed the standard header formats for using these elements.)
>
> Axis2 can automatically manage WS-Addressing and WS-Security headers
> for you, and they will do so in an interoperable way. But you mustn't
> define the headers in the WSDL -- you must configure them in the
> config file.
>
> Anne
>
> On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > First, let me sincerely thank you for your rapid response.
> >
> > I had originally questioned the other developers on that repeated import
> > of the namespace and been told it was ok. I probably have to be more
> > forceful when my gut says it's wrong... but, as you can probably tell, I
> > am new to this WSDL stuff.. previous services I have deployed were from
> > POJOs and not defined by or through WSDL, and I am no xml expert either.
> >
> > At least I have ammo to go back to them and have their manager apply the
> > "2 by 4" process... ;-)
> >
> > Next here are the other two xsd's that I had left off.
> >
> > again, thanks.
> >
> >
> > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > Bruce,
> > >
> > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > know if this is what's causing your problem, but it's a good place to
> > > start.
> > >
> > > In your WSDL <types> section, you attempt to import the same namespace
> > > twice. This is not allowed. If the namespace is defined in multiple
> > > schemas, and your goal is to import both schemas, then you must define
> > > a schema with the same target namespace and <xs:include> the schemas
> > > into the namespace. e.g.:
> > >
> > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="qualified">
> > > <xs:include
> > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > <xs:include
> > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > </xs:schema>
> > >
> > > Another error that I found: you must not specify the parameterOrder
> > > attribute in the <wsdl:operation> definition when using document
> > > style. (It is only used with RPC style.)
> > >
> > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > especially if you are using standard headers. (The XMLBeans error
> > > indicates that you are using WS-Addressing and DSIG.) You should
> > > define your header requirements using WS-Policy and configuration
> > > files.
> > >
> > > Also, in regards to schema you did provide
> > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > advice:
> > >
> > > - Avoid using anonymous types. Rather than defining structures as
> > > elements, define them as named types, and then define elements as
> > > those types. e.g.:
> > >
> > > Do this:
> > >
> > > <xs:complexType name="baselineItemDataLoop">
> > > <xs:sequence>
> > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > >
> > > Rather than this:
> > >
> > > <xs:element name="BaselineItemDataLoop">
> > > <xs:complexType>
> > > <xs:sequence>
> > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:element>
> > >
> > > And I recommend being cautious about defining each element as a global
> > > element. The only elements that really should be defined as global
> > > elements are those elements that will be the root of a document. i.e,
> > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > referencing it from the type definition, define the element within the
> > > type definition and reference its type, e.g.:
> > >
> > >
> > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > >
> > > <xs:complexType name="baselineItemDataLoop">
> > > <xs:sequence>
> > > <xs:element name="BaselineItemDataSegment"
> > > type="baselineItemDataSegment
> > > minOccurs="0"/>
> > > <xs:element name="ReferenceIdentificationSegment"
> > > type="referenceIdentificationSegment"
> > > minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > Anne
> > >
> > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > Sure... sorry.
> > > >
> > > > Also, when using xmlbeans binding, I get the following error:
> > > >
> > > > Using AXIS2_HOME: /usr/local/axis2
> > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Retrieving schema at
> > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > Retrieving schema at
> > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > [/fih/1.0/fih-header.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId
> > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId
> > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > Exception in thread "main"
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > at
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > Caused by: java.lang.RuntimeException:
> > > > java.lang.reflect.InvocationTargetException
> > > > at
> > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > at
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > ... 2 more
> > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > at
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > at
> > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > ... 3 more
> > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > value for type of processContents attribute in xs:wildcard
> > > > at
> > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > ... 8 more
> > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > value for type of processContents attribute in xs:wildcard
> > > > at
> > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > at
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > at
> > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > at
> > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > ... 8 more
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > Can you attach your fih-header.xsd file?
> > > > >
> > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > create
> > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > what seems
> > > > > to be, relatively simple wsdl and xsd's.
> > > > >
> > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > >
> > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > the
> > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > WDSCi) seem
> > > > > to agree that they are at least valid.
> > > > >
> > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > end up in
> > > > > the default package with empty package statements
> > > > > ("package ;"). The
> > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > (It's named
> > > > > "null" and on the output src path.)
> > > > >
> > > > > All of the types, after the first array type, are listed with
> > > > > "This was
> > > > > an array!" in the comments, but have no array declarations in
> > > > > their
> > > > > _type_nn classes... the [] markers are not produced after the
> > > > > first
> > > > > repeating element.
> > > > >
> > > > > I have looked at trying to clean up this code to make it
> > > > > usable, but I
> > > > > would think that Axis2 should be producing code that, at the
> > > > > very least,
> > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > which it
> > > > > does complete in this case. If not, it should probably give me
> > > > > an error
> > > > > in the generation of the ADB code.
> > > > >
> > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > am lost.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Amila Suriarachchi,
> > > > > WSO2 Inc.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
you call 10MB big? HA! I download System i software and Redhat
distributions... that's big. Send away... my email should be able to
handle anything less than a couple of GB...
On Wed, 2007-01-17 at 19:56 -0500, Anne Thomas Manes wrote:
> I use the Cape Clear SOA Editor tool. It's free, but not open source.
> No support. I have permission to distribute it, so I can send it to
> you if you like. It's a big file, though. (>10MB)
>
> Anne
>
> On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > Again, thank you so much for the effort and information.
> >
> > What tool is it that you are using to validate this stuff? And, is it a
> > commercial product or open source tool?
> >
> >
> > On Wed, 2007-01-17 at 13:20 -0500, Anne Thomas Manes wrote:
> > > Bruce,
> > >
> > > I took the WSDL file, commented out the imports, pasted the schemas
> > > inline, and validated the WSDL. I found one error:
> > >
> > > There is no schema component of the name [ds:Signature] defined
> > > in the WSDL either via imported or embedded schema.
> > >
> > > I don't understand why this error comes up, because as far as I can
> > > tell, the DSig namespace is properly imported, and certainly the
> > > Signature element is properly defined in the DSig namespace. I know
> > > that quite a few folks have experienced problems when trying to use
> > > the DSig namespace, so my guess is that many tools have trouble with
> > > the "#" in the namespace URI.
> > >
> > > My tool also raised two warnings:
> > >
> > > You have nested sequences (which should be okay)
> > > You have a maxOccurs attribute on an xsd:sequence declaration
> > > (something to avoid)
> > >
> > > Something else I noticed: The request and reply schemas do not specify
> > > elementFormDefault="qualified". This isn't an error, but it often
> > > causes interoperability errors.
> > >
> > > But I reiterate my earlier comment. I strongly discourage you from
> > > defining headers in the WSDL. The WSDL represents the information that
> > > the application should be responsible for. Typically headers are added
> > > to the message and processed by the middleware, not by the
> > > application. Therefore the requirement for headers should be specified
> > > separately -- preferably using WS-Policy, even though it isn't final
> > > yet.
> > >
> > > I also *strongly* recommend that you not define your own header
> > > formats, but rather that you conform to standard SOAP extensions -- in
> > > your case WS-Addressing and WS-Security. (You've used standard element
> > > definitions from WS-Addressing and XML Signature, but you haven't
> > > followed the standard header formats for using these elements.)
> > >
> > > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > > for you, and they will do so in an interoperable way. But you mustn't
> > > define the headers in the WSDL -- you must configure them in the
> > > config file.
> > >
> > > Anne
> > >
> > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > First, let me sincerely thank you for your rapid response.
> > > >
> > > > I had originally questioned the other developers on that repeated import
> > > > of the namespace and been told it was ok. I probably have to be more
> > > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > > am new to this WSDL stuff.. previous services I have deployed were from
> > > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > > >
> > > > At least I have ammo to go back to them and have their manager apply the
> > > > "2 by 4" process... ;-)
> > > >
> > > > Next here are the other two xsd's that I had left off.
> > > >
> > > > again, thanks.
> > > >
> > > >
> > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > Bruce,
> > > > >
> > > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > > know if this is what's causing your problem, but it's a good place to
> > > > > start.
> > > > >
> > > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > > schemas, and your goal is to import both schemas, then you must define
> > > > > a schema with the same target namespace and <xs:include> the schemas
> > > > > into the namespace. e.g.:
> > > > >
> > > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="qualified">
> > > > > <xs:include
> > > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > > <xs:include
> > > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > > </xs:schema>
> > > > >
> > > > > Another error that I found: you must not specify the parameterOrder
> > > > > attribute in the <wsdl:operation> definition when using document
> > > > > style. (It is only used with RPC style.)
> > > > >
> > > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > > especially if you are using standard headers. (The XMLBeans error
> > > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > > define your header requirements using WS-Policy and configuration
> > > > > files.
> > > > >
> > > > > Also, in regards to schema you did provide
> > > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > > advice:
> > > > >
> > > > > - Avoid using anonymous types. Rather than defining structures as
> > > > > elements, define them as named types, and then define elements as
> > > > > those types. e.g.:
> > > > >
> > > > > Do this:
> > > > >
> > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > <xs:sequence>
> > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > > >
> > > > > Rather than this:
> > > > >
> > > > > <xs:element name="BaselineItemDataLoop">
> > > > > <xs:complexType>
> > > > > <xs:sequence>
> > > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:element>
> > > > >
> > > > > And I recommend being cautious about defining each element as a global
> > > > > element. The only elements that really should be defined as global
> > > > > elements are those elements that will be the root of a document. i.e,
> > > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > > referencing it from the type definition, define the element within the
> > > > > type definition and reference its type, e.g.:
> > > > >
> > > > >
> > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > > >
> > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > <xs:sequence>
> > > > > <xs:element name="BaselineItemDataSegment"
> > > > > type="baselineItemDataSegment
> > > > > minOccurs="0"/>
> > > > > <xs:element name="ReferenceIdentificationSegment"
> > > > > type="referenceIdentificationSegment"
> > > > > minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > Anne
> > > > >
> > > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > Sure... sorry.
> > > > > >
> > > > > > Also, when using xmlbeans binding, I get the following error:
> > > > > >
> > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Retrieving schema at
> > > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > Retrieving schema at
> > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > > to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId
> > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId
> > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > $Axis2EntityResolver resolveEntity
> > > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > Exception in thread "main"
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > > Caused by: java.lang.RuntimeException:
> > > > > > java.lang.reflect.InvocationTargetException
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > > ... 2 more
> > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > at
> > > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > > ... 3 more
> > > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > at
> > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > > ... 8 more
> > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > at
> > > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > at
> > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > > at
> > > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > > ... 8 more
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > > Can you attach your fih-header.xsd file?
> > > > > > >
> > > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > > create
> > > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > > what seems
> > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > >
> > > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > > >
> > > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > > the
> > > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > > WDSCi) seem
> > > > > > > to agree that they are at least valid.
> > > > > > >
> > > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > > end up in
> > > > > > > the default package with empty package statements
> > > > > > > ("package ;"). The
> > > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > > (It's named
> > > > > > > "null" and on the output src path.)
> > > > > > >
> > > > > > > All of the types, after the first array type, are listed with
> > > > > > > "This was
> > > > > > > an array!" in the comments, but have no array declarations in
> > > > > > > their
> > > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > > first
> > > > > > > repeating element.
> > > > > > >
> > > > > > > I have looked at trying to clean up this code to make it
> > > > > > > usable, but I
> > > > > > > would think that Axis2 should be producing code that, at the
> > > > > > > very least,
> > > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > > which it
> > > > > > > does complete in this case. If not, it should probably give me
> > > > > > > an error
> > > > > > > in the generation of the ADB code.
> > > > > > >
> > > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > > am lost.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Amila Suriarachchi,
> > > > > > > WSO2 Inc.
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Anne Thomas Manes <at...@gmail.com>.
I use the Cape Clear SOA Editor tool. It's free, but not open source.
No support. I have permission to distribute it, so I can send it to
you if you like. It's a big file, though. (>10MB)
Anne
On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> Again, thank you so much for the effort and information.
>
> What tool is it that you are using to validate this stuff? And, is it a
> commercial product or open source tool?
>
>
> On Wed, 2007-01-17 at 13:20 -0500, Anne Thomas Manes wrote:
> > Bruce,
> >
> > I took the WSDL file, commented out the imports, pasted the schemas
> > inline, and validated the WSDL. I found one error:
> >
> > There is no schema component of the name [ds:Signature] defined
> > in the WSDL either via imported or embedded schema.
> >
> > I don't understand why this error comes up, because as far as I can
> > tell, the DSig namespace is properly imported, and certainly the
> > Signature element is properly defined in the DSig namespace. I know
> > that quite a few folks have experienced problems when trying to use
> > the DSig namespace, so my guess is that many tools have trouble with
> > the "#" in the namespace URI.
> >
> > My tool also raised two warnings:
> >
> > You have nested sequences (which should be okay)
> > You have a maxOccurs attribute on an xsd:sequence declaration
> > (something to avoid)
> >
> > Something else I noticed: The request and reply schemas do not specify
> > elementFormDefault="qualified". This isn't an error, but it often
> > causes interoperability errors.
> >
> > But I reiterate my earlier comment. I strongly discourage you from
> > defining headers in the WSDL. The WSDL represents the information that
> > the application should be responsible for. Typically headers are added
> > to the message and processed by the middleware, not by the
> > application. Therefore the requirement for headers should be specified
> > separately -- preferably using WS-Policy, even though it isn't final
> > yet.
> >
> > I also *strongly* recommend that you not define your own header
> > formats, but rather that you conform to standard SOAP extensions -- in
> > your case WS-Addressing and WS-Security. (You've used standard element
> > definitions from WS-Addressing and XML Signature, but you haven't
> > followed the standard header formats for using these elements.)
> >
> > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > for you, and they will do so in an interoperable way. But you mustn't
> > define the headers in the WSDL -- you must configure them in the
> > config file.
> >
> > Anne
> >
> > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > First, let me sincerely thank you for your rapid response.
> > >
> > > I had originally questioned the other developers on that repeated import
> > > of the namespace and been told it was ok. I probably have to be more
> > > forceful when my gut says it's wrong... but, as you can probably tell, I
> > > am new to this WSDL stuff.. previous services I have deployed were from
> > > POJOs and not defined by or through WSDL, and I am no xml expert either.
> > >
> > > At least I have ammo to go back to them and have their manager apply the
> > > "2 by 4" process... ;-)
> > >
> > > Next here are the other two xsd's that I had left off.
> > >
> > > again, thanks.
> > >
> > >
> > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > Bruce,
> > > >
> > > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > > know if this is what's causing your problem, but it's a good place to
> > > > start.
> > > >
> > > > In your WSDL <types> section, you attempt to import the same namespace
> > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > schemas, and your goal is to import both schemas, then you must define
> > > > a schema with the same target namespace and <xs:include> the schemas
> > > > into the namespace. e.g.:
> > > >
> > > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="qualified">
> > > > <xs:include
> > > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > <xs:include
> > > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > </xs:schema>
> > > >
> > > > Another error that I found: you must not specify the parameterOrder
> > > > attribute in the <wsdl:operation> definition when using document
> > > > style. (It is only used with RPC style.)
> > > >
> > > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > > especially if you are using standard headers. (The XMLBeans error
> > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > define your header requirements using WS-Policy and configuration
> > > > files.
> > > >
> > > > Also, in regards to schema you did provide
> > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > advice:
> > > >
> > > > - Avoid using anonymous types. Rather than defining structures as
> > > > elements, define them as named types, and then define elements as
> > > > those types. e.g.:
> > > >
> > > > Do this:
> > > >
> > > > <xs:complexType name="baselineItemDataLoop">
> > > > <xs:sequence>
> > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > > >
> > > > Rather than this:
> > > >
> > > > <xs:element name="BaselineItemDataLoop">
> > > > <xs:complexType>
> > > > <xs:sequence>
> > > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:element>
> > > >
> > > > And I recommend being cautious about defining each element as a global
> > > > element. The only elements that really should be defined as global
> > > > elements are those elements that will be the root of a document. i.e,
> > > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > > referencing it from the type definition, define the element within the
> > > > type definition and reference its type, e.g.:
> > > >
> > > >
> > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > > >
> > > > <xs:complexType name="baselineItemDataLoop">
> > > > <xs:sequence>
> > > > <xs:element name="BaselineItemDataSegment"
> > > > type="baselineItemDataSegment
> > > > minOccurs="0"/>
> > > > <xs:element name="ReferenceIdentificationSegment"
> > > > type="referenceIdentificationSegment"
> > > > minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > Anne
> > > >
> > > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > Sure... sorry.
> > > > >
> > > > > Also, when using xmlbeans binding, I get the following error:
> > > > >
> > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Retrieving schema at
> > > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > Retrieving schema at
> > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > > to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > [/fih/1.0/fih-header.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId
> > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId
> > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > $Axis2EntityResolver resolveEntity
> > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > Exception in thread "main"
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > Caused by: java.lang.RuntimeException:
> > > > > java.lang.reflect.InvocationTargetException
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > ... 2 more
> > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > at
> > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > at
> > > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > ... 3 more
> > > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > value for type of processContents attribute in xs:wildcard
> > > > > at
> > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > ... 8 more
> > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > > value for type of processContents attribute in xs:wildcard
> > > > > at
> > > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > at
> > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > at
> > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > at
> > > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > ... 8 more
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > Can you attach your fih-header.xsd file?
> > > > > >
> > > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > > create
> > > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > > what seems
> > > > > > to be, relatively simple wsdl and xsd's.
> > > > > >
> > > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > >
> > > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > > the
> > > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > > WDSCi) seem
> > > > > > to agree that they are at least valid.
> > > > > >
> > > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > > end up in
> > > > > > the default package with empty package statements
> > > > > > ("package ;"). The
> > > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > > (It's named
> > > > > > "null" and on the output src path.)
> > > > > >
> > > > > > All of the types, after the first array type, are listed with
> > > > > > "This was
> > > > > > an array!" in the comments, but have no array declarations in
> > > > > > their
> > > > > > _type_nn classes... the [] markers are not produced after the
> > > > > > first
> > > > > > repeating element.
> > > > > >
> > > > > > I have looked at trying to clean up this code to make it
> > > > > > usable, but I
> > > > > > would think that Axis2 should be producing code that, at the
> > > > > > very least,
> > > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > > which it
> > > > > > does complete in this case. If not, it should probably give me
> > > > > > an error
> > > > > > in the generation of the ADB code.
> > > > > >
> > > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > > am lost.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Amila Suriarachchi,
> > > > > > WSO2 Inc.
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
Again, thank you so much for the effort and information.
What tool is it that you are using to validate this stuff? And, is it a
commercial product or open source tool?
On Wed, 2007-01-17 at 13:20 -0500, Anne Thomas Manes wrote:
> Bruce,
>
> I took the WSDL file, commented out the imports, pasted the schemas
> inline, and validated the WSDL. I found one error:
>
> There is no schema component of the name [ds:Signature] defined
> in the WSDL either via imported or embedded schema.
>
> I don't understand why this error comes up, because as far as I can
> tell, the DSig namespace is properly imported, and certainly the
> Signature element is properly defined in the DSig namespace. I know
> that quite a few folks have experienced problems when trying to use
> the DSig namespace, so my guess is that many tools have trouble with
> the "#" in the namespace URI.
>
> My tool also raised two warnings:
>
> You have nested sequences (which should be okay)
> You have a maxOccurs attribute on an xsd:sequence declaration
> (something to avoid)
>
> Something else I noticed: The request and reply schemas do not specify
> elementFormDefault="qualified". This isn't an error, but it often
> causes interoperability errors.
>
> But I reiterate my earlier comment. I strongly discourage you from
> defining headers in the WSDL. The WSDL represents the information that
> the application should be responsible for. Typically headers are added
> to the message and processed by the middleware, not by the
> application. Therefore the requirement for headers should be specified
> separately -- preferably using WS-Policy, even though it isn't final
> yet.
>
> I also *strongly* recommend that you not define your own header
> formats, but rather that you conform to standard SOAP extensions -- in
> your case WS-Addressing and WS-Security. (You've used standard element
> definitions from WS-Addressing and XML Signature, but you haven't
> followed the standard header formats for using these elements.)
>
> Axis2 can automatically manage WS-Addressing and WS-Security headers
> for you, and they will do so in an interoperable way. But you mustn't
> define the headers in the WSDL -- you must configure them in the
> config file.
>
> Anne
>
> On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > First, let me sincerely thank you for your rapid response.
> >
> > I had originally questioned the other developers on that repeated import
> > of the namespace and been told it was ok. I probably have to be more
> > forceful when my gut says it's wrong... but, as you can probably tell, I
> > am new to this WSDL stuff.. previous services I have deployed were from
> > POJOs and not defined by or through WSDL, and I am no xml expert either.
> >
> > At least I have ammo to go back to them and have their manager apply the
> > "2 by 4" process... ;-)
> >
> > Next here are the other two xsd's that I had left off.
> >
> > again, thanks.
> >
> >
> > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > Bruce,
> > >
> > > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > > know if this is what's causing your problem, but it's a good place to
> > > start.
> > >
> > > In your WSDL <types> section, you attempt to import the same namespace
> > > twice. This is not allowed. If the namespace is defined in multiple
> > > schemas, and your goal is to import both schemas, then you must define
> > > a schema with the same target namespace and <xs:include> the schemas
> > > into the namespace. e.g.:
> > >
> > > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="qualified">
> > > <xs:include
> > > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > <xs:include
> > > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > </xs:schema>
> > >
> > > Another error that I found: you must not specify the parameterOrder
> > > attribute in the <wsdl:operation> definition when using document
> > > style. (It is only used with RPC style.)
> > >
> > > As a general practice, it's a bad idea to define headers in your WSDL,
> > > especially if you are using standard headers. (The XMLBeans error
> > > indicates that you are using WS-Addressing and DSIG.) You should
> > > define your header requirements using WS-Policy and configuration
> > > files.
> > >
> > > Also, in regards to schema you did provide
> > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > advice:
> > >
> > > - Avoid using anonymous types. Rather than defining structures as
> > > elements, define them as named types, and then define elements as
> > > those types. e.g.:
> > >
> > > Do this:
> > >
> > > <xs:complexType name="baselineItemDataLoop">
> > > <xs:sequence>
> > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> > >
> > > Rather than this:
> > >
> > > <xs:element name="BaselineItemDataLoop">
> > > <xs:complexType>
> > > <xs:sequence>
> > > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:element>
> > >
> > > And I recommend being cautious about defining each element as a global
> > > element. The only elements that really should be defined as global
> > > elements are those elements that will be the root of a document. i.e,
> > > rather than defining "BaselineItemDataSegment" as a gloal element and
> > > referencing it from the type definition, define the element within the
> > > type definition and reference its type, e.g.:
> > >
> > >
> > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> > >
> > > <xs:complexType name="baselineItemDataLoop">
> > > <xs:sequence>
> > > <xs:element name="BaselineItemDataSegment"
> > > type="baselineItemDataSegment
> > > minOccurs="0"/>
> > > <xs:element name="ReferenceIdentificationSegment"
> > > type="referenceIdentificationSegment"
> > > minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > Anne
> > >
> > > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > Sure... sorry.
> > > >
> > > > Also, when using xmlbeans binding, I get the following error:
> > > >
> > > > Using AXIS2_HOME: /usr/local/axis2
> > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Retrieving schema at
> > > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > Retrieving schema at
> > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > > to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > [/fih/1.0/fih-header.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId
> > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId
> > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > $Axis2EntityResolver resolveEntity
> > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > Exception in thread "main"
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > > at
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > Caused by: java.lang.RuntimeException:
> > > > java.lang.reflect.InvocationTargetException
> > > > at
> > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > at
> > > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > ... 2 more
> > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > at
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > at
> > > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > ... 3 more
> > > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > value for type of processContents attribute in xs:wildcard
> > > > at
> > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > ... 8 more
> > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > > value for type of processContents attribute in xs:wildcard
> > > > at
> > > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > at
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > at
> > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > at
> > > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > ... 8 more
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > Can you attach your fih-header.xsd file?
> > > > >
> > > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > > create
> > > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > > what seems
> > > > > to be, relatively simple wsdl and xsd's.
> > > > >
> > > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > >
> > > > > I am being told that the wsdl and xsd information is valid (by
> > > > > the
> > > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > > WDSCi) seem
> > > > > to agree that they are at least valid.
> > > > >
> > > > > When I run wsdl2java with ADB binding, the message parts all
> > > > > end up in
> > > > > the default package with empty package statements
> > > > > ("package ;"). The
> > > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > > (It's named
> > > > > "null" and on the output src path.)
> > > > >
> > > > > All of the types, after the first array type, are listed with
> > > > > "This was
> > > > > an array!" in the comments, but have no array declarations in
> > > > > their
> > > > > _type_nn classes... the [] markers are not produced after the
> > > > > first
> > > > > repeating element.
> > > > >
> > > > > I have looked at trying to clean up this code to make it
> > > > > usable, but I
> > > > > would think that Axis2 should be producing code that, at the
> > > > > very least,
> > > > > would compile through the ant build if the wsdl2java succeeds,
> > > > > which it
> > > > > does complete in this case. If not, it should probably give me
> > > > > an error
> > > > > in the generation of the ADB code.
> > > > >
> > > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > > am lost.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Amila Suriarachchi,
> > > > > WSO2 Inc.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Anne Thomas Manes <at...@gmail.com>.
Bruce,
I took the WSDL file, commented out the imports, pasted the schemas
inline, and validated the WSDL. I found one error:
There is no schema component of the name [ds:Signature] defined
in the WSDL either via imported or embedded schema.
I don't understand why this error comes up, because as far as I can
tell, the DSig namespace is properly imported, and certainly the
Signature element is properly defined in the DSig namespace. I know
that quite a few folks have experienced problems when trying to use
the DSig namespace, so my guess is that many tools have trouble with
the "#" in the namespace URI.
My tool also raised two warnings:
You have nested sequences (which should be okay)
You have a maxOccurs attribute on an xsd:sequence declaration
(something to avoid)
Something else I noticed: The request and reply schemas do not specify
elementFormDefault="qualified". This isn't an error, but it often
causes interoperability errors.
But I reiterate my earlier comment. I strongly discourage you from
defining headers in the WSDL. The WSDL represents the information that
the application should be responsible for. Typically headers are added
to the message and processed by the middleware, not by the
application. Therefore the requirement for headers should be specified
separately -- preferably using WS-Policy, even though it isn't final
yet.
I also *strongly* recommend that you not define your own header
formats, but rather that you conform to standard SOAP extensions -- in
your case WS-Addressing and WS-Security. (You've used standard element
definitions from WS-Addressing and XML Signature, but you haven't
followed the standard header formats for using these elements.)
Axis2 can automatically manage WS-Addressing and WS-Security headers
for you, and they will do so in an interoperable way. But you mustn't
define the headers in the WSDL -- you must configure them in the
config file.
Anne
On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> First, let me sincerely thank you for your rapid response.
>
> I had originally questioned the other developers on that repeated import
> of the namespace and been told it was ok. I probably have to be more
> forceful when my gut says it's wrong... but, as you can probably tell, I
> am new to this WSDL stuff.. previous services I have deployed were from
> POJOs and not defined by or through WSDL, and I am no xml expert either.
>
> At least I have ammo to go back to them and have their manager apply the
> "2 by 4" process... ;-)
>
> Next here are the other two xsd's that I had left off.
>
> again, thanks.
>
>
> On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > Bruce,
> >
> > Giving the WSDL a quick look, I noticed that it is not valid. I don't
> > know if this is what's causing your problem, but it's a good place to
> > start.
> >
> > In your WSDL <types> section, you attempt to import the same namespace
> > twice. This is not allowed. If the namespace is defined in multiple
> > schemas, and your goal is to import both schemas, then you must define
> > a schema with the same target namespace and <xs:include> the schemas
> > into the namespace. e.g.:
> >
> > <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified">
> > <xs:include
> > schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > <xs:include
> > schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > </xs:schema>
> >
> > Another error that I found: you must not specify the parameterOrder
> > attribute in the <wsdl:operation> definition when using document
> > style. (It is only used with RPC style.)
> >
> > As a general practice, it's a bad idea to define headers in your WSDL,
> > especially if you are using standard headers. (The XMLBeans error
> > indicates that you are using WS-Addressing and DSIG.) You should
> > define your header requirements using WS-Policy and configuration
> > files.
> >
> > Also, in regards to schema you did provide
> > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > advice:
> >
> > - Avoid using anonymous types. Rather than defining structures as
> > elements, define them as named types, and then define elements as
> > those types. e.g.:
> >
> > Do this:
> >
> > <xs:complexType name="baselineItemDataLoop">
> > <xs:sequence>
> > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > </xs:sequence>
> > </xs:complexType>
> > <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
> >
> > Rather than this:
> >
> > <xs:element name="BaselineItemDataLoop">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> > <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > And I recommend being cautious about defining each element as a global
> > element. The only elements that really should be defined as global
> > elements are those elements that will be the root of a document. i.e,
> > rather than defining "BaselineItemDataSegment" as a gloal element and
> > referencing it from the type definition, define the element within the
> > type definition and reference its type, e.g.:
> >
> >
> > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> > (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
> >
> > <xs:complexType name="baselineItemDataLoop">
> > <xs:sequence>
> > <xs:element name="BaselineItemDataSegment"
> > type="baselineItemDataSegment
> > minOccurs="0"/>
> > <xs:element name="ReferenceIdentificationSegment"
> > type="referenceIdentificationSegment"
> > minOccurs="0"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > Anne
> >
> > On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > Sure... sorry.
> > >
> > > Also, when using xmlbeans binding, I get the following error:
> > >
> > > Using AXIS2_HOME: /usr/local/axis2
> > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > Retrieving schema at
> > > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > Retrieving schema at
> > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > > to
> > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > [/fih/1.0/fih-header.xsd]
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId
> > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId
> > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > $Axis2EntityResolver resolveEntity
> > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > Exception in thread "main"
> > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > > at
> > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > Caused by: java.lang.RuntimeException:
> > > java.lang.reflect.InvocationTargetException
> > > at
> > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > at
> > > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > ... 2 more
> > > Caused by: java.lang.reflect.InvocationTargetException
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > at
> > > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > ... 3 more
> > > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > value for type of processContents attribute in xs:wildcard
> > > at
> > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > ... 8 more
> > > Caused by: org.apache.xmlbeans.XmlException:
> > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > > value for type of processContents attribute in xs:wildcard
> > > at
> > > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > at
> > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > at
> > > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > ... 8 more
> > >
> > >
> > >
> > >
> > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > Can you attach your fih-header.xsd file?
> > > >
> > > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > > create
> > > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > > what seems
> > > > to be, relatively simple wsdl and xsd's.
> > > >
> > > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > >
> > > > I am being told that the wsdl and xsd information is valid (by
> > > > the
> > > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > > WDSCi) seem
> > > > to agree that they are at least valid.
> > > >
> > > > When I run wsdl2java with ADB binding, the message parts all
> > > > end up in
> > > > the default package with empty package statements
> > > > ("package ;"). The
> > > > ExtensionMapper.java ends up in an (invalid) null package.
> > > > (It's named
> > > > "null" and on the output src path.)
> > > >
> > > > All of the types, after the first array type, are listed with
> > > > "This was
> > > > an array!" in the comments, but have no array declarations in
> > > > their
> > > > _type_nn classes... the [] markers are not produced after the
> > > > first
> > > > repeating element.
> > > >
> > > > I have looked at trying to clean up this code to make it
> > > > usable, but I
> > > > would think that Axis2 should be producing code that, at the
> > > > very least,
> > > > would compile through the ant build if the wsdl2java succeeds,
> > > > which it
> > > > does complete in this case. If not, it should probably give me
> > > > an error
> > > > in the generation of the ADB code.
> > > >
> > > > Maybe its something simple or I'm just a dope, or both, but I
> > > > am lost.
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
First, let me sincerely thank you for your rapid response.
I had originally questioned the other developers on that repeated import
of the namespace and been told it was ok. I probably have to be more
forceful when my gut says it's wrong... but, as you can probably tell, I
am new to this WSDL stuff.. previous services I have deployed were from
POJOs and not defined by or through WSDL, and I am no xml expert either.
At least I have ammo to go back to them and have their manager apply the
"2 by 4" process... ;-)
Next here are the other two xsd's that I had left off.
again, thanks.
On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> Bruce,
>
> Giving the WSDL a quick look, I noticed that it is not valid. I don't
> know if this is what's causing your problem, but it's a good place to
> start.
>
> In your WSDL <types> section, you attempt to import the same namespace
> twice. This is not allowed. If the namespace is defined in multiple
> schemas, and your goal is to import both schemas, then you must define
> a schema with the same target namespace and <xs:include> the schemas
> into the namespace. e.g.:
>
> <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
> <xs:include
> schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> <xs:include
> schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> </xs:schema>
>
> Another error that I found: you must not specify the parameterOrder
> attribute in the <wsdl:operation> definition when using document
> style. (It is only used with RPC style.)
>
> As a general practice, it's a bad idea to define headers in your WSDL,
> especially if you are using standard headers. (The XMLBeans error
> indicates that you are using WS-Addressing and DSIG.) You should
> define your header requirements using WS-Policy and configuration
> files.
>
> Also, in regards to schema you did provide
> (targetNamespace="urn:/fih/purchase-order"), some best practices
> advice:
>
> - Avoid using anonymous types. Rather than defining structures as
> elements, define them as named types, and then define elements as
> those types. e.g.:
>
> Do this:
>
> <xs:complexType name="baselineItemDataLoop">
> <xs:sequence>
> <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
>
> Rather than this:
>
> <xs:element name="BaselineItemDataLoop">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
> <xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> And I recommend being cautious about defining each element as a global
> element. The only elements that really should be defined as global
> elements are those elements that will be the root of a document. i.e,
> rather than defining "BaselineItemDataSegment" as a gloal element and
> referencing it from the type definition, define the element within the
> type definition and reference its type, e.g.:
>
>
> We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> (You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
>
> <xs:complexType name="baselineItemDataLoop">
> <xs:sequence>
> <xs:element name="BaselineItemDataSegment"
> type="baselineItemDataSegment
> minOccurs="0"/>
> <xs:element name="ReferenceIdentificationSegment"
> type="referenceIdentificationSegment"
> minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
>
> Anne
>
> On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > Sure... sorry.
> >
> > Also, when using xmlbeans binding, I get the following error:
> >
> > Using AXIS2_HOME: /usr/local/axis2
> > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Retrieving schema at
> > 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > Retrieving schema at
> > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > to
> > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> > 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > [/fih/1.0/fih-header.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > and systemId [/1.0/receive-purchase-order-request.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId
> > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId
> > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > Exception in thread "main"
> > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > at
> > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > Caused by: java.lang.RuntimeException:
> > java.lang.reflect.InvocationTargetException
> > at
> > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > at
> > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > ... 2 more
> > Caused by: java.lang.reflect.InvocationTargetException
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> > org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > ... 3 more
> > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > value for type of processContents attribute in xs:wildcard
> > at
> > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > ... 8 more
> > Caused by: org.apache.xmlbeans.XmlException:
> > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > value for type of processContents attribute in xs:wildcard
> > at
> > org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > at
> > org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > ... 8 more
> >
> >
> >
> >
> > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > Can you attach your fih-header.xsd file?
> > >
> > > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > create
> > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > what seems
> > > to be, relatively simple wsdl and xsd's.
> > >
> > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > >
> > > I am being told that the wsdl and xsd information is valid (by
> > > the
> > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > WDSCi) seem
> > > to agree that they are at least valid.
> > >
> > > When I run wsdl2java with ADB binding, the message parts all
> > > end up in
> > > the default package with empty package statements
> > > ("package ;"). The
> > > ExtensionMapper.java ends up in an (invalid) null package.
> > > (It's named
> > > "null" and on the output src path.)
> > >
> > > All of the types, after the first array type, are listed with
> > > "This was
> > > an array!" in the comments, but have no array declarations in
> > > their
> > > _type_nn classes... the [] markers are not produced after the
> > > first
> > > repeating element.
> > >
> > > I have looked at trying to clean up this code to make it
> > > usable, but I
> > > would think that Axis2 should be producing code that, at the
> > > very least,
> > > would compile through the ant build if the wsdl2java succeeds,
> > > which it
> > > does complete in this case. If not, it should probably give me
> > > an error
> > > in the generation of the ADB code.
> > >
> > > Maybe its something simple or I'm just a dope, or both, but I
> > > am lost.
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by Anne Thomas Manes <at...@gmail.com>.
Bruce,
Giving the WSDL a quick look, I noticed that it is not valid. I don't
know if this is what's causing your problem, but it's a good place to
start.
In your WSDL <types> section, you attempt to import the same namespace
twice. This is not allowed. If the namespace is defined in multiple
schemas, and your goal is to import both schemas, then you must define
a schema with the same target namespace and <xs:include> the schemas
into the namespace. e.g.:
<xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:include
schemaLocation="1.0/receive-purchase-order-request.xsd"/>
<xs:include
schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
</xs:schema>
Another error that I found: you must not specify the parameterOrder
attribute in the <wsdl:operation> definition when using document
style. (It is only used with RPC style.)
As a general practice, it's a bad idea to define headers in your WSDL,
especially if you are using standard headers. (The XMLBeans error
indicates that you are using WS-Addressing and DSIG.) You should
define your header requirements using WS-Policy and configuration
files.
Also, in regards to schema you did provide
(targetNamespace="urn:/fih/purchase-order"), some best practices
advice:
- Avoid using anonymous types. Rather than defining structures as
elements, define them as named types, and then define elements as
those types. e.g.:
Do this:
<xs:complexType name="baselineItemDataLoop">
<xs:sequence>
<xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
<xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
Rather than this:
<xs:element name="BaselineItemDataLoop">
<xs:complexType>
<xs:sequence>
<xs:element ref="BaselineItemDataSegment" minOccurs="0"/>
<xs:element ref="ReferenceIdentificationSegment" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
And I recommend being cautious about defining each element as a global
element. The only elements that really should be defined as global
elements are those elements that will be the root of a document. i.e,
rather than defining "BaselineItemDataSegment" as a gloal element and
referencing it from the type definition, define the element within the
type definition and reference its type, e.g.:
We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
(You sent us the "http://www.fih.org/XML/WD0" namespace schema, instead.)
<xs:complexType name="baselineItemDataLoop">
<xs:sequence>
<xs:element name="BaselineItemDataSegment"
type="baselineItemDataSegment
minOccurs="0"/>
<xs:element name="ReferenceIdentificationSegment"
type="referenceIdentificationSegment"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Anne
On 1/17/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> Sure... sorry.
>
> Also, when using xmlbeans binding, I get the following error:
>
> Using AXIS2_HOME: /usr/local/axis2
> Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> Retrieving schema at
> 'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> Retrieving schema at
> 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> to
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> 'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> [/fih/1.0/fih-header.xsd]
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> and systemId [/1.0/receive-purchase-order-request.xsd]
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> and systemId [/1.0/receive-purchase-order-reply.xsd]
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId
> [http://www.w3.org/2000/09/xmldsig#] and systemId
> [/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId
> [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> $Axis2EntityResolver resolveEntity
> INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> systemId [/1.0/LimitedPurchaseOrder.xsd]
> Exception in thread "main"
> org.apache.axis2.wsdl.codegen.CodeGenerationException:
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> Caused by: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> ... 2 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> ... 3 more
> Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> cvc-enumeration-valid: string value 'none' is not a valid enumeration
> value for type of processContents attribute in xs:wildcard
> at
> org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> ... 8 more
> Caused by: org.apache.xmlbeans.XmlException:
> http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> cvc-enumeration-valid: string value 'none' is not a valid enumeration
> value for type of processContents attribute in xs:wildcard
> at
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> at
> org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> ... 8 more
>
>
>
>
> On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > Can you attach your fih-header.xsd file?
> >
> > On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > create
> > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > what seems
> > to be, relatively simple wsdl and xsd's.
> >
> > Below is the xsd and wsdl information. I have used FC4, FC5,
> > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> >
> > I am being told that the wsdl and xsd information is valid (by
> > the
> > original developers). Both NetBeans 5.5 and Eclipse (under
> > WDSCi) seem
> > to agree that they are at least valid.
> >
> > When I run wsdl2java with ADB binding, the message parts all
> > end up in
> > the default package with empty package statements
> > ("package ;"). The
> > ExtensionMapper.java ends up in an (invalid) null package.
> > (It's named
> > "null" and on the output src path.)
> >
> > All of the types, after the first array type, are listed with
> > "This was
> > an array!" in the comments, but have no array declarations in
> > their
> > _type_nn classes... the [] markers are not produced after the
> > first
> > repeating element.
> >
> > I have looked at trying to clean up this code to make it
> > usable, but I
> > would think that Axis2 should be producing code that, at the
> > very least,
> > would compile through the ant build if the wsdl2java succeeds,
> > which it
> > does complete in this case. If not, it should probably give me
> > an error
> > in the generation of the ADB code.
> >
> > Maybe its something simple or I'm just a dope, or both, but I
> > am lost.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: wsdl2java generates incorrect/incomplete code
Posted by R Bruce Hoffman <br...@iseries-admin.net>.
Sure... sorry.
Also, when using xmlbeans binding, I get the following error:
Using AXIS2_HOME: /usr/local/axis2
Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
Retrieving schema at
'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
Retrieving schema at
'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
to
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
[/fih/1.0/fih-header.xsd]
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
and systemId [/1.0/receive-purchase-order-request.xsd]
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
and systemId [/1.0/receive-purchase-order-reply.xsd]
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId
[http://www.w3.org/2000/09/xmldsig#] and systemId
[/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId
[http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
[/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
$Axis2EntityResolver resolveEntity
INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
systemId [/1.0/LimitedPurchaseOrder.xsd]
Exception in thread "main"
org.apache.axis2.wsdl.codegen.CodeGenerationException:
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
Caused by: java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
... 2 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
... 3 more
Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
cvc-enumeration-valid: string value 'none' is not a valid enumeration
value for type of processContents attribute in xs:wildcard
at
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
... 8 more
Caused by: org.apache.xmlbeans.XmlException:
http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
cvc-enumeration-valid: string value 'none' is not a valid enumeration
value for type of processContents attribute in xs:wildcard
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
at
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
... 8 more
On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> Can you attach your fih-header.xsd file?
>
> On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
> I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> create
> skeleton code and Axiom or XmlBeans artifacts correctly for,
> what seems
> to be, relatively simple wsdl and xsd's.
>
> Below is the xsd and wsdl information. I have used FC4, FC5,
> Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
>
> I am being told that the wsdl and xsd information is valid (by
> the
> original developers). Both NetBeans 5.5 and Eclipse (under
> WDSCi) seem
> to agree that they are at least valid.
>
> When I run wsdl2java with ADB binding, the message parts all
> end up in
> the default package with empty package statements
> ("package ;"). The
> ExtensionMapper.java ends up in an (invalid) null package.
> (It's named
> "null" and on the output src path.)
>
> All of the types, after the first array type, are listed with
> "This was
> an array!" in the comments, but have no array declarations in
> their
> _type_nn classes... the [] markers are not produced after the
> first
> repeating element.
>
> I have looked at trying to clean up this code to make it
> usable, but I
> would think that Axis2 should be producing code that, at the
> very least,
> would compile through the ant build if the wsdl2java succeeds,
> which it
> does complete in this case. If not, it should probably give me
> an error
> in the generation of the ADB code.
>
> Maybe its something simple or I'm just a dope, or both, but I
> am lost.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
Re: wsdl2java generates incorrect/incomplete code
Posted by Amila Suriarachchi <am...@gmail.com>.
Can you attach your fih-header.xsd file?
On 1/16/07, R Bruce Hoffman <br...@iseries-admin.net> wrote:
>
> I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly create
> skeleton code and Axiom or XmlBeans artifacts correctly for, what seems
> to be, relatively simple wsdl and xsd's.
>
> Below is the xsd and wsdl information. I have used FC4, FC5, Ubuntu and
> Debian Sarge. I have tried 1.1, a snapshot before 1.1.1 and 1.1.1releases. Sun java
> 1.5.0_09 and 10.
>
> I am being told that the wsdl and xsd information is valid (by the
> original developers). Both NetBeans 5.5 and Eclipse (under WDSCi) seem
> to agree that they are at least valid.
>
> When I run wsdl2java with ADB binding, the message parts all end up in
> the default package with empty package statements ("package ;"). The
> ExtensionMapper.java ends up in an (invalid) null package. (It's named
> "null" and on the output src path.)
>
> All of the types, after the first array type, are listed with "This was
> an array!" in the comments, but have no array declarations in their
> _type_nn classes... the [] markers are not produced after the first
> repeating element.
>
> I have looked at trying to clean up this code to make it usable, but I
> would think that Axis2 should be producing code that, at the very least,
> would compile through the ant build if the wsdl2java succeeds, which it
> does complete in this case. If not, it should probably give me an error
> in the generation of the ADB code.
>
> Maybe its something simple or I'm just a dope, or both, but I am lost.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
Amila Suriarachchi,
WSO2 Inc.