You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Yang ZHONG (JIRA)" <tu...@ws.apache.org> on 2006/12/13 03:20:24 UTC
[jira] Created: (TUSCANY-990) Avoid duplicated/infinite loading
Avoid duplicated/infinite loading
---------------------------------
Key: TUSCANY-990
URL: http://issues.apache.org/jira/browse/TUSCANY-990
Project: Tuscany
Issue Type: Improvement
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Yang ZHONG
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.
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.
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
Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Geoffrey Winn <ge...@googlemail.com>.
Excellent. Thank you. I've applied that patch.
On 04/01/07, Yang ZHONG <le...@gmail.com> wrote:
>
> xmlCanonicPath and comment have been attached as
>
> http://issues.apache.org/jira/secure/attachment/12348285/WindowsPath.support
>
>
> On 1/4/07, Caroline Maynard <ca...@gmail.com> wrote:
> >
> > On 04/01/07, Geoffrey Winn <ge...@googlemail.com> wrote:
> > >
> > > I have a couple of comments.
> > >
> > > 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain
> > what
> > > the code is doing and why.
> > >
> > > 2. Regarding xmlCanonicPath, performance is not an issue. This section
> > of
> > > code won't be called often enough to matter, whereas reliability and
> > > clarity
> > > (for people reading it in future) are essential. So whether we use
> > > xmlCanonicPath or not should be based on which one is easier to
> > understand
> > > in future.
> > >
> > > Caroline, I've looked on the libxml2 website and the description of
> > > xmlCanonicPath that I found is pretty thin. Do you have a pointer to a
> > > decent explanation of what it does?
> > >
> >
> > Well, this is open source :-)
> >
> > Here's the prolog:
> >
> > */**
> > * xmlCanonicPath:
> > * @path: the resource locator in a filesystem notation
> > *
> > * Constructs a canonic path from the specified path.
> > *
> > * Returns a new canonic path, or a duplicate of the path parameter if
> > the
> > * construction fails. The caller is responsible for freeing the memory
> > occupied
> > * by the returned string. If there is insufficient memory available, or
> > the
> > * argument is NULL, the function returns NULL.
> > */*
> >
> > and you can view the source at:
> > http://cvs.gnome.org/viewcvs/libxml2/uri.c?view=markup
> > (search for xmlCanonicPath)
> >
> > You'll see the the logic is very similar to Yang's, but IMHO it serves
> the
> > project better to reuse a function from a supported open-source library
> > that
> > the project already depends on than to reinvent it. Personally I
> wouldn't
> > see the extra memory allocation as an issue.
> >
> > --
> > Caroline
> >
> >
>
> --
>
> Yang ZHONG
>
>
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Yang ZHONG <le...@gmail.com>.
xmlCanonicPath and comment have been attached as
http://issues.apache.org/jira/secure/attachment/12348285/WindowsPath.support
On 1/4/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> On 04/01/07, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > I have a couple of comments.
> >
> > 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain
> what
> > the code is doing and why.
> >
> > 2. Regarding xmlCanonicPath, performance is not an issue. This section
> of
> > code won't be called often enough to matter, whereas reliability and
> > clarity
> > (for people reading it in future) are essential. So whether we use
> > xmlCanonicPath or not should be based on which one is easier to
> understand
> > in future.
> >
> > Caroline, I've looked on the libxml2 website and the description of
> > xmlCanonicPath that I found is pretty thin. Do you have a pointer to a
> > decent explanation of what it does?
> >
>
> Well, this is open source :-)
>
> Here's the prolog:
>
> */**
> * xmlCanonicPath:
> * @path: the resource locator in a filesystem notation
> *
> * Constructs a canonic path from the specified path.
> *
> * Returns a new canonic path, or a duplicate of the path parameter if
> the
> * construction fails. The caller is responsible for freeing the memory
> occupied
> * by the returned string. If there is insufficient memory available, or
> the
> * argument is NULL, the function returns NULL.
> */*
>
> and you can view the source at:
> http://cvs.gnome.org/viewcvs/libxml2/uri.c?view=markup
> (search for xmlCanonicPath)
>
> You'll see the the logic is very similar to Yang's, but IMHO it serves the
> project better to reuse a function from a supported open-source library
> that
> the project already depends on than to reinvent it. Personally I wouldn't
> see the extra memory allocation as an issue.
>
> --
> Caroline
>
>
--
Yang ZHONG
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Caroline Maynard <ca...@gmail.com>.
On 04/01/07, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> I have a couple of comments.
>
> 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain what
> the code is doing and why.
>
> 2. Regarding xmlCanonicPath, performance is not an issue. This section of
> code won't be called often enough to matter, whereas reliability and
> clarity
> (for people reading it in future) are essential. So whether we use
> xmlCanonicPath or not should be based on which one is easier to understand
> in future.
>
> Caroline, I've looked on the libxml2 website and the description of
> xmlCanonicPath that I found is pretty thin. Do you have a pointer to a
> decent explanation of what it does?
>
Well, this is open source :-)
Here's the prolog:
*/**
* xmlCanonicPath:
* @path: the resource locator in a filesystem notation
*
* Constructs a canonic path from the specified path.
*
* Returns a new canonic path, or a duplicate of the path parameter if the
* construction fails. The caller is responsible for freeing the memory occupied
* by the returned string. If there is insufficient memory available, or the
* argument is NULL, the function returns NULL.
*/*
and you can view the source at:
http://cvs.gnome.org/viewcvs/libxml2/uri.c?view=markup
(search for xmlCanonicPath)
You'll see the the logic is very similar to Yang's, but IMHO it serves the
project better to reuse a function from a supported open-source library that
the project already depends on than to reinvent it. Personally I wouldn't
see the extra memory allocation as an issue.
--
Caroline
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Geoffrey Winn <ge...@googlemail.com>.
I have a couple of comments.
1. In the patch XSDHelperImpl.990 you _must_ add comments to explain what
the code is doing and why.
2. Regarding xmlCanonicPath, performance is not an issue. This section of
code won't be called often enough to matter, whereas reliability and clarity
(for people reading it in future) are essential. So whether we use
xmlCanonicPath or not should be based on which one is easier to understand
in future.
Caroline, I've looked on the libxml2 website and the description of
xmlCanonicPath that I found is pretty thin. Do you have a pointer to a
decent explanation of what it does?
Regards,
Geoff.
On 04/01/07, Yang ZHONG <le...@gmail.com> wrote:
>
>
> http://issues.apache.org/jira/secure/attachment/12348234/WindowsPath.support
> throws SDOFileNotFoundException for non-existent path.
>
> As for xmlCanonicPath, it always allocates new memory and expects xmlFree
> where try/finally simulation may also complicate code.
> Trading off for performance, mine only allocates new memory when necessary
> and implicitly frees on destruction.
> I can't make up my mind. Anyone preferring xmlCanonicPath can go ahead
> modify the patch even source (after applying) directly.
>
> On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
> >
> > The good news is that the fix does work for me. Though I would suggest
> > thinking about using xmlCanonicPath() to keep the Tuscany code simpler
> and
> > the URI function in libxml where it belongs. xmlCanonicPath() will
> > silently
> > handle platform-specific paths, too.
> >
> > The bad news is that the tests still fail. This time the problem is a
> test
> > which deliberately calls defineFile() with a non-existent file spec. I
> get
> > the same traceback for the access violation:
> >
> > MSVCRTD! 00239060()
> > commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436
> +
> > 17
> > bytes
> > commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
> > 1318
> > + 17 bytes
> > commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88,
> > unsigned char 0x00, const void * 0x00000000) line 556 + 17 bytes
> > commonj::sdo::XSDHelperImpl::defineFile(const char * 0x02d92f88,
> unsigned
> > char 0x00) line 111 + 21 bytes
> >
> > The cause is the same as the first example - xmlBuildURI() is returning
> > null
> > when passed an invalid location, and there is no guard for this
> condition.
> > Before your fix was applied, Tuscany would throw an
> > SDOFileNotFoundException.
> >
> > On 03/01/07, Yang ZHONG <le...@gmail.com> wrote:
> > >
> > > I've tried
> > >
> >
> http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990
> > > and I think it supports Windows path on Windows (only).
> > >
> > > Let me know if your case still fails.
> > >
> >
> >
> >
> > --
> > Caroline
> >
> >
>
>
> --
>
> Yang ZHONG
>
>
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Yang ZHONG <le...@gmail.com>.
http://issues.apache.org/jira/secure/attachment/12348234/WindowsPath.support
throws SDOFileNotFoundException for non-existent path.
As for xmlCanonicPath, it always allocates new memory and expects xmlFree
where try/finally simulation may also complicate code.
Trading off for performance, mine only allocates new memory when necessary
and implicitly frees on destruction.
I can't make up my mind. Anyone preferring xmlCanonicPath can go ahead
modify the patch even source (after applying) directly.
On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> The good news is that the fix does work for me. Though I would suggest
> thinking about using xmlCanonicPath() to keep the Tuscany code simpler and
> the URI function in libxml where it belongs. xmlCanonicPath() will
> silently
> handle platform-specific paths, too.
>
> The bad news is that the tests still fail. This time the problem is a test
> which deliberately calls defineFile() with a non-existent file spec. I get
> the same traceback for the access violation:
>
> MSVCRTD! 00239060()
> commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 +
> 17
> bytes
> commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
> 1318
> + 17 bytes
> commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88,
> unsigned char 0x00, const void * 0x00000000) line 556 + 17 bytes
> commonj::sdo::XSDHelperImpl::defineFile(const char * 0x02d92f88, unsigned
> char 0x00) line 111 + 21 bytes
>
> The cause is the same as the first example - xmlBuildURI() is returning
> null
> when passed an invalid location, and there is no guard for this condition.
> Before your fix was applied, Tuscany would throw an
> SDOFileNotFoundException.
>
> On 03/01/07, Yang ZHONG <le...@gmail.com> wrote:
> >
> > I've tried
> >
> http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990
> > and I think it supports Windows path on Windows (only).
> >
> > Let me know if your case still fails.
> >
>
>
>
> --
> Caroline
>
>
--
Yang ZHONG
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Caroline Maynard <ca...@gmail.com>.
The good news is that the fix does work for me. Though I would suggest
thinking about using xmlCanonicPath() to keep the Tuscany code simpler and
the URI function in libxml where it belongs. xmlCanonicPath() will silently
handle platform-specific paths, too.
The bad news is that the tests still fail. This time the problem is a test
which deliberately calls defineFile() with a non-existent file spec. I get
the same traceback for the access violation:
MSVCRTD! 00239060()
commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 + 17
bytes
commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line 1318
+ 17 bytes
commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88,
unsigned char 0x00, const void * 0x00000000) line 556 + 17 bytes
commonj::sdo::XSDHelperImpl::defineFile(const char * 0x02d92f88, unsigned
char 0x00) line 111 + 21 bytes
The cause is the same as the first example - xmlBuildURI() is returning null
when passed an invalid location, and there is no guard for this condition.
Before your fix was applied, Tuscany would throw an
SDOFileNotFoundException.
On 03/01/07, Yang ZHONG <le...@gmail.com> wrote:
>
> I've tried
> http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990
> and I think it supports Windows path on Windows (only).
>
> Let me know if your case still fails.
>
--
Caroline
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Yang ZHONG <le...@gmail.com>.
I've tried
http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990
and I think it supports Windows path on Windows (only).
Let me know if your case still fails.
On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> I posted the traceback to show that it's XSDHelperImpl::defineFile(). The
> file spec is being passed in from the user, and I do think that Windows
> users normally expect to specify file specs in this way, and I see no
> reason
> to regress this behaviour in your fix. Especially not with an
> AccessViolation :-)
>
>
> On 03/01/07, Yang ZHONG <le...@gmail.com> wrote:
> >
> > Are you using "C:\path\to\the.xsd" as schemaLocation for include/import?
> > According to XSD spec, it should have been "a URI as defined by [RFC
> > 2396],
> > as amended by [RFC 2732]".
> > Both RFC 2396 and RFC 2732 have specified "\" unwise.
> >
> > Or are you using "C:\path\to\the.xsd" for XSDHelper#defineFile?
> > Neither SDO spec 2.1 C++ nor the Java counterpart seems specifying the
> > input.
> > I think it's reasonable to support that for XSDHelper#defineFile on
> > Windows
> > only.
> > What's everyone's opinion?
> >
> > On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
> > >
> > > This isn't looking good for me. Tests which previously worked are now
> > > failing with :
> > >
> > > MSVCRTD! 00239060()
> > > commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line
> 436
> > +
> > > 17
> > > bytes
> > > commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
> > > 1316
> > > + 17 bytes
> > > commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0,
> > > unsigned char 0x00, const void * 0x00000000) line 554 + 17 bytes
> > > commonj::sdo::XSDHelperImpl::defineFile(const char * 0x01a8cad0,
> > unsigned
> > > char 0x00) line 83 + 21 bytes
> > >
> > > This is probably because the schema is specified as a Windows-style
> > > filespec: C:\path\to\the.xsd. It would probably work with your changes
> > if
> > > the location was a valid URI, so that xmlBuildURI() returns a valid
> URI,
> > > but
> > > I think the code should work in either case.
> > >
> > > On 03/01/07, Geoff Winn (JIRA) <tu...@ws.apache.org> wrote:
> > > >
> > > >
> > > > [
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > > ]
> > > >
> > > > Geoff Winn resolved TUSCANY-990.
> > > > --------------------------------
> > > >
> > > > Resolution: Fixed
> > > > Fix Version/s: Cpp-current
> > > >
> > > > Patch applied.
> > > >
> > > > The standard tests now produce just 5 I/O warnings about failing to
> > load
> > > > an external entity.
> > > >
> > > > > Avoid duplicated/infinite loading
> > > > > ---------------------------------
> > > > >
> > > > > Key: TUSCANY-990
> > > > > URL:
> > https://issues.apache.org/jira/browse/TUSCANY-990
> > > > > Project: Tuscany
> > > > > Issue Type: Improvement
> > > > > Components: C++ SDO
> > > > > Affects Versions: Cpp-current
> > > > > Reporter: Yang ZHONG
> > > > > Fix For: Cpp-current
> > > > >
> > > > > Attachments: AvoidInfiniteLoading.990,
> > > AvoidInfiniteLoading.990
> > > > >
> > > > >
> > > > > 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.
> > > > > 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.
> > > > > 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
> > > > > Above has been discussed on thread
> > > >
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> > > > > and Caroline has also requested this improvement (
> > > >
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > If you think it was sent incorrectly contact one of the
> > administrators:
> > > > https://issues.apache.org/jira/secure/Administrators.jspa
> > > > -
> > > > For more information on JIRA, see:
> > > http://www.atlassian.com/software/jira
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Caroline
> > >
> > >
> >
> >
> > --
> >
> > Yang ZHONG
> >
> >
>
>
> --
> Caroline
>
>
--
Yang ZHONG
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Caroline Maynard <ca...@gmail.com>.
I posted the traceback to show that it's XSDHelperImpl::defineFile(). The
file spec is being passed in from the user, and I do think that Windows
users normally expect to specify file specs in this way, and I see no reason
to regress this behaviour in your fix. Especially not with an
AccessViolation :-)
On 03/01/07, Yang ZHONG <le...@gmail.com> wrote:
>
> Are you using "C:\path\to\the.xsd" as schemaLocation for include/import?
> According to XSD spec, it should have been "a URI as defined by [RFC
> 2396],
> as amended by [RFC 2732]".
> Both RFC 2396 and RFC 2732 have specified "\" unwise.
>
> Or are you using "C:\path\to\the.xsd" for XSDHelper#defineFile?
> Neither SDO spec 2.1 C++ nor the Java counterpart seems specifying the
> input.
> I think it's reasonable to support that for XSDHelper#defineFile on
> Windows
> only.
> What's everyone's opinion?
>
> On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
> >
> > This isn't looking good for me. Tests which previously worked are now
> > failing with :
> >
> > MSVCRTD! 00239060()
> > commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436
> +
> > 17
> > bytes
> > commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
> > 1316
> > + 17 bytes
> > commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0,
> > unsigned char 0x00, const void * 0x00000000) line 554 + 17 bytes
> > commonj::sdo::XSDHelperImpl::defineFile(const char * 0x01a8cad0,
> unsigned
> > char 0x00) line 83 + 21 bytes
> >
> > This is probably because the schema is specified as a Windows-style
> > filespec: C:\path\to\the.xsd. It would probably work with your changes
> if
> > the location was a valid URI, so that xmlBuildURI() returns a valid URI,
> > but
> > I think the code should work in either case.
> >
> > On 03/01/07, Geoff Winn (JIRA) <tu...@ws.apache.org> wrote:
> > >
> > >
> > > [
> > >
> >
> https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > ]
> > >
> > > Geoff Winn resolved TUSCANY-990.
> > > --------------------------------
> > >
> > > Resolution: Fixed
> > > Fix Version/s: Cpp-current
> > >
> > > Patch applied.
> > >
> > > The standard tests now produce just 5 I/O warnings about failing to
> load
> > > an external entity.
> > >
> > > > Avoid duplicated/infinite loading
> > > > ---------------------------------
> > > >
> > > > Key: TUSCANY-990
> > > > URL:
> https://issues.apache.org/jira/browse/TUSCANY-990
> > > > Project: Tuscany
> > > > Issue Type: Improvement
> > > > Components: C++ SDO
> > > > Affects Versions: Cpp-current
> > > > Reporter: Yang ZHONG
> > > > Fix For: Cpp-current
> > > >
> > > > Attachments: AvoidInfiniteLoading.990,
> > AvoidInfiniteLoading.990
> > > >
> > > >
> > > > 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.
> > > > 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.
> > > > 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
> > > > Above has been discussed on thread
> > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> > > > and Caroline has also requested this improvement (
> > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the
> administrators:
> > > https://issues.apache.org/jira/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see:
> > http://www.atlassian.com/software/jira
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Caroline
> >
> >
>
>
> --
>
> Yang ZHONG
>
>
--
Caroline
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Yang ZHONG <le...@gmail.com>.
Are you using "C:\path\to\the.xsd" as schemaLocation for include/import?
According to XSD spec, it should have been "a URI as defined by [RFC 2396],
as amended by [RFC 2732]".
Both RFC 2396 and RFC 2732 have specified "\" unwise.
Or are you using "C:\path\to\the.xsd" for XSDHelper#defineFile?
Neither SDO spec 2.1 C++ nor the Java counterpart seems specifying the
input.
I think it's reasonable to support that for XSDHelper#defineFile on Windows
only.
What's everyone's opinion?
On 1/3/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> This isn't looking good for me. Tests which previously worked are now
> failing with :
>
> MSVCRTD! 00239060()
> commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 +
> 17
> bytes
> commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
> 1316
> + 17 bytes
> commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0,
> unsigned char 0x00, const void * 0x00000000) line 554 + 17 bytes
> commonj::sdo::XSDHelperImpl::defineFile(const char * 0x01a8cad0, unsigned
> char 0x00) line 83 + 21 bytes
>
> This is probably because the schema is specified as a Windows-style
> filespec: C:\path\to\the.xsd. It would probably work with your changes if
> the location was a valid URI, so that xmlBuildURI() returns a valid URI,
> but
> I think the code should work in either case.
>
> On 03/01/07, Geoff Winn (JIRA) <tu...@ws.apache.org> wrote:
> >
> >
> > [
> >
> https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >
> > Geoff Winn resolved TUSCANY-990.
> > --------------------------------
> >
> > Resolution: Fixed
> > Fix Version/s: Cpp-current
> >
> > Patch applied.
> >
> > The standard tests now produce just 5 I/O warnings about failing to load
> > an external entity.
> >
> > > Avoid duplicated/infinite loading
> > > ---------------------------------
> > >
> > > Key: TUSCANY-990
> > > URL: https://issues.apache.org/jira/browse/TUSCANY-990
> > > Project: Tuscany
> > > Issue Type: Improvement
> > > Components: C++ SDO
> > > Affects Versions: Cpp-current
> > > Reporter: Yang ZHONG
> > > Fix For: Cpp-current
> > >
> > > Attachments: AvoidInfiniteLoading.990,
> AvoidInfiniteLoading.990
> > >
> > >
> > > 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.
> > > 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.
> > > 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
> > > Above has been discussed on thread
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> > > and Caroline has also requested this improvement (
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> > https://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Caroline
>
>
--
Yang ZHONG
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by Caroline Maynard <ca...@gmail.com>.
This isn't looking good for me. Tests which previously worked are now
failing with :
MSVCRTD! 00239060()
commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 + 17
bytes
commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line 1316
+ 17 bytes
commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0,
unsigned char 0x00, const void * 0x00000000) line 554 + 17 bytes
commonj::sdo::XSDHelperImpl::defineFile(const char * 0x01a8cad0, unsigned
char 0x00) line 83 + 21 bytes
This is probably because the schema is specified as a Windows-style
filespec: C:\path\to\the.xsd. It would probably work with your changes if
the location was a valid URI, so that xmlBuildURI() returns a valid URI, but
I think the code should work in either case.
On 03/01/07, Geoff Winn (JIRA) <tu...@ws.apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Geoff Winn resolved TUSCANY-990.
> --------------------------------
>
> Resolution: Fixed
> Fix Version/s: Cpp-current
>
> Patch applied.
>
> The standard tests now produce just 5 I/O warnings about failing to load
> an external entity.
>
> > Avoid duplicated/infinite loading
> > ---------------------------------
> >
> > Key: TUSCANY-990
> > URL: https://issues.apache.org/jira/browse/TUSCANY-990
> > Project: Tuscany
> > Issue Type: Improvement
> > Components: C++ SDO
> > Affects Versions: Cpp-current
> > Reporter: Yang ZHONG
> > Fix For: Cpp-current
> >
> > Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990
> >
> >
> > 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.
> > 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.
> > 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
> > Above has been discussed on thread
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> > and Caroline has also requested this improvement (
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Caroline
[jira] Updated: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-990?page=all ]
Yang ZHONG updated TUSCANY-990:
-------------------------------
Attachment: AvoidInfiniteLoading.990
The attached prototype has adopted
3-3. Currently ParserErrorSetter is explicitly passed into each parser, which can host the LoadingContext/ResourceSet
to minimize source changes.
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: http://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Attachments: AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462101 ]
Yang ZHONG commented on TUSCANY-990:
------------------------------------
WindowsPath.support has been attached to address Caroline's request of supporting Windows path (C:\path\to\the.xsd) by XSDHelperImpl::defineFile on Windows (only) and throwing SDOFileNotFoundException for non-existent path.
The patch only affects Windows runtime.
Tests on Windows XP SP2 before the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
Tests on Windows XP SP2 after the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, WindowsPath.support, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yang ZHONG updated TUSCANY-990:
-------------------------------
Attachment: XSDHelperImpl.990
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-990?page=comments#action_12458263 ]
Geoff Winn commented on TUSCANY-990:
------------------------------------
Looking at the changes in ParserErrorSetter.h ...
The stdext::hash_map is used to keep a record of the schema files that have already been processed so that we don't read them again. You could use something simpler for that - I'd suggest a std::vector. For large numbers of files that will be less efficient than the hash_map, but lets face it, we aren't going to have large numbers of files and anyway the amount we save by not loading the schema files multiple times will more than cover the cost of a few string compares.
That way you can a) get away from the hash_map construct that requires special handling on different platforms and b) simplify the code change by getting rid of the HashCompare stuff.
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: http://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Attachments: AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462458 ]
Geoff Winn commented on TUSCANY-990:
------------------------------------
I've applied that patch. Since xmlCanonicPath works on Windows and Linux I removed the #ifdef so that xmlCanonicPath is always used.
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, WindowsPath.support, WindowsPath.support, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yang ZHONG updated TUSCANY-990:
-------------------------------
Attachment: WindowsPath.support
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, WindowsPath.support, WindowsPath.support, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yang ZHONG updated TUSCANY-990:
-------------------------------
Attachment: WindowsPath.support
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, WindowsPath.support, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462271 ]
Yang ZHONG commented on TUSCANY-990:
------------------------------------
A different WindowsPath.support implemented with xmlCanonicPath has been attached.
The patch only affects Windows runtime.
Tests on Windows XP SP2 before the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
Tests on Windows XP SP2 after the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, WindowsPath.support, WindowsPath.support, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462047 ]
Yang ZHONG commented on TUSCANY-990:
------------------------------------
XSDHelperImpl.990 has been attached to address Caroline's request of supporting Windows path (C:\path\to\the.xsd) by XSDHelperImpl::defineFile on Windows (only).
The patch only affects Windows runtime.
Tests on Windows XP SP2 before the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
Tests on Windows XP SP2 after the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990, XSDHelperImpl.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-990?page=comments#action_12458224 ]
Geoff Winn commented on TUSCANY-990:
------------------------------------
This patch doesn't build on Linux using gcc 3.2.3.
The problem is in ParserErrorSetter.h. The namespace stdext isn't recognised by gcc, however, after I correct that I still get further errors about incorrect type definitions. I'll look into this a little more but I won't be able to apply the patch today.
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: http://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Attachments: AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-990?page=all ]
Yang ZHONG updated TUSCANY-990:
-------------------------------
Attachment: AvoidInfiniteLoading.990
The attachment has passed all build tests on Fedora 6.
Tests on Windows XP SP2 before the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
Tests on Windows XP SP2 after the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: http://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-990?page=comments#action_12458008 ]
Yang ZHONG commented on TUSCANY-990:
------------------------------------
Tests on Windows XP SP2 before the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
Tests on Windows XP SP2 after the patch:
Test Failed: 115 sdotest::cloneopentest()
Total tests:117 Tests passed:116
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: http://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Attachments: AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Winn resolved TUSCANY-990.
--------------------------------
Resolution: Fixed
Fix Version/s: Cpp-current
Patch applied.
The standard tests now produce just 5 I/O warnings about failing to load an external entity.
> Avoid duplicated/infinite loading
> ---------------------------------
>
> Key: TUSCANY-990
> URL: https://issues.apache.org/jira/browse/TUSCANY-990
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Yang ZHONG
> Fix For: Cpp-current
>
> Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990
>
>
> 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.
> 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.
> 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
> Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> and Caroline has also requested this improvement (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org