This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 81298 - wsdl model having problem resolving portType when main wsdl and imported wsdl are having same targetNamespace
Summary: wsdl model having problem resolving portType when main wsdl and imported wsdl...
Status: VERIFIED DUPLICATE of bug 81842
Alias: None
Product: xml
Classification: Unclassified
Component: WSDL Model (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Nam Nguyen
Depends on:
Blocks: 80978
  Show dependency tree
Reported: 2006-07-28 01:51 UTC by Ritesh Adval
Modified: 2007-01-17 16:16 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

wsdl/xsd exhibiting problem (2.61 KB, application/octet-stream)
2006-07-28 02:01 UTC, Ritesh Adval

Note You need to log in before you can comment on or make changes to this bug.
Description Ritesh Adval 2006-07-28 01:51:23 UTC
This is from Asynchrousnous Sample Project. Attached are wsdl and xsd files.

Note that AsynchronousSampleClient.wsdl and AsynchronousSample.wsdl both have 
same targetNamespace (

AsynchronousSampleClient.wsdl imports AsynchronousSample.wsdl.

AsynchronousSampleClient.wsdl has binding:

<binding name="CallbackSoapBinding" type="tns:MyCallbackPortType">

which refers to portType MyCallbackPortType which is defined in


The problem is because of same targetNamespace in both of these wsdls,
when calling getPortType().get() on binding CallbackSoapBinding
it just finds out first matching wsdl which is AsynchronousSampleClient.wsdl.
And this does not have this MyCallbackPortType defined.

The solution should be to look into all the wsdl documents matching a 
targetNamespace and then find out first matching portType.
Comment 1 Ritesh Adval 2006-07-28 02:01:19 UTC
Created attachment 32275 [details]
wsdl/xsd exhibiting problem
Comment 2 Nam Nguyen 2006-07-28 07:56:16 UTC
Target for FCS, will fix in next milestone build.
Possible temporary work-around in the Asynchronous sample for beta is to rename
the targetNamespace of the client?
Comment 3 Nam Nguyen 2006-07-28 09:24:54 UTC
This is a bug since WSDL specs allow imported wsdl to have same target namespace
as the importing as well as multiple other wsdl's.  The fix is xml/wsdl/api
module class GlobalReferenceImpl to search for the referenced in all wsdl's
having the target namespace.

Justification for BETA waiver:
- Could be worked-around by rename namespace or reordering import's.
Comment 4 Todd Fast 2006-08-01 00:15:11 UTC
Nam, can you please expand on the waiver justification so that the release note
engineer can document the workaround.
Comment 5 Todd Fast 2006-08-01 00:18:11 UTC
Nam, if the sample is adjusted, is the workaround still needed? Ideally, we can
just update the sample so that it doesn't encounter this bug.
Comment 6 Manish Malhotra 2006-08-01 00:21:16 UTC
Praveen - need you to check/adjust Asynch sample with required workaround... it
is *OK* if this comes after B17 cutoff of 10pm tonight.
Comment 7 Nam Nguyen 2006-08-01 00:26:45 UTC
We already update the Asynchronous sample and it runs fine now wihtout any
intervention from user.  However, we still have to document the work-around in
case user hit this limitation in non-sample app.
Comment 8 Nam Nguyen 2006-08-01 00:31:40 UTC
The work-around is simply to assign a namespace the imported WSDL file, distinct
from the namespace of the importing WSDL.
Comment 9 Chris Webster 2006-08-16 16:34:36 UTC
Can you verify whether this is fixed or not?
Comment 10 Nam Nguyen 2006-08-16 17:13:45 UTC
This is fixed.  Duplicate of issue 81842.

*** This issue has been marked as a duplicate of 81842 ***
Comment 11 jlautz 2007-01-17 16:16:58 UTC
Issue 81842 has already been verified. Scenario cannot be duplicated because of
issue 80978.