A patch has been attached into http://issues.apache.org/jira/browse/TUSCANY-990
BTW, Caroline has also requested this improvement ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html) On 12/10/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 09/12/06, Yang ZHONG <[EMAIL PROTECTED]> wrote: > > Thank you Pete for the alternative to host LoadingContext/ResourceSet > within > DataFactory. > How to browse from SDOSchemaSAX2Parser to DataFactory please? > My prototype checks LoadingContext/ResourceSet > within SDOSchemaSAX2Parser::startInclude > > My LoadingContext/ResourceSet is internal to parsers, not a user context. I wasn't thinking clearly ;-) It's SDOSchemaSAX2Parser that needs to remember what it has loaded. Your suggsetion sounds good. Could you post a patch so we can see your idea? On 12/9/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > Yang, > > Yes we've noticed this when loading the Atom schema. > > > > > > On 09/12/06, Yang ZHONG <[EMAIL PROTECTED]> wrote: > > > > > > While working on http://issues.apache.org/jira/browse/TUSCANY-907 > > > I've observed duplicated XSD loading. It could be infinite loading. I > > > might > > > have a way to avoid that. > > > > > > Could you verify current implementation may load redundantly even > > > infinitely? > > > Could you brainstorm how to avoid that? > > > > > > http://pecl.php.net/bugs/bug.php?id=9243 > > > has the Test Case: > > > 1. http://ping.chip.org/phr/xml/insurance.xsd imports > > > http://ping.chip.org/phr/xml/types.xsd > > > 2. http://ping.chip.org/phr/xml/insurance.xsd imports > > > http://ping.chip.org/phr/xml/contact.xsd which also imports > > > http://ping.chip.org/phr/xml/types.xsd > > > > > > I've observed http://ping.chip.org/phr/xml/types.xsd is loaded/parsed > > > multiple times during loading > http://ping.chip.org/phr/xml/insurance.xsd > > > > > > That impacts performance, especially types.xsd is remote. > > > > > > More deadly, that may cause infinite loading or stack overflow. > > > Imagine A imports B which imports A, or X imports Y which imports Z > > which > > > imports X. > > > > > > If above is true, let's brainstorm how to avoid that. > > > > > > We can have a LoadingContext/ResourceSet to cache loaded/parsed > > resources, > > > and reuse parsing results if a location/URI has been loaded/parsed > > > already. > > > > > > 3-1. The LoadingContext/ResourceSet can be a Thread Local > > > 3-2. The LoadingContext/ResourceSet can be explicitly passed into each > > > parser > > > 3-3. Currently ParserErrorSetter is explicitly passed into each > parser, > > > which can host the LoadingContext/ResourceSet > > > > > > Do you have alternatives? Which would you prefer? > > > > > > The most basic problem is when a user uses XSDHelper to load X.xsdwhich > > imports other schema... which in turn include some of the same schema. > At > > the moment his causes redundant parsing. A simple solution is to > remember > > the schema namespace/location so the import/include of a schema we > already > > have parsed can be ignored. This information could be held in the > > DataFactory so that if the user calls XSDHelper::define() for the same > > schema we could ignore it (as we know the types are already defined). > > > > I'm not sure if you are suggesting a wider ranging improvement of some > > context the user can pass into XSDHelper? > > > > Cheers, > > -- > > Pete > > > > > > > -- > > Yang ZHONG > > -- Pete
-- Yang ZHONG
