To restate the problem slightly.... We have simple BPEL 1.1 request-response process for which the main wsdl is based on a derived schema. That is, the schema it uses to define its request and response, extends an existing schema which it references using an <xs:include>. This fails to compile with an unfound type definition. The unfound type is defined is in the derived schema which is odd since it is right there in the schema part of the .wsdl. The reason the type is not found is that for some reason ODE or maybe Xerces builds separate schema type libraries for both the full schema including all the types and the base schema including only the base types. When the type is looked up, ODE/Xerces finds the base schema types first and thus does not find the type it is looking for and fails. The problem can be worked around by replacing the <xs:include> with the content of the base schema. We also created a work around fix in Xerces by looking for the namepace type list that is the longest before looking up the type.
One other problem here is that the order of the schemas that are stored or looked up can change under some circumstances and which makes the problem intermittent. Yuriy had the problem from the start but for me it worked for serveral months then suddenly stopped working. Now it works again - why I don't have the exact error here. I have no explanation for this except that it is a hash lookup but one would expect that to be consistent. We tried to determine the root cause but the ODE schema building code proved extremely hard to follow so we gave up given that we have a reasonable workaround. I suspect the problem is that ODE is too aggressive in finding namespace schema documents and does not anticipate the case where a namespace might be fully defined using <xs:include> and incorrectly handles include as an an <xs:import>. It then gives the list of schema documents and namespaces to Xerces which dutifully does what it is told. Speculation.... I will enter a JIRA and provide our Xerces work around and if time permits an example that breaks if intermittently. Our current failing case is a bit too complex as an illustration. regards, Tim fyrachek wrote: > > When we include one schema to another we have two schemas with the same > namespace names. > ODE handles this situation very odd : > > While schemas capturing we have diferent(random) schemas order(depends on > the hash) at the > > _schemas map wich is : > > private final Map<URI, byte[]> _schemas = new HashMap<URI,byte[]>(); > > > Map<URI, byte[]> capture = XSUtils.captureSchema(defuri, schema, > resolver); > _schemas.putAll(capture); > > While *.bpel file compilation we create XSModelImpl(using it for variables > type checking).It's xercex class. > > And at the constructor, we have this code : > > fGrammarMap.put(null2EmptyString(fNamespaces[i]), fGrammarList[i]); > > So.. if we have more than one namespace with same name at the > fNamespaces, then we loose all previous fGrammarList[i] for this namespace > except last.Because the behavior of the put method is to update value for > already existing key. > > > Is it the bug of the ODE ? > > Because if we lost parent schema grammar it does not matter(child schema > grammar has all parent types), > but if we lost child schema grammar(I debuged such kind of situation)..we > will have compilation error. > > > Thx ! > -- View this message in context: http://old.nabble.com/Schemas-with-same-namespaces-problem.-tp32503745p32503768.html Sent from the Apache Ode Dev mailing list archive at Nabble.com.
