You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by David Kocher <dk...@itserve.ch> on 2004/07/02 09:29:55 UTC
Unsmarshalling exception
hi,
I am having problems querying the juddi using the recently released
JAXR API with jwsdp-1.4. I am however not sure if this is the
appropriate place to ask as it seems to be a problem with the JAXR API
or with the parsers used respecitively. However, the same request works
against the SYSTINET uddi.
The stack trace:
javax.xml.registry.JAXRException: javax.xml.bind.UnmarshalException:
Unexpected element {urn:uddi-org:api_v2}:name
at com.sun.xml.registry.uddi.Processor.processResponseJAXB(Unknown Source)
at com.sun.xml.registry.uddi.Processor.processRequestJAXB(Unknown Source)
at com.sun.xml.registry.uddi.UDDIMapper.findOrganizations(Unknown Source)
at
com.sun.xml.registry.uddi.BusinessQueryManagerImpl.findOrganizations(Unknown
Source)
Caused by: javax.xml.bind.UnmarshalException: Unexpected element
{urn:uddi-org:api_v2}:name
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.SAXUnmarshallerHandlerImpl.handleEvent(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.AbstractUnmarshallingEventHandlerImpl.reportError(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.AbstractUnmarshallingEventHandlerImpl.reportError(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.AbstractUnmarshallingEventHandlerImpl.unexpectedEnterElement(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.AbstractUnmarshallingEventHandlerImpl.enterElement(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.ServiceInfoTypeImpl$Unmarshaller.enterElement(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.ServiceInfosTypeImpl$Unmarshaller.enterElement(Unknown
Source)
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.SAXUnmarshallerHandlerImpl.startElement(Unknown
Source)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:177)
The juddi response looks good; almost the same as the response I get
from SYSTINET, only the namespace declaration is more detailed in the
juddi response:
HTTP/1.1 200 OK
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Fri, 02 Jul 2004 07:00:24 GMT
Server: Apache-Coyote/1.1
77d
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<businessList generic="2.0" operator="itserve.ch"
xmlns="urn:uddi-org:api_v2">
<businessInfos>
<businessInfo
businessKey="28ECD120-CB3A-11D8-9120-B1DCF22C37D1">
<name xml:lang="en">itServe AG</name>
<serviceInfos>
<serviceInfo
serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
<name xml:lang="en">SalaryDeclaration</name>
</serviceInfo>
<serviceInfo
serviceKey="290191A0-CB3A-11D8-91A0-F55D553AB48B">
<name xml:lang="en">SalaryDeclaration</name>
</serviceInfo>
<serviceInfo
serviceKey="2909CF00-CB3A-11D8-8F00-F1B2E4415A96">
<name xml:lang="en">SalaryDeclaration</name>
</serviceInfo>
</serviceInfos>
</businessInfo>
</businessInfos>
</businessList>
</soapenv:Body>
</soapenv:Envelope>
0
Am I missing something obvious? Thanks in advance!
-david
Re: Unsmarshalling exception
Posted by David Kocher <dk...@itserve.ch>.
http://nagoya.apache.org/jira/browse/JUDDI-29
Steve Viens wrote:
> Thanks David.
>
> Another rc sounds appropriate - we've got a few bugs to fix now.
>
> Would you mind bugging this?
>
> http://ws.apache.org/juddi/bugs.html
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 6:32 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> I have found where the problem is. In fact, it doesn't even works with
> the examples provided by SUN in the JWSDP release.
>
> The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
> serviceInfo element:
>
> <xsd:complexType name="serviceInfo">
> <xsd:sequence>
> <xsd:element ref="uddi:name" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
> use="required"/>
> <xsd:attribute name="businessKey"
> type="uddi:businessKey" use="required"/>
> </xsd:complexType>
>
> Both the serviceKey and businessKey are required attributes in the
> serviceInfo element. (This also applies for v3 of the UDDI schema)
>
> However, the response from juddi does NOT contain the businessKey
> attribute in the serviceInfo element; the response doesn't validate and
> we get the unmarshalling exception described in my previous mail.
>
> > <serviceInfo
> > serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> > <name xml:lang="en">SalaryDeclaration</name>
> > </serviceInfo>
>
> Please correct me if I've overseen something obvious.
>
> Would be nice if you can make another RC prior to the release of 0.9
> with the bugfix included.
>
> Thanks!
> -David
>
>
RE: Unsmarshalling exception
Posted by Steve Viens <st...@viens.net>.
Thanks David.
Another rc sounds appropriate - we've got a few bugs to fix now.
Would you mind bugging this?
http://ws.apache.org/juddi/bugs.html
Steve
-----Original Message-----
From: David Kocher [mailto:dko@itserve.ch]
Sent: Friday, July 02, 2004 6:32 AM
To: juddi-user@ws.apache.org
Subject: Re: Unsmarshalling exception
I have found where the problem is. In fact, it doesn't even works with
the examples provided by SUN in the JWSDP release.
The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
serviceInfo element:
<xsd:complexType name="serviceInfo">
<xsd:sequence>
<xsd:element ref="uddi:name" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="serviceKey" type="uddi:serviceKey"
use="required"/>
<xsd:attribute name="businessKey"
type="uddi:businessKey" use="required"/>
</xsd:complexType>
Both the serviceKey and businessKey are required attributes in the
serviceInfo element. (This also applies for v3 of the UDDI schema)
However, the response from juddi does NOT contain the businessKey
attribute in the serviceInfo element; the response doesn't validate and
we get the unmarshalling exception described in my previous mail.
> <serviceInfo
> serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> <name xml:lang="en">SalaryDeclaration</name>
> </serviceInfo>
Please correct me if I've overseen something obvious.
Would be nice if you can make another RC prior to the release of 0.9
with the bugfix included.
Thanks!
-David
Re: Unsmarshalling exception
Posted by David Kocher <dk...@itserve.ch>.
Great. Thank you very much!
Steve Viens wrote:
> Thanks,
>
> I've just committed a fix for this as well as for the bugs reported by
> Takayuki last night and will produce a 0.9rc3 over the weekend.
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 10:29 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> <?xml version="1.0" encoding="utf-8"?>
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP-ENV:Header/>
> <SOAP-ENV:Body>
> <find_business generic="2.0" xmlns="urn:uddi-org:api_v2">
> <findQualifiers>
> <findQualifier>sortByNameDesc</findQualifier>
> </findQualifiers>
> <name xml:lang="en">%Example%</name>
> </find_business>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> Steve Viens wrote:
>
>>David, one last question.
>>
>>Is the problem serviceInfo the result of performing a find_business or
>
>
>>a find_service?
>>
>>Steve
>>
>>-----Original Message-----
>>From: David Kocher [mailto:dko@itserve.ch]
>>Sent: Friday, July 02, 2004 9:56 AM
>>To: juddi-user@ws.apache.org
>>Subject: Re: Unsmarshalling exception
>>
>>
>>Steve,
>>
>>Yes, there is a business key value (
>>28ECD120-CB3A-11D8-9120-B1DCF22C37D1 ) Also, this business key exists
>
> as
>
>>a primary key in the BUSINESS_ENTITY table.
>>
>>-David
>>
>>Steve Viens wrote:
>>
>>
>>>David,
>>>
>>>Currently the source indicates that it will include a businessKey
>>>attribute in the ServiceInfo element if a busienssKey value is found
>>>for the service. It should be adding the attribute regardless (at
>>>least an empty value will pass validation) but could you confirm that
>>>the row in the BUSINESS_SERVICE table for the service in your example
>>>below (serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a
>>>businessKey value in the BUSINESS_KEY column. I believe it has to
>>>since the column uses the NOT NULL attribute but I just want to be
>>>sure.
>>>
>>>Steve
>>>
>>>-----Original Message-----
>>>From: David Kocher [mailto:dko@itserve.ch]
>>>Sent: Friday, July 02, 2004 6:32 AM
>>>To: juddi-user@ws.apache.org
>>>Subject: Re: Unsmarshalling exception
>>>
>>>
>>>I have found where the problem is. In fact, it doesn't even works with
>
>
>>>the examples provided by SUN in the JWSDP release.
>>>
>>>The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
>>>serviceInfo element:
>>>
>>> <xsd:complexType name="serviceInfo">
>>> <xsd:sequence>
>>> <xsd:element ref="uddi:name" minOccurs="0"
>>
>>maxOccurs="unbounded"/>
>>
>>> </xsd:sequence>
>>> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
>>>use="required"/>
>>> <xsd:attribute name="businessKey"
>>>type="uddi:businessKey" use="required"/>
>>> </xsd:complexType>
>>>
>>>Both the serviceKey and businessKey are required attributes in the
>>>serviceInfo element. (This also applies for v3 of the UDDI schema)
>>>
>>>However, the response from juddi does NOT contain the businessKey
>>>attribute in the serviceInfo element; the response doesn't validate
>>
>>and
>>
>>
>>>we get the unmarshalling exception described in my previous mail.
>>>
>>>
>>>><serviceInfo
>>>> serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
>>>> <name xml:lang="en">SalaryDeclaration</name>
>>>></serviceInfo>
>>>
>>>Please correct me if I've overseen something obvious.
>>>
>>>Would be nice if you can make another RC prior to the release of 0.9
>>>with the bugfix included.
>>>
>>>Thanks!
>>>-David
>>>
>>>
>>
>>
>>
>>
>
>
>
RE: Unsmarshalling exception
Posted by Steve Viens <st...@viens.net>.
Thanks,
I've just committed a fix for this as well as for the bugs reported by
Takayuki last night and will produce a 0.9rc3 over the weekend.
Steve
-----Original Message-----
From: David Kocher [mailto:dko@itserve.ch]
Sent: Friday, July 02, 2004 10:29 AM
To: juddi-user@ws.apache.org
Subject: Re: Unsmarshalling exception
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2">
<findQualifiers>
<findQualifier>sortByNameDesc</findQualifier>
</findQualifiers>
<name xml:lang="en">%Example%</name>
</find_business>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Steve Viens wrote:
> David, one last question.
>
> Is the problem serviceInfo the result of performing a find_business or
> a find_service?
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 9:56 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> Steve,
>
> Yes, there is a business key value (
> 28ECD120-CB3A-11D8-9120-B1DCF22C37D1 ) Also, this business key exists
as
>
> a primary key in the BUSINESS_ENTITY table.
>
> -David
>
> Steve Viens wrote:
>
>>David,
>>
>>Currently the source indicates that it will include a businessKey
>>attribute in the ServiceInfo element if a busienssKey value is found
>>for the service. It should be adding the attribute regardless (at
>>least an empty value will pass validation) but could you confirm that
>>the row in the BUSINESS_SERVICE table for the service in your example
>>below (serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a
>>businessKey value in the BUSINESS_KEY column. I believe it has to
>>since the column uses the NOT NULL attribute but I just want to be
>>sure.
>>
>>Steve
>>
>>-----Original Message-----
>>From: David Kocher [mailto:dko@itserve.ch]
>>Sent: Friday, July 02, 2004 6:32 AM
>>To: juddi-user@ws.apache.org
>>Subject: Re: Unsmarshalling exception
>>
>>
>>I have found where the problem is. In fact, it doesn't even works with
>>the examples provided by SUN in the JWSDP release.
>>
>>The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
>>serviceInfo element:
>>
>> <xsd:complexType name="serviceInfo">
>> <xsd:sequence>
>> <xsd:element ref="uddi:name" minOccurs="0"
>
> maxOccurs="unbounded"/>
>
>> </xsd:sequence>
>> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
>>use="required"/>
>> <xsd:attribute name="businessKey"
>>type="uddi:businessKey" use="required"/>
>> </xsd:complexType>
>>
>>Both the serviceKey and businessKey are required attributes in the
>>serviceInfo element. (This also applies for v3 of the UDDI schema)
>>
>>However, the response from juddi does NOT contain the businessKey
>>attribute in the serviceInfo element; the response doesn't validate
>
> and
>
>>we get the unmarshalling exception described in my previous mail.
>>
>> > <serviceInfo
>> > serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
>> > <name xml:lang="en">SalaryDeclaration</name>
>> > </serviceInfo>
>>
>>Please correct me if I've overseen something obvious.
>>
>>Would be nice if you can make another RC prior to the release of 0.9
>>with the bugfix included.
>>
>>Thanks!
>>-David
>>
>>
>
>
>
>
Re: Unsmarshalling exception
Posted by David Kocher <dk...@itserve.ch>.
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2">
<findQualifiers>
<findQualifier>sortByNameDesc</findQualifier>
</findQualifiers>
<name xml:lang="en">%Example%</name>
</find_business>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Steve Viens wrote:
> David, one last question.
>
> Is the problem serviceInfo the result of performing a find_business or a
> find_service?
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 9:56 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> Steve,
>
> Yes, there is a business key value (
> 28ECD120-CB3A-11D8-9120-B1DCF22C37D1 ) Also, this business key exists as
>
> a primary key in the BUSINESS_ENTITY table.
>
> -David
>
> Steve Viens wrote:
>
>>David,
>>
>>Currently the source indicates that it will include a businessKey
>>attribute in the ServiceInfo element if a busienssKey value is found
>>for the service. It should be adding the attribute regardless (at
>>least an empty value will pass validation) but could you confirm that
>>the row in the BUSINESS_SERVICE table for the service in your example
>>below (serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a
>>businessKey value in the BUSINESS_KEY column. I believe it has to
>>since the column uses the NOT NULL attribute but I just want to be
>>sure.
>>
>>Steve
>>
>>-----Original Message-----
>>From: David Kocher [mailto:dko@itserve.ch]
>>Sent: Friday, July 02, 2004 6:32 AM
>>To: juddi-user@ws.apache.org
>>Subject: Re: Unsmarshalling exception
>>
>>
>>I have found where the problem is. In fact, it doesn't even works with
>>the examples provided by SUN in the JWSDP release.
>>
>>The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
>>serviceInfo element:
>>
>> <xsd:complexType name="serviceInfo">
>> <xsd:sequence>
>> <xsd:element ref="uddi:name" minOccurs="0"
>
> maxOccurs="unbounded"/>
>
>> </xsd:sequence>
>> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
>>use="required"/>
>> <xsd:attribute name="businessKey"
>>type="uddi:businessKey" use="required"/>
>> </xsd:complexType>
>>
>>Both the serviceKey and businessKey are required attributes in the
>>serviceInfo element. (This also applies for v3 of the UDDI schema)
>>
>>However, the response from juddi does NOT contain the businessKey
>>attribute in the serviceInfo element; the response doesn't validate
>
> and
>
>>we get the unmarshalling exception described in my previous mail.
>>
>> > <serviceInfo
>> > serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
>> > <name xml:lang="en">SalaryDeclaration</name>
>> > </serviceInfo>
>>
>>Please correct me if I've overseen something obvious.
>>
>>Would be nice if you can make another RC prior to the release of 0.9
>>with the bugfix included.
>>
>>Thanks!
>>-David
>>
>>
>
>
>
>
RE: Unsmarshalling exception
Posted by Steve Viens <st...@viens.net>.
David, one last question.
Is the problem serviceInfo the result of performing a find_business or a
find_service?
Steve
-----Original Message-----
From: David Kocher [mailto:dko@itserve.ch]
Sent: Friday, July 02, 2004 9:56 AM
To: juddi-user@ws.apache.org
Subject: Re: Unsmarshalling exception
Steve,
Yes, there is a business key value (
28ECD120-CB3A-11D8-9120-B1DCF22C37D1 ) Also, this business key exists as
a primary key in the BUSINESS_ENTITY table.
-David
Steve Viens wrote:
> David,
>
> Currently the source indicates that it will include a businessKey
> attribute in the ServiceInfo element if a busienssKey value is found
> for the service. It should be adding the attribute regardless (at
> least an empty value will pass validation) but could you confirm that
> the row in the BUSINESS_SERVICE table for the service in your example
> below (serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a
> businessKey value in the BUSINESS_KEY column. I believe it has to
> since the column uses the NOT NULL attribute but I just want to be
> sure.
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 6:32 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> I have found where the problem is. In fact, it doesn't even works with
> the examples provided by SUN in the JWSDP release.
>
> The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
> serviceInfo element:
>
> <xsd:complexType name="serviceInfo">
> <xsd:sequence>
> <xsd:element ref="uddi:name" minOccurs="0"
maxOccurs="unbounded"/>
> </xsd:sequence>
> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
> use="required"/>
> <xsd:attribute name="businessKey"
> type="uddi:businessKey" use="required"/>
> </xsd:complexType>
>
> Both the serviceKey and businessKey are required attributes in the
> serviceInfo element. (This also applies for v3 of the UDDI schema)
>
> However, the response from juddi does NOT contain the businessKey
> attribute in the serviceInfo element; the response doesn't validate
and
> we get the unmarshalling exception described in my previous mail.
>
> > <serviceInfo
> > serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> > <name xml:lang="en">SalaryDeclaration</name>
> > </serviceInfo>
>
> Please correct me if I've overseen something obvious.
>
> Would be nice if you can make another RC prior to the release of 0.9
> with the bugfix included.
>
> Thanks!
> -David
>
>
Re: Unsmarshalling exception
Posted by David Kocher <dk...@itserve.ch>.
Steve,
Yes, there is a business key value (
28ECD120-CB3A-11D8-9120-B1DCF22C37D1 ) Also, this business key exists as
a primary key in the BUSINESS_ENTITY table.
-David
Steve Viens wrote:
> David,
>
> Currently the source indicates that it will include a businessKey
> attribute in the ServiceInfo element if a busienssKey value is found for
> the service. It should be adding the attribute regardless (at least an
> empty value will pass validation) but could you confirm that the row in
> the BUSINESS_SERVICE table for the service in your example below
> (serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a businessKey
> value in the BUSINESS_KEY column. I believe it has to since the column
> uses the NOT NULL attribute but I just want to be sure.
>
> Steve
>
> -----Original Message-----
> From: David Kocher [mailto:dko@itserve.ch]
> Sent: Friday, July 02, 2004 6:32 AM
> To: juddi-user@ws.apache.org
> Subject: Re: Unsmarshalling exception
>
>
> I have found where the problem is. In fact, it doesn't even works with
> the examples provided by SUN in the JWSDP release.
>
> The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
> serviceInfo element:
>
> <xsd:complexType name="serviceInfo">
> <xsd:sequence>
> <xsd:element ref="uddi:name" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> <xsd:attribute name="serviceKey" type="uddi:serviceKey"
> use="required"/>
> <xsd:attribute name="businessKey"
> type="uddi:businessKey" use="required"/>
> </xsd:complexType>
>
> Both the serviceKey and businessKey are required attributes in the
> serviceInfo element. (This also applies for v3 of the UDDI schema)
>
> However, the response from juddi does NOT contain the businessKey
> attribute in the serviceInfo element; the response doesn't validate and
> we get the unmarshalling exception described in my previous mail.
>
> > <serviceInfo
> > serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> > <name xml:lang="en">SalaryDeclaration</name>
> > </serviceInfo>
>
> Please correct me if I've overseen something obvious.
>
> Would be nice if you can make another RC prior to the release of 0.9
> with the bugfix included.
>
> Thanks!
> -David
>
>
RE: Unsmarshalling exception
Posted by Steve Viens <st...@viens.net>.
David,
Currently the source indicates that it will include a businessKey
attribute in the ServiceInfo element if a busienssKey value is found for
the service. It should be adding the attribute regardless (at least an
empty value will pass validation) but could you confirm that the row in
the BUSINESS_SERVICE table for the service in your example below
(serviceKey = 28F53590-CB3A-11D8-B590-94A6F2DB02CD) has a businessKey
value in the BUSINESS_KEY column. I believe it has to since the column
uses the NOT NULL attribute but I just want to be sure.
Steve
-----Original Message-----
From: David Kocher [mailto:dko@itserve.ch]
Sent: Friday, July 02, 2004 6:32 AM
To: juddi-user@ws.apache.org
Subject: Re: Unsmarshalling exception
I have found where the problem is. In fact, it doesn't even works with
the examples provided by SUN in the JWSDP release.
The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
serviceInfo element:
<xsd:complexType name="serviceInfo">
<xsd:sequence>
<xsd:element ref="uddi:name" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="serviceKey" type="uddi:serviceKey"
use="required"/>
<xsd:attribute name="businessKey"
type="uddi:businessKey" use="required"/>
</xsd:complexType>
Both the serviceKey and businessKey are required attributes in the
serviceInfo element. (This also applies for v3 of the UDDI schema)
However, the response from juddi does NOT contain the businessKey
attribute in the serviceInfo element; the response doesn't validate and
we get the unmarshalling exception described in my previous mail.
> <serviceInfo
> serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> <name xml:lang="en">SalaryDeclaration</name>
> </serviceInfo>
Please correct me if I've overseen something obvious.
Would be nice if you can make another RC prior to the release of 0.9
with the bugfix included.
Thanks!
-David
Re: Unsmarshalling exception
Posted by David Kocher <dk...@itserve.ch>.
I have found where the problem is. In fact, it doesn't even works with
the examples provided by SUN in the JWSDP release.
The uddi-v2 schema ( http://uddi.org/schema/uddi_v2.xsd ) defines the
serviceInfo element:
<xsd:complexType name="serviceInfo">
<xsd:sequence>
<xsd:element ref="uddi:name" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="serviceKey" type="uddi:serviceKey" use="required"/>
<xsd:attribute name="businessKey" type="uddi:businessKey" use="required"/>
</xsd:complexType>
Both the serviceKey and businessKey are required attributes in the
serviceInfo element. (This also applies for v3 of the UDDI schema)
However, the response from juddi does NOT contain the businessKey
attribute in the serviceInfo element; the response doesn't validate and
we get the unmarshalling exception described in my previous mail.
> <serviceInfo
> serviceKey="28F53590-CB3A-11D8-B590-94A6F2DB02CD">
> <name xml:lang="en">SalaryDeclaration</name>
> </serviceInfo>
Please correct me if I've overseen something obvious.
Would be nice if you can make another RC prior to the release of 0.9
with the bugfix included.
Thanks!
-David