Schemas with same namespaces problem.

[fyrachek <fy...@gmail.com>]

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.-tp32503745p32503745.html
Sent from the Apache Ode Dev mailing list archive at Nabble.com.

Re: Schemas with same namespaces problem.

[Waruna Ranasinghe <wa...@gmail.com>]

On 22 September 2011 00:05, tgb <TB...@serena.com> wrote:

>
> 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.
>
Yes, please try to attach a simple sample to the jira, so that we can
reproduce the issue.

Thanks,
Waruna



>
> 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.
>
>


-- 
-----------------------------------------------------
Regards,
Waruna Ranasinghe

mob: 0724318285
blog: http://warunapw.blogspot.com
twitter: http://twitter.com/warunapww
http://lk.linkedin.com/in/waruna
www.facebook.com/waruna.ranasinghe

Re: Schemas with same namespaces problem.

[tgb <TB...@SERENA.com>]

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.