We have a wsdl with an included schema. When I try to map elements with types from the included schema we see the following:
1. In one case the node has name <?UNKNOEN NODE TYPE?>
2. In the second case the node cannot be expanded
See example project.
Created attachment 59418 [details]
The problem was initially reported against 6.0 but is still reproducable with 6.1beta.
It seems that if an element from an included schema is referenced it can't be accessed in the bpel mapper.
<xsd:include schemaLocation="xyz.xsd"/> <- defines Element AElement
In the BPEL Mapper you can't drill down to the AElement Type.
This makes included schemas not really usable in the BPEL tooling -> Thus raising to P1.
This problem goes to Schema model, so I created an issue against it: iz132301.
As a workaround, one can copy targetNamespace declaration from schema, inlined in wsdl
(targetNamespace="http://afb.de/Schufa") to included xsd file(schufa.xsd)
The bug will be fixed via patch1 and since the workaround exists, the P2 priority is appropriate. Please, work on the
fix in the trunk. Thanks
Fixed in trunk
Issue '131639' Integrated in NB_Trunk_Production #153 : http://hg.netbeans.org/main/rev/b6415dca5f39,
with comment: Fix the issue #131639 - Problem with Included Schemas in Mapper
marked as fixed.
The issue hasn't be verified till 61patch1 nomination cut-off date.
Marked as release61_fixes_candidate2.
There are no nodes with <?UNKNOEN NODE TYPE?> name
There are all nodes can be expanded
verified by Vika. returned back to patch1 candidates list.
The fix has been ported into the release61_fixes branch.
After applying the fix, the module bpel.mapper does not compile anymore. See attached log.
It seems that the fix is incomplete. Please evaluate and provide complete fix in 5 days (till May 5th) otherwise this
fix cannot be part of patch 1.
Created attachment 60814 [details]
The change http://hg.netbeans.org/release61_fixes/rev/32a6602d3f8e was rolled back in release61_fixes branch because it
broke the build.
Anyway, the changes in the fix are huge (19 files affected), so it is controversial if such huge changes should be part
of patch 1 (is it really bug fix or bug fix + some refactoring?)...
The fix changed 19 files because the changes are quite complex. But it fixes the real problem.
And I'm sure that it is safe enough to be included to the patch.
I think it is inevitable that merging big amount of changes can come to build problems.
Most likely it can be a result of skipping some changesets while merging.
But regarding my code, I can try merging it manually and make it compilable.
I have seen the console log., It looks strange for me, but I think it isn't very difficult to fix.
I have sent the hg bundle with changeset by email.
So I hope the fix will be in the patch1.
The fix has been ported into the release61_fixes branch. (Thanks for the bundle, supernikita!)