Re: [SDO C++] Escaping special characters in XML
Pete Robbins wrote: I've applied this patch to the branch. I'll apply it to head later. I had to change a couple of lines to construct SDOString from a start and end iterator as this caused compile errors on VC8. Cheers, On 30/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote: I've uploaded a proposed patch for http://issues.apache.org/jira/browse/TUSCANY-1553. Please take a look. It runs all the PHP regression tests without problems, and also makes the uploaded test run clean. Thank you! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Problem with special characters in property names
Pete Robbins wrote:
I've checked a fix for this into the branch. I'll apply it to head later.
Cheers,
On 22/11/2007, Pete Robbins <[EMAIL PROTECTED]> wrote:
I'll need to look into this. I can't find any restrictions in the spec
for characters in property names so I'm assuming NCName. So I think
your patch looks good.
The usual place where hyphens in names become a problem is when
mapping to programming language label but that is something that code
gen should take care of.
This will be an issue in the HEAD as well as the branch.
Cheers,
On 16/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote:
A PHP user is facing a problem using a schema which uses the - (hyphen)
character in element names, as second or subsequent character. We thinks
this is valid XML, according to
http://www.w3.org/TR/REC-xml/#NT-NameChar, where the grammar is:
[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar
| Extender
[5] Name ::= (Letter | '_' | ':') (NameChar)*
What's actually happening is that he's getting an SDO_PropertyNotFound
exception when he tries to set the property. Within the PHP
implementation, this is resolving to
dop->set('element-name', value)
which ends up at:
void DataObjectImpl::setSDOValue(const SDOString& path,
const SDOValue& sval,
const SDOString& dataType)
Practically the first thing that method does is to call stripPath(),
which removes the hyphen from the element name - resulting in the
exception later on.
I tried this patch:
### Eclipse Workspace Patch 1.0
#P pecl-sdo-FULMAR
Index: commonj/sdo/DataObjectImpl.cpp
===
RCS file: /repository/pecl/sdo/commonj/sdo/DataObjectImpl.cpp,v
retrieving revision 1.20
diff -u -r1.20 DataObjectImpl.cpp
--- commonj/sdo/DataObjectImpl.cpp 24 Aug 2007 15:20:21 - 1.20
+++ commonj/sdo/DataObjectImpl.cpp 16 Nov 2007 19:10:23 -
@@ -951,7 +951,7 @@
//
const char* DataObjectImpl::templateString =
-"
/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#";
+"
/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#-";
char* DataObjectImpl::stripPath(const char* path)
{
which appears to fix the problem. But I expect you'll tell me there is
more to it than that. I know there are existing issues about valid
characters in XPaths. But it seems a shame to prevent this simple
scenario from working because of Xpath.
Thank you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Escaping special characters in XML
I've uploaded a proposed patch for http://issues.apache.org/jira/browse/TUSCANY-1553. Please take a look. It runs all the PHP regression tests without problems, and also makes the uploaded test run clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Attachment: Tuscany-1553.phpt OK, so you need php to run this test, but just viewing the test source shows the behaviour of this patch quite clearly, so it may be helpful > XML characters are not escaped by XMLHelper. > > > Key: TUSCANY-1553 > URL: https://issues.apache.org/jira/browse/TUSCANY-1553 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-M3 > Environment: All >Reporter: Albert Krzymowski > Fix For: Cpp-Next > > Attachments: tuscany-1553.patch, Tuscany-1553.phpt > > > XML charactres are not escaped. > In case of all string based data types SDOXMLWriter uses > xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. > Is it related to this comment in SDOXMLWriter::writeXMLElement ? >/* A more complex version that doesn't work! ... > Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Attachment: tuscany-1553.patch Herewith a proposed patch for this issue. I have not delved into the issues with the previous attempt, but started out anew. This patch runs all regression tests for the PHP project without problems. > XML characters are not escaped by XMLHelper. > > > Key: TUSCANY-1553 > URL: https://issues.apache.org/jira/browse/TUSCANY-1553 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-M3 > Environment: All >Reporter: Albert Krzymowski > Fix For: Cpp-Next > > Attachments: tuscany-1553.patch > > > XML charactres are not escaped. > In case of all string based data types SDOXMLWriter uses > xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. > Is it related to this comment in SDOXMLWriter::writeXMLElement ? >/* A more complex version that doesn't work! ... > Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Component/s: C++ SDO > XML characters are not escaped by XMLHelper. > > > Key: TUSCANY-1553 > URL: https://issues.apache.org/jira/browse/TUSCANY-1553 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-M3 > Environment: All >Reporter: Albert Krzymowski > Fix For: Cpp-Next > > > XML charactres are not escaped. > In case of all string based data types SDOXMLWriter uses > xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. > Is it related to this comment in SDOXMLWriter::writeXMLElement ? >/* A more complex version that doesn't work! ... > Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Problem with special characters in property names
A PHP user is facing a problem using a schema which uses the - (hyphen)
character in element names, as second or subsequent character. We thinks
this is valid XML, according to
http://www.w3.org/TR/REC-xml/#NT-NameChar, where the grammar is:
[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar
| Extender
[5] Name ::= (Letter | '_' | ':') (NameChar)*
What's actually happening is that he's getting an SDO_PropertyNotFound
exception when he tries to set the property. Within the PHP
implementation, this is resolving to
dop->set('element-name', value)
which ends up at:
void DataObjectImpl::setSDOValue(const SDOString& path,
const SDOValue& sval,
const SDOString& dataType)
Practically the first thing that method does is to call stripPath(),
which removes the hyphen from the element name - resulting in the
exception later on.
I tried this patch:
### Eclipse Workspace Patch 1.0
#P pecl-sdo-FULMAR
Index: commonj/sdo/DataObjectImpl.cpp
===
RCS file: /repository/pecl/sdo/commonj/sdo/DataObjectImpl.cpp,v
retrieving revision 1.20
diff -u -r1.20 DataObjectImpl.cpp
--- commonj/sdo/DataObjectImpl.cpp 24 Aug 2007 15:20:21 - 1.20
+++ commonj/sdo/DataObjectImpl.cpp 16 Nov 2007 19:10:23 -
@@ -951,7 +951,7 @@
//
const char* DataObjectImpl::templateString =
-"
/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#";
+"
/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#-";
char* DataObjectImpl::stripPath(const char* path)
{
which appears to fix the problem. But I expect you'll tell me there is
more to it than that. I know there are existing issues about valid
characters in XPaths. But it seems a shame to prevent this simple
scenario from working because of Xpath.
(NB we're still on the branch. I don't know if this also applies to the
trunk code.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] AccessViolation in XMLHelperImpl
Pete Robbins wrote: Thanks for that. I'll fix it right away. Thanks, Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] AccessViolation in XMLHelperImpl
A user has found a vulnerability in XMLHelperImpl::createDocument, the
one with the const char * parameters. The problem being that the root
element name is initialized with the parameter >before< the code which
checks for the parameter being null. I'll add a guard for this in the
PHP code, but really it should be fixed in Tuscany. Could someone apply
this patch, please:
Index:
C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
===
---
C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
(revision 568508)
+++
C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
(working copy)
@@ -172,7 +172,7 @@
const char* rootElementName)
{
SDOString uri;
- SDOString name = rootElementName;
+ SDOString name;
if (0 == rootElementURI)
uri = "";
else
The patch was created against the branch, but the same code exists in
the trunk.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]
Brady Johnson wrote: That's good to know the background to that include file, I didn't know about it. I'll definitely keep it in mind. I don't think the change I made should affect you, let me know if it does. Thanks. As discussed previously, we're sticking with the branch for now, and will move up to the trunk when it is more stable - it's clear there will be a >lot< of changes to make, though the majority should be fairly mindless refactoring. Just wanted to make sure that you knew how some of the Tuscany code ended up like it is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]
Original Message Subject: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible Date: Mon, 13 Aug 2007 10:57:44 +0100 From: Caroline Maynard <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Newsgroups: gmane.comp.apache.webservices.tuscany.devel References: <[EMAIL PROTECTED]> Brady Johnson (JIRA) wrote: Tuscany SDO native for windows is not msvc backwards compatible Don't I know it. In the PHP project the automated build servers for Win use VC6, so we are obliged to use that compiler in the SDO for PHP project. Since the Tuscany team decided to support only VC8, I usually find some minor problems porting the code over - you'll find a trail of these in the issues database where I've sent the fixes back as patches. It's not really a big problem, more an inconvenience. However it was a policy decision by the Tuscany committers at the time. YMMV. Again, with the localtime behaviour, this came from concerns about using non-reentrant versions of localtime(). You may not have noticed the SDOUserMacros.h file - this mechanism was introduced so that consumers of Tuscany C++ could adapt the macros to their environment. You can see the PHP version here: http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup It would be helpful if you would keep this mechanism in place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible
Brady Johnson (JIRA) wrote: Tuscany SDO native for windows is not msvc backwards compatible Don't I know it. In the PHP project the automated build servers for Win use VC6, so we are obliged to use that compiler in the SDO for PHP project. Since the Tuscany team decided to support only VC8, I usually find some minor problems porting the code over - you'll find a trail of these in the issues database where I've sent the fixes back as patches. It's not really a big problem, more an inconvenience. However it was a policy decision by the Tuscany committers at the time. YMMV. Again, with the localtime behaviour, this came from concerns about using non-reentrant versions of localtime(). You may not have noticed the SDOUserMacros.h file - this mechanism was introduced so that consumers of Tuscany C++ could adapt the macros to their environment. You can see the PHP version here: http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup It would be helpful if you would keep this mechanism in place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516978 ] Caroline Maynard commented on TUSCANY-1397: --- The current SDO C++ implementation does create the property on demand, and does not throw an exception. The PHP SDO implementation makes use of this behaviour. Of course it would be a SMOP to change the PHP code to use an alternative mechanism ... but what alternative mechanism exists in the spec? > createDataObject() throws NPE if property does not exist > > > Key: TUSCANY-1397 > URL: https://issues.apache.org/jira/browse/TUSCANY-1397 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Andy Grove > > Calling createDataObject( "foo" ) where the data object's type does not > define a property "foo" causes a null pointer exception in > DataObjectUtil.createDataObject(DataObject dataObject, Property property, > Type type) because it attempts to call property.isContainment without > checking if the property is null. > Calling createDataObject( "foo" ) on an open type should create an on-demand > property. If the type is not open and the property does not exist then an > exception should be thrown. > Thanks, > Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] SDO Build error on Linux
Jean-Sebastien Delfino wrote: Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF ".deps/HelperProvider.Tpo" -c -o HelperProvider.lo HelperProvider.cpp; \ then mv -f ".deps/HelperProvider.Tpo" ".deps/HelperProvider.Plo"; else rm -f ".deps/HelperProvider.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c HelperProvider.cpp -fPIC -DPIC -o .libs/HelperProvider.o ../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88: error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on member 'parseURI' Any idea? It's very likely that this is the same as http://issues.apache.org/jira/browse/TUSCANY-1425, which has been sitting around for a while. Just a reminder, we do need this in the branch as well, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1425) Compile failure on Fedora 6
[ https://issues.apache.org/jira/browse/TUSCANY-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1425: -- Attachment: tuscany-1425.patch > Compile failure on Fedora 6 > --- > > Key: TUSCANY-1425 > URL: https://issues.apache.org/jira/browse/TUSCANY-1425 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-Next > Environment: Fedora 6 > Reporter: Caroline Maynard >Priority: Critical > Attachments: tuscany-1425.patch > > > A PHP user reports a compile failure on Fedora 6. The attached change to > SDOSchemaSAX2Parser.hsorts it, and seems benign on Win. > FWIW, I also attach a fix for a compiler warning in TypeImpl.cpp. > The patch is against the pre-2.1 branch, which we're currently using for PHP, > but should be applied against the trunk too, please. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1425) Compile failure on Fedora 6
Compile failure on Fedora 6 --- Key: TUSCANY-1425 URL: https://issues.apache.org/jira/browse/TUSCANY-1425 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Environment: Fedora 6 Reporter: Caroline Maynard Priority: Critical A PHP user reports a compile failure on Fedora 6. The attached change to SDOSchemaSAX2Parser.h sorts it, and seems benign on Win. FWIW, I also attach a fix for a compiler warning in TypeImpl.cpp. The patch is against the pre-2.1 branch, which we're currently using for PHP, but should be applied against the trunk too, please. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
Caroline Maynard wrote: However we don't have a huge amount of code, and it is very simple to download it from cvs using pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo and load it into cscope or similar, so you could easily check for references that way. Or you could just mail us :-) I like the gmane address obfuscation, but there are times when it goes too far. Try pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo for that cvs repository - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
Pete Robbins wrote: On 25/06/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. Do you have a list of the non-spec interfaces PHP is using? I believe the getUserData interfaces were added for PHP use?? Yes, the UserData stuff was added as somewhere for consumers (like PHP) to be able to augment the DataObject with their own data, and it's crucial to our implementation. I've given some thought as to how we could easily create a definitive list of the Tuscany APIs employed. But since the PHP implementation includes the Tuscany code, we don't have the ability to simply list the external references as we would for a dynamic library, unless you can suggest another way. However we don't have a huge amount of code, and it is very simple to download it from cvs using pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo and load it into cscope or similar, so you could easily check for references that way. Or you could just mail us :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
Simon Laws wrote: On 6/23/07, Pete Robbins <[EMAIL PROTECTED]> wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Pete, thanks for creating the branch, it will be helpful in keeping the php implementation stable while this is going on. I understand it's hard to say how long you think the branch will be necessary, but are you going to have some groundrules about the use of the branch? I would hate to see the branch and the trunk diverging, in the sense of fixes being applied to one and not the other. Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ SDO spec portability: RefCountingPointer
Pete Robbins wrote: The ostream operator << is very useful and there is a default implementation in RefCountingObject so that objects inheriting from RefCounting object do not need to implement anything... but they can if appropriate. Yes, the << operator is very useful to consumers of the API, and at no cost to implementors because, as Pete says, a default implementation exists. Please don't remove it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope
[ https://issues.apache.org/jira/browse/TUSCANY-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1297: -- Component/s: (was: C++ DAS) C++ SDO > xsi:type in generated XML causes it not to validate/load into: visual studio > or Mindreef SOAPscope > -- > > Key: TUSCANY-1297 > URL: https://issues.apache.org/jira/browse/TUSCANY-1297 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: any >Reporter: Matthew Peters > > We use SDO to build and generate WSDL. We use the standard WSDL and SOAP > schemas (schemata?) to build the model then add port, operation, binding etc. > elements, then serialise the lot to XML. There are occasional xsi:type > attributes in the serialised XML which cause the WSDL not to validate or load > in visual studio. Here is a snippet from WSDL that we have generated in this > way: > type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType"> > > > > > > > > > > transport="http://schemas.xmlsoap.org/soap/http"; style="document"/> > > These xsi:type attributes cause this WSDL to fail to load. I quote one of our > users: > > MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will > > not import a SCA generated WSDL. It complains that it does not validate > > because of the following element attributes: > > xsi:type="tns3:tBody" of > > xsi:type="tns3:tAddress" of > > Stripping out these attributes resolved the VS WSDL import problem. > and a different bug report but the same problem: > > WSDL generated does not validate (ran against the oXygen editor and > Mindreef SOAPscope). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] JIRA status
I've recently spent some time reviewing all the JIRAs that have originated from the PHP project. All the problems which remain in Open state raised by myself, Matthew Peters or Graham Charters are genuine current issues. Also I've verified and closed off all the issues from the PHP project that were in Resolved state, so we have none there. Thanks everyone, especially Pete, for the flurry of recent fixes. There are still 32 others remaining in that state, some dating back as far as October last year. I don't have the karma to handle them myself - if the originators (or someone else) can find time to review them it would help to make their status clearer. It's a pity if issues remain in an uncertain state when someone has gone to the trouble of providing a fix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1240) Compilation warnings
Compilation warnings Key: TUSCANY-1240 URL: https://issues.apache.org/jira/browse/TUSCANY-1240 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP, Linux AMD64, gcc Reporter: Caroline Maynard Priority: Trivial Compilation warnings: /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp: In destructor `virtual commonj::sdo::PropertyImpl::~PropertyImpl()': /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp:159: warning: deleting `void*' is undefined /home/cem/pecl-sdo-BUZZARD/commonj/sdo/PropertyImpl.cpp:163: warning: deleting `void*' is undefined These are not malignant, but should be fixed some time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] SDOList is not reference-counted
I've recently had to fix a problem in the SDO for PHP code where the user was holding a reference to a DataObjectList, the containing DataObject was dropped, and the list went eerily empty. Example: DataObjectPtr dop = xmlDocumentPtr->getRootDataObject(); DataObjectList& dol = dop->getList(propertyName); /* print the list - it's populated */ dop = NULL; /* print the list - it's now empty */ I fixed this by making the PHP wrapper for the list also hold a reference to the containing DataObject, so that it will not be freed whilst the user is working on the list. I think this is Working As Designed according to the specification, and it was just my carelessness in assuming that a DataObjectList is reference-counted in the same way as a DataObject. But I'm inclined to see this as a spec issue - I don't see why DataObjectLists would behave differently from DataObjects, and it makes the API quite confusing. What's the rationale for this? A related issue is that I don't see a (public) way to reach the containing DataObject from a DataObjectList. Did I miss something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] XMLDocument has no root object
On 27/04/07, Andy Grove <[EMAIL PROTECTED]> wrote: I'm not using schema - is that a problem? Ah. Welcome to https://issues.apache.org/jira/browse/TUSCANY-747 -- Caroline
Re: [C++] XMLDocument has no root object
On 27/04/07, Andy Grove <[EMAIL PROTECTED]> wrote: Hi Caroline, If I call xmlHelper->save(doc) I just get the prolog e.g. "" and no content. I've tried with a couple of different input documents and I have also confirmed that I do get an exception if the input document doesn't exist. I've had this happen too, and it was because the document wasn't valid against the schema. The symptoms were as you describe. In my case ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10937.html) the circumstances were a bit different, but probably something is amiss with your input and libxml2 isn't kind enough to tell you. Can you try pushing them through an XML validator? -- Caroline
Re: [C++] XMLDocument has no root object
On 27/04/07, Andy Grove <[EMAIL PROTECTED]> wrote: I am trying to parse an XML document using Tuscany C++ (current build). The XMLHelper::loadFile() method is returning an XMLDocumentPtr and no exceptions are thrown. However, a call to XMLDocument::getRootDataObject() returns NULL. What do you see if you print the XMLDocument ? -- Caroline
[jira] Created: (TUSCANY-1236) False positives from DataObject::isSet (xpath)
False positives from DataObject::isSet (xpath)
--
Key: TUSCANY-1236
URL: https://issues.apache.org/jira/browse/TUSCANY-1236
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-M1
Environment: PHP, Win32
Reporter: Caroline Maynard
Problem occurs when a PHP SDO program uses Xpath notation. For example:
isset($rss['channel/item[2]']);
The PHP sdo implementation currently does not attempt to parse the Xpath, but
delegates this to Tuscany. It is unaware that the final part of the Xpath is an
index into a list, so doesn't know to do any extra processing.
Currently the logic in DataObjectImpl::isSet() checks that the list
exists and is not empty. If so, it returns true. This is a necessary condition,
but in my example above it is not sufficient - it should also test if the size
is at least 2.
I couldn't find an easy way to achieve this with the code as it stands - I did
work up a prototype using something like:
--- DataObjectImpl.cpp 19 Apr 2007 14:25:52 - 1.16.4.3
+++ DataObjectImpl.cpp 27 Apr 2007 11:30:50 -
@@ -1906,7 +1906,20 @@
if (d != 0) {
if (!prop.empty()) {
const Property& p = d->getProperty(prop);
-return d->isSet(p);
+if (p.isMany())
+{
+if (d->isSet(p))
+{
+long index;
+if (d->findDataObject(prop, &index))
+return true;
+}
+}
+else
+{
+return d->isSet(p);
+}
}
}
string msg("Invalid path:");
but that's rather clumsy and probably fails in some other way. Perhaps an extra
long *listIndex parameter to getPropertyContainer() would do it?
Alternatively, Tuscany might prefer to hand up some more control to the caller,
for example by adding some new function to the XpathHelper.
(P.S. The same issue would apply to isValid as well as isSet.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1226) Nulls go missing in CopyHelper
[
https://issues.apache.org/jira/browse/TUSCANY-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard closed TUSCANY-1226.
-
> Nulls go missing in CopyHelper
> --
>
> Key: TUSCANY-1226
> URL: https://issues.apache.org/jira/browse/TUSCANY-1226
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP, WIn32
> Reporter: Caroline Maynard
>Priority: Minor
> Fix For: Cpp-current
>
> Attachments: Tuscany-1226.patch
>
>
> This is perhaps a variation on Tuscany-1225. Problem is that when using
> CopyHelper to clone a DataObject, properties which are set to null remain
> unset in the destination DataObject.
> Example:
> SCHEMA:
>
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="PersonNamespace"
> xmlns:AuthorNS="PersonNamespace">
>
>
>
>
>
>
>
>
> logic:
> $xmldas = SDO_DAS_XML::create('person.xsd');
> $person = $xmldas->createDataObject('PersonNamespace','personType');
> $person->name = "William Shakespeare'";
> $person->dob = null;
> $person->pob = null;
> $person2 = clone($person);
> After the clone the php $person looks like:
> object(SDO_DataObject)#3 (3) {name=>"William Shakespeare'"; dob=>NULL;
> pob=>NULL}
> but $person2 is:
> object(SDO_DataObject)#4 (3) {name=>"William Shakespeare'"; dob; pob}
> (I can't show you the Tuscany print of the DO, because it causes an
> AccessViolation :-) )
> Problem is perhaps that transferitem() doesn't consider nulls
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1133) Support the PHP extension under Windows
[ https://issues.apache.org/jira/browse/TUSCANY-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1133. - > Support the PHP extension under Windows > --- > > Key: TUSCANY-1133 > URL: https://issues.apache.org/jira/browse/TUSCANY-1133 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-current > Reporter: Caroline Maynard >Priority: Minor > Fix For: Cpp-current > > Attachments: Tuscany-1133.patch > > > I've been battling with getting this working under Windows, and attach a > patch with my latest efforts. Note that these changes work hand-in-hand with > corresponding changes to the Tuscany bindings for PHP SCA, which are already > in place in the AVOCET branch in the PECL repository. > On my Windows box with the patch installed, the PHP Calculator sample runs > clean, with no crashes on shutdown and no reported leaks of PHP memory. > I've also done quite a bit of tidying up, to make the inner workings a more > standard use of the PHP engine. In particular, I've broken out the big > php_eval_script() into its component parts, which makes it much easier to > debug. Unfortunately I haven't had time to refactor > SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at > present and could do with further prettying. I also hid the SCA_Tuscany > object handle from user space, because exporting the handle as a reference > was rather dangerous code. > One thing I haven't yet tackled is getting the thread context right for > reentrant paths through the extension. I've been investigating this, and I > think it's going to require saving a thread context in each of the mediator > objects, and restoring the correct one on invoke(). However what's there > seems to work OK in the simple environment of the PHP Calculator sample. > I'm out for a few days now - could someone give it a spin on *IX and make > sure that's still OK? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1225) Access violation in CopyHelper
[
https://issues.apache.org/jira/browse/TUSCANY-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard closed TUSCANY-1225.
-
The AccessViolation is gone. The test still doesn't work, but I'll use
Tuscany-1226 to track that.
> Access violation in CopyHelper
> --
>
> Key: TUSCANY-1225
> URL: https://issues.apache.org/jira/browse/TUSCANY-1225
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: Win32, PHP
>Reporter: Caroline Maynard
> Assigned To: Pete Robbins
> Fix For: Cpp-current
>
>
> Cloning a DataObject withe a property that has been explicitly set to null
> results in an AccessViolation:
> commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
> {...}, unsigned char 0x01) line 277 + 3 bytes
> commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
> {...}, unsigned char 0x01) line 403 + 41 bytes
> commonj::sdo::CopyHelper::copy(commonj::sdo::RefCountingPointer
> {...}) line 267 + 29 bytes
> sdo_do_clone_obj(_zval_struct * 0x0120c050, void * * * 0x003d2a20) line 208 +
> 33 bytes
> On the second entry to internalCopy(), the dataObject is null, which results
> in the AccessViolation when trying to get the DataFactory.
> Example:
> schema:
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:ord="orderNS" xmlns:cust="customerNS" targetNamespace="orderNS">
>
>
>
>
>
>
>
>
>
> document:
> $customer_xsd = <<
> http://www.w3.org/2001/XMLSchema";
> xmlns:cust="customerNS" targetNamespace="customerNS">
>
>
>
>
>
>
>
> logic:
> $xmldas = SDO_DAS_XML::create('Order.xsd');
> $order = $xmldas->createDataObject('orderNS','OrderType');
> $order->customer = null;
> $o = clone $order;
> If customer is unset, there is no problem. Or if it is set to a real data
> object there is no problem either.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1226) Nulls go missing in CopyHelper
[
https://issues.apache.org/jira/browse/TUSCANY-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard reopened TUSCANY-1226:
---
> Nulls go missing in CopyHelper
> --
>
> Key: TUSCANY-1226
> URL: https://issues.apache.org/jira/browse/TUSCANY-1226
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP, WIn32
> Reporter: Caroline Maynard
>Priority: Minor
> Fix For: Cpp-current
>
> Attachments: Tuscany-1226.patch
>
>
> This is perhaps a variation on Tuscany-1225. Problem is that when using
> CopyHelper to clone a DataObject, properties which are set to null remain
> unset in the destination DataObject.
> Example:
> SCHEMA:
>
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="PersonNamespace"
> xmlns:AuthorNS="PersonNamespace">
>
>
>
>
>
>
>
>
> logic:
> $xmldas = SDO_DAS_XML::create('person.xsd');
> $person = $xmldas->createDataObject('PersonNamespace','personType');
> $person->name = "William Shakespeare'";
> $person->dob = null;
> $person->pob = null;
> $person2 = clone($person);
> After the clone the php $person looks like:
> object(SDO_DataObject)#3 (3) {name=>"William Shakespeare'"; dob=>NULL;
> pob=>NULL}
> but $person2 is:
> object(SDO_DataObject)#4 (3) {name=>"William Shakespeare'"; dob; pob}
> (I can't show you the Tuscany print of the DO, because it causes an
> AccessViolation :-) )
> Problem is perhaps that transferitem() doesn't consider nulls
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1226) Nulls go missing in CopyHelper
[
https://issues.apache.org/jira/browse/TUSCANY-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1226:
--
Attachment: Tuscany-1226.patch
Got rid of the crash but didn't quite do it for me. Two reasons:
a) NULLs are not the same as empty strings.
b) Still getting SDONullPointerExceptions out of resolveReferences()
The attached makes my tests run OK. How is it for you?
> Nulls go missing in CopyHelper
> --
>
> Key: TUSCANY-1226
> URL: https://issues.apache.org/jira/browse/TUSCANY-1226
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP, WIn32
>Reporter: Caroline Maynard
>Priority: Minor
> Fix For: Cpp-current
>
> Attachments: Tuscany-1226.patch
>
>
> This is perhaps a variation on Tuscany-1225. Problem is that when using
> CopyHelper to clone a DataObject, properties which are set to null remain
> unset in the destination DataObject.
> Example:
> SCHEMA:
>
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="PersonNamespace"
> xmlns:AuthorNS="PersonNamespace">
>
>
>
>
>
>
>
>
> logic:
> $xmldas = SDO_DAS_XML::create('person.xsd');
> $person = $xmldas->createDataObject('PersonNamespace','personType');
> $person->name = "William Shakespeare'";
> $person->dob = null;
> $person->pob = null;
> $person2 = clone($person);
> After the clone the php $person looks like:
> object(SDO_DataObject)#3 (3) {name=>"William Shakespeare'"; dob=>NULL;
> pob=>NULL}
> but $person2 is:
> object(SDO_DataObject)#4 (3) {name=>"William Shakespeare'"; dob; pob}
> (I can't show you the Tuscany print of the DO, because it causes an
> AccessViolation :-) )
> Problem is perhaps that transferitem() doesn't consider nulls
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-962) Incorrect namespace for open content
[
https://issues.apache.org/jira/browse/TUSCANY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard closed TUSCANY-962.
> Incorrect namespace for open content
>
>
> Key: TUSCANY-962
> URL: https://issues.apache.org/jira/browse/TUSCANY-962
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Reporter: Caroline Maynard
>Priority: Blocker
> Fix For: Cpp-current
>
>
> I use XSDHelper::defineFile() to load the two schemas at
> http://schemas.xmlsoap.org/wsdl/ and http://schemas.xmlsoap.org/wsdl/soap/.
> I then build up an XML Document using that factory. I create an empty
> document and get the root data object. Then
> - create a child object (type
> http://schemas.xmlsoap.org/wsdl/#tService) on the root
> - create a child object (type http://schemas.xmlsoap.org/wsdl/#tPort)
> on the service
> - create an child object (type
> http://schemas.xmlsoap.org/wsdl/soap/#tAddress) on the port, as an open type
> At this point I can introspect my port object, and I see:
> object(SDO_Model_ReflectionDataObject)#9 {
> - Instance of {port}
> - Type http://schemas.xmlsoap.org/wsdl/:tPort
> - Instance Properties[4] {
> http://schemas.xmlsoap.org/wsdl/:tDocumentation $documentation {
> }
> commonj.sdo:String $name;
> commonj.sdo:URI $binding;
> http://schemas.xmlsoap.org/wsdl/soap/:tAddress $address {
> commonj.sdo:Boolean $required;
> commonj.sdo:URI $location;
> }
> }
> }
> This looks correct to me.
> Now we get to the problem. I save the XML document to a string. and it comes
> out like this:
>
> http://schemas.xmlsoap.org/wsdl/";
> xmlns:tns="http://schemas.xmlsoap.org/wsdl/";
> xmlns:tns2="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
> http://example.com"/>
>
>
>
> You'll notice that address has no namespace, and so is in the wsdl namespace
> by default, not the soap namespace where it belongs.
> This is using revision 478193.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-980) DataObject assigned into open property goes missing
[ https://issues.apache.org/jira/browse/TUSCANY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-980. > DataObject assigned into open property goes missing > --- > > Key: TUSCANY-980 > URL: https://issues.apache.org/jira/browse/TUSCANY-980 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Reporter: Caroline Maynard > Fix For: Cpp-M3 > > > I have a schema like so: >xmlns="http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > and another one like so: > http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > Now suppose I load BOTH schemas into the same DataFactory, create a document > with root type jungle, create some animal types and then assign them into the > jungle. When I save the document, I see: > > http://www.w3.org/2001/XMLSchema-instance";> > > Baloo > 700 > > > Bagheera > inky black > > > Kaa > 25 > > > This is good. > Now I change the example so that the two schemas are loaded into DIFFERENT > Data Factories, and run the same test. The saved document is now: > > http://www.w3.org/2001/XMLSchema-instance";> > > > > > so the elements have turned into attributes. > Finally, I change the test so that the document root is a mixedJungle instead > of a jungle, that is, it is sequenced. No errors are reported, but my > document comes out as: > > http://www.w3.org/2001/XMLSchema-instance"/> > Now the animals are completely missing. The outcome is the same regardless of > whether I use one or two data factories, btw. > I am at revision 483149, so should have all the latest fixes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-988) Xpath doesn't work with nested open properties
[
https://issues.apache.org/jira/browse/TUSCANY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491857
]
Caroline Maynard commented on TUSCANY-988:
--
See http://pecl.php.net/bugs/bug.php?id=10842
> Xpath doesn't work with nested open properties
> --
>
> Key: TUSCANY-988
> URL: https://issues.apache.org/jira/browse/TUSCANY-988
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Reporter: Caroline Maynard
> Fix For: Cpp-M3
>
>
> I'm using the same Jungle schema as before, but this time my bear type is
> itself open. So the jungle is:
>xmlns="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
> and the bear is:
> http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
> I load the jungle and the animal schemas into the same data factory. Then
> create an empty xml document, assign into it a bear, then assign into that
> bear a second bear. The instance is created fine, and I can access the nested
> bear or dump out the entire instance:
>
> http://www.w3.org/2001/XMLSchema-instance";>
>
> Mummy Bear
> 700
>
> Baby Bear
> 100
>
>
>
> The problem occurs when I try to use Xpath notation to reach the baby bear,
> so I'm doing a getProperty("bear/bear") on the jungle object. This fails in
> commonj::sdo::DataObjectImpl::getPropertyImpl(const
> std::basic_string,std::allocator > &
> {0x01131b69 "bear/bear"}) line 3228 + 42 bytes
> commonj::sdo::DataObjectImpl::getProperty(const
> std::basic_string,std::allocator > &
> {0x01131b69 "bear/bear"}) line 3205 + 20 bytes
> commonj::sdo::DataObjectImpl::getProperty(const char * 0x01a7e840) line 3200
> + 59 bytes
> because it doesn't handle the name as a potential Xpath, and reaches the end
> of the iteration without a match. An SDOPropertyNotFoundException is raised
> with the message "Cannot find property :bear/bear".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-907) Schema Import is noisy when schemaLocation is an abolute URI
[ https://issues.apache.org/jira/browse/TUSCANY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-907. Resolution: Fixed Warnings have been eliminated. > Schema Import is noisy when schemaLocation is an abolute URI > > > Key: TUSCANY-907 > URL: https://issues.apache.org/jira/browse/TUSCANY-907 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Java-M1 > Reporter: Caroline Maynard > Fix For: Cpp-M3 > > Attachments: Tuscany-907.patch > > > See http://pecl.php.net/bugs/bug.php?id=9243. > SDO for PHP user is importing a schema with import statements like > http://ping.chip.org/xml/pid"; > schemaLocation="http://ping.chip.org/xml/pid.xsd"/> > These are unconventional, since the schemaLocation is not usually an absolute > URI, but they are valid. > They see a lot (I mean a lot) of warning messages like: > SDO_DAS_XML::create(http://ping.chip.org/phr/xml/http://ping.chip.org/phr/xml/types.xsd) > [function.SDO-DAS-XML-create]: failed to open stream:HTTP request failed! > HTTP/1.1 404 Not Found > where, as you can see, an invalid URI is being created and used. However the > schema is read successfully. > There are potentially quite a few issues here around the handling of libxml > error messages, but I'll restrict myself to the behaviour of > SDOSchemaSAX2Parser::startSecondaryParse > This tries to deal with four different ways to combine the path to the > current schema with the schemaLocation attribute of the import element. > Eventually the imported schema is found, but only after URIs like the one in > the message above are created and used. > I wasn't too happy with this particular method, so I perhaps went to the > other extreme with the patch I shall attach, where I let libxml combine the > two values according to RFC 2396. It works for me, but you may well have > testcases where it fails, and want to approach the problem some other way. > Whether or not you like the patch, I think something should be done to avoid > the flurry of warnings about ill-formed URIs like the above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[ https://issues.apache.org/jira/browse/TUSCANY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-625. > [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is > omitted from an import > -- > > Key: TUSCANY-625 > URL: https://issues.apache.org/jira/browse/TUSCANY-625 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-M1 > Reporter: Caroline Maynard > Assigned To: Pete Robbins >Priority: Minor > Fix For: Cpp-M3 > > > A PHP user is trying to work with a service defined by > http://api.urbandictionary.com/soap > However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException: > 'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' > I think this is because the required type is defined via an import: > http://schemas.xmlsoap.org/soap/encoding/"; /> > which omits the schemaLocation. > Arguably the wsdl in question is a bit defective, and the problem can be > bypassed by hand-editing the wsdl to add the schemaLocation attribute. But > Tuscany could be a bit more helpful, and try to use the namespace URI when > schemaLocation is omitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[ https://issues.apache.org/jira/browse/TUSCANY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard resolved TUSCANY-625. -- Resolution: Fixed At some point a second (boolean) parameter was added to defineFile to control this behaviour. Works for me. > [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is > omitted from an import > -- > > Key: TUSCANY-625 > URL: https://issues.apache.org/jira/browse/TUSCANY-625 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-M1 > Reporter: Caroline Maynard > Assigned To: Pete Robbins >Priority: Minor > Fix For: Cpp-M3 > > > A PHP user is trying to work with a service defined by > http://api.urbandictionary.com/soap > However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException: > 'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' > I think this is because the required type is defined via an import: > http://schemas.xmlsoap.org/soap/encoding/"; /> > which omits the schemaLocation. > Arguably the wsdl in question is a bit defective, and the problem can be > bypassed by hand-editing the wsdl to add the schemaLocation attribute. But > Tuscany could be a bit more helpful, and try to use the namespace URI when > schemaLocation is omitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1231) Various incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1231:
--
Component/s: (was: C++ DAS)
C++ SDO
> Various incorrect namespaces in generated XML
> -
>
> Key: TUSCANY-1231
> URL: https://issues.apache.org/jira/browse/TUSCANY-1231
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-M3
> Environment: WinXP
>Reporter: Matthew Peters
>
> Given the following two xsds, which define an add element in http://Component
> and a PersonType in http://www.test.com/info...
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','personType');
> $name = $person->createDataObject('name');
> $name->first = "Will";
> $name->last = "Shakespeare";
> $add = $xmldas->createDataObject('http://Component','add');
> $add->person = $person;
> $xdoc = $xmldas->createDocument('', 'BOGUS', $add);
> $xmlstr = $xmldas->saveString($xdoc, 2);
> echo $xmlstr;
> ?>
> types.xsd:
> http://www.w3.org/2001/XMLSchema";
> xmlns:ns0="http://www.test.com/info";
> targetNamespace="http://Component";
> elementNameDefault="qualified">
>namespace="http://www.test.com/info"/>
>
>
>
> nillable="true"/>
>
>
>
>
> person.xsd:
>
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.test.com/info";
> xmlns:info="http://www.test.com/info";>
>
>
>
>
>
>
>
>
>
>
>
>
> ... if you now create a document with an 'add' element, create a PersonType
> object and assign meaningful first and last names, and serialise to XML, you
> get:
>
> http://Component"; xmlns:tns="http://Component";
> xmlns:tns2="http://www.test.com/info";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
> Will
> Shakespeare
>
>
>
> There are several things wrong with this XML.
> 1. "name" should not be in tns2=http://www.test.com/info, and neither should
> "first" and "last" be in the default namespace of http://Component. The
> person.xsd has no elementFormDefault, so the elements below should
> all be in the no name namespace.
> 2.You have to change the person.xsd to see the next thing: put
> ElementNameDefault="qualified" in
> the person schema, then "name", "first" and "last" should all now be
> coming out in the http://www.test.com/info namespace, but it makes no
> difference to the generated XML.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1112) Incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1112:
--
Component/s: (was: C++ DAS)
C++ SDO
> Incorrect namespaces in generated XML
> -
>
> Key: TUSCANY-1112
> URL: https://issues.apache.org/jira/browse/TUSCANY-1112
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: WinXP
>Reporter: Matthew Peters
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is
> however pretty trivial and it seems a simple thing to make in C. Also, I know
> that the PHP layer is doing very little to interfere, so this is genuine
> Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
>
> I have been quite sceptical about the XML that SDO is producing when it
> builds a SOAP request, especially w.r.t. the namespaces. So I tried
> loading the XML that SDO is producing into Java XERCES with validation
> on. There are several problems with the XML generated, I think.
> Using the two xsds that are in the reproduce section below, and the
> short PHP script also there, SDO generates:
>
> http://Component"; xmlns:tns="http://Component";
> xmlns:tns2="http://www.test.com/info";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:type="add">
>
>
> Will
> Shakespeare
>
>
>
> There are three (!) things wrong with this.
> 1. XERCES will not accept the xsi:type="add". I do not really know why.
> I assume this is because there is no type called "add", it's only an
> element. So I do not think this should be coming out.
> 2. name should not be in tns2=http://www.test.com/info, neither should
> "first" and "last" be in the default namespace of http://Component. The
> person.xsd has no elementFormDefault, so the elements below
> should all ne in the no name namespace.
> 3.You have to change the person.xsd to see the third thing: put
> ElementNameDefault="qualified" in
> the person schema, then "name", "first" and "last" should all now be
> coming out in the http://www.test.com/info namespace, but it makes no
> difference to the generated XML.
> Reproduce code:
> ---
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','personType');
> $name = $person->createDataObject('name');
> $name->first = "Will";
> $name->last = "Shakespeare";
> $add = $xmldas->createDataObject('http://Component','add');
> $add->person = $person;
> $xdoc = $xmldas->createDocument('', 'BOGUS', $add);
> $xmlstr = $xmldas->saveString($xdoc, 2);
> echo $xmlstr;
> ?>
> types.xsd:
> http://www.w3.org/2001/XMLSchema";
> xmlns:ns0="http://www.test.com/info";
> targetNamespace="http://Component";
> elementNameDefault="qualified">
>namespace="http://www.test.com/info"/>
>
>
>
> nillable="true"/>
>
>
>
>
> person.xsd:
>
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.test.com/info";
> xmlns:info="http://www.test.com/info";>
>
>
>
>
>
>
>
>
>
>
>
>
> Expected result:
>
> see above
> Actual result:
> --
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> I just came across what I think is another example of this. Now I
> understand better how namespaces work, I suspect it is more common than
> we realise.
> Here's the example in a nutshell:
> Catalog.xsd defines a catalog element in the catalogNS namespace, which
> contains items defined in a different namespace in a different file,
> Order.xsd:
> http://www.w3.org/2001/XMLSchema";
> xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>
>
>
>
>
>
>
>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> http://www.w3.org/2001/XMLSchema";
> xmlns:ord="orderNS" xmlns:cust="customerNS" targetNamespace="orderNS">
> .../...
>
> .../...
> but when you build a catalog and write it out, although a namespace
> prefix is defined for "orderNS", everything is in the default namespace,
> "catalogNS":
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:tns2="orderNS">
>
> .../...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[ https://issues.apache.org/jira/browse/TUSCANY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491468 ] Caroline Maynard commented on TUSCANY-625: -- We're still hoping for solution to this one. > [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is > omitted from an import > -- > > Key: TUSCANY-625 > URL: https://issues.apache.org/jira/browse/TUSCANY-625 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-M1 >Reporter: Caroline Maynard > Assigned To: Pete Robbins >Priority: Minor > Fix For: Cpp-M3 > > > A PHP user is trying to work with a service defined by > http://api.urbandictionary.com/soap > However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException: > 'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' > I think this is because the required type is defined via an import: > http://schemas.xmlsoap.org/soap/encoding/"; /> > which omits the schemaLocation. > Arguably the wsdl in question is a bit defective, and the problem can be > bypassed by hand-editing the wsdl to add the schemaLocation attribute. But > Tuscany could be a bit more helpful, and try to use the namespace URI when > schemaLocation is omitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-950) CopyHelper::copy() forgets sequence information
[ https://issues.apache.org/jira/browse/TUSCANY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-950. Resolution: Fixed Problem stated has been fixed. > CopyHelper::copy() forgets sequence information > --- > > Key: TUSCANY-950 > URL: https://issues.apache.org/jira/browse/TUSCANY-950 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Reporter: Caroline Maynard > Fix For: Cpp-M3 > > Attachments: sdoclone-sequences.txt > > > An SDO for PHP user has reported the following at > http://pecl.php.net/bugs/bug.php?id=9487 > He is using CopyHelper::copy() to copy a seqenced data object. The properties > are copied OK, but the unstructured text is forgotten. So when I inspect the > copied DataObject, its properties have the same values as the original. But > if I do a getSequence() on it, I get a Sequence object which is empty. That > is, neither its properties nor its unstructured text are set. > This should be self-explanatory, but I'll create a testcase if you need one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1227) FileException not thrown when schema file missing
FileException not thrown when schema file missing
-
Key: TUSCANY-1227
URL: https://issues.apache.org/jira/browse/TUSCANY-1227
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: PHP, Win32
Reporter: Caroline Maynard
Priority: Minor
This regression occurred a few months back. When I do
XSDHelper::defineFile("nonexistent.xsd"), Tuscany used to give me an
SDOFileNotFoundException. Now it does not throw an exception. Instead it
returns with a non-zero error count, and messages:
1 parse error(s) occurred when parsing the file 'xxx':
1. xmlSAXUserParseFile returned an error -1 ' in Command line code:1
I'd really like the exception back, because it's confusing for end-users to get
what looks like a parsing failure when the file is just not there.
If necessary I will check the file stat in the php code before calling Tuscany
and raise an exception directly, but I'm not sure I know exactly what the path
spec is that libxml2 uses to find a relative file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1226) Nulls go missing in CopyHelper
Nulls go missing in CopyHelper
--
Key: TUSCANY-1226
URL: https://issues.apache.org/jira/browse/TUSCANY-1226
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: PHP, WIn32
Reporter: Caroline Maynard
Priority: Minor
Fix For: Cpp-current
This is perhaps a variation on Tuscany-1225. Problem is that when using
CopyHelper to clone a DataObject, properties which are set to null remain unset
in the destination DataObject.
Example:
SCHEMA:
http://www.w3.org/2001/XMLSchema";
targetNamespace="PersonNamespace"
xmlns:AuthorNS="PersonNamespace">
logic:
$xmldas = SDO_DAS_XML::create('person.xsd');
$person = $xmldas->createDataObject('PersonNamespace','personType');
$person->name = "William Shakespeare'";
$person->dob = null;
$person->pob = null;
$person2 = clone($person);
After the clone the php $person looks like:
object(SDO_DataObject)#3 (3) {name=>"William Shakespeare'"; dob=>NULL;
pob=>NULL}
but $person2 is:
object(SDO_DataObject)#4 (3) {name=>"William Shakespeare'"; dob; pob}
(I can't show you the Tuscany print of the DO, because it causes an
AccessViolation :-) )
Problem is perhaps that transferitem() doesn't consider nulls
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1225) Access violation in CopyHelper
[
https://issues.apache.org/jira/browse/TUSCANY-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491222
]
Caroline Maynard commented on TUSCANY-1225:
---
Of course those are two parts of the same schema - there is no input xml
document
> Access violation in CopyHelper
> --
>
> Key: TUSCANY-1225
> URL: https://issues.apache.org/jira/browse/TUSCANY-1225
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: Win32, PHP
> Reporter: Caroline Maynard
>
> Cloning a DataObject withe a property that has been explicitly set to null
> results in an AccessViolation:
> commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
> {...}, unsigned char 0x01) line 277 + 3 bytes
> commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
> {...}, unsigned char 0x01) line 403 + 41 bytes
> commonj::sdo::CopyHelper::copy(commonj::sdo::RefCountingPointer
> {...}) line 267 + 29 bytes
> sdo_do_clone_obj(_zval_struct * 0x0120c050, void * * * 0x003d2a20) line 208 +
> 33 bytes
> On the second entry to internalCopy(), the dataObject is null, which results
> in the AccessViolation when trying to get the DataFactory.
> Example:
> schema:
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:ord="orderNS" xmlns:cust="customerNS" targetNamespace="orderNS">
>
>
>
>
>
>
>
>
>
> document:
> $customer_xsd = <<
> http://www.w3.org/2001/XMLSchema";
> xmlns:cust="customerNS" targetNamespace="customerNS">
>
>
>
>
>
>
>
> logic:
> $xmldas = SDO_DAS_XML::create('Order.xsd');
> $order = $xmldas->createDataObject('orderNS','OrderType');
> $order->customer = null;
> $o = clone $order;
> If customer is unset, there is no problem. Or if it is set to a real data
> object there is no problem either.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1225) Access violation in CopyHelper
Access violation in CopyHelper
--
Key: TUSCANY-1225
URL: https://issues.apache.org/jira/browse/TUSCANY-1225
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Win32, PHP
Reporter: Caroline Maynard
Cloning a DataObject withe a property that has been explicitly set to null
results in an AccessViolation:
commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
{...}, unsigned char 0x01) line 277 + 3 bytes
commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointer
{...}, unsigned char 0x01) line 403 + 41 bytes
commonj::sdo::CopyHelper::copy(commonj::sdo::RefCountingPointer
{...}) line 267 + 29 bytes
sdo_do_clone_obj(_zval_struct * 0x0120c050, void * * * 0x003d2a20) line 208 +
33 bytes
On the second entry to internalCopy(), the dataObject is null, which results in
the AccessViolation when trying to get the DataFactory.
Example:
schema:
http://www.w3.org/2001/XMLSchema";
xmlns:ord="orderNS" xmlns:cust="customerNS" targetNamespace="orderNS">
document:
$customer_xsd = <<
http://www.w3.org/2001/XMLSchema";
xmlns:cust="customerNS" targetNamespace="customerNS">
logic:
$xmldas = SDO_DAS_XML::create('Order.xsd');
$order = $xmldas->createDataObject('orderNS','OrderType');
$order->customer = null;
$o = clone $order;
If customer is unset, there is no problem. Or if it is set to a real data
object there is no problem either.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()
[ https://issues.apache.org/jira/browse/TUSCANY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1202. - Resolution: Fixed Fix Version/s: Cpp-current Combined patch committed > AccessViolation in DataObjectImpl::logDeletion() > > > Key: TUSCANY-1202 > URL: https://issues.apache.org/jira/browse/TUSCANY-1202 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: PHP > Reporter: Caroline Maynard > Fix For: Cpp-current > > Attachments: Tuscany-1202.patch > > > Like Tuscany 1147, this problem is seen running the SDOAPITest PHPUNIT > testcase. The scenario is the same, but this time ChangeLogging type objects > exist in the tree (note that Logging does not need to be turned on to see the > problem). As with 1147, the problem is seen when the code using Tuscany holds > references to objects at different levels in the tree, such that they are > held after the root object no longer exists. > It's the standard company->departments->employees setup. When the company is > dropped, the Tuscany code does reset the container and the applicable change > summary for the department. But it doesn't drill down and do the same for the > employee. The consequence is that the employee still has a changesummary > pointer to the company's changesummary. When that gets referenced, in this > testcase when unsetting the employee from the department, the changesummary > value is tested and an AccessViolation occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
[
https://issues.apache.org/jira/browse/TUSCANY-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard closed TUSCANY-1203.
-
Resolution: Fixed
Fix Version/s: Cpp-current
Combined patch committed
> Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
> --
>
> Key: TUSCANY-1203
> URL: https://issues.apache.org/jira/browse/TUSCANY-1203
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP
> Reporter: Caroline Maynard
> Fix For: Cpp-current
>
> Attachments: Tuscany-1203.patch
>
>
> This one occurs when deleting a DataObject which has several open properties.
> The logic in the destructor is:
> while (i != PropertyValues.end())
> {
> unsigned int pindx = (*i).first;
> DataObjectImplPtr dol = (*i).second;
> unset(pindx);
> i = PropertyValues.begin();
> if (i != PropertyValues.end() && (*i).first == pindx )
> {
> // unset has not removed the item from the list - do it
> // here instead
> PropertyValues.erase(i);
> i = PropertyValues.begin();
> }
> }
> However what happens in the unset() method is that if the property is open,
> undefineProperty() is called. This removes the open property and "shuffles
> up" the rest, so that a different property is assigned the property index
> pindx. Which means that even though the unset has removed the item from the
> list, the test (*).first==pindx passes, which results in the next property
> being removed from the list even though it has not yet been unset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1147. - Resolution: Fixed Fix Version/s: Cpp-current Patch committed > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 > Reporter: Caroline Maynard >Priority: Critical > Fix For: Cpp-current > > Attachments: SDOAPITest.php, Tuscany-1147.patch, Tuscany-1147.patch, > Tuscany-1147.patch, Tuscany-combined.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: {SDO C++] Untangling the graph without access violations
Thanks, Pete On 10/04/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Patch applied. Looks ok to me. -- Caroline
{SDO C++] Untangling the graph without access violations
Memory leaks are a major concern for PHP users in a long-running web server. For some time we've had a problem that we cannot reliably drop a datagraph because of various access violations which may occur, depending on the order in which the data objects are released. We've bypassed the access violations by omitting to drop the graph at the end of each script, but that's not a real solution as the memory leaks just mount up over time. Recently I've been working through the problems, which I've documented in defects 1147, 1202 and 1203. I now have a patch for Tuscany C++ which permits the tree to be dropped. I've uploaded it as Tuscany-combined.patch, as an attachment to https://issues.apache.org/jira/browse/TUSCANY-1147. With this combined patch in place, the Tuscany SDO C++ tests run clean, as well as the PHP tests. Please would a Tuscany committer review and apply this patch - it would be a great help to PHP users. -- Caroline
[jira] Updated: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
[
https://issues.apache.org/jira/browse/TUSCANY-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1203:
--
Patch Info: [Patch Available]
I'vve added to 1147 a combined patch for 1147, 1202 and 1203, which should be
simpler to apply.
> Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
> --
>
> Key: TUSCANY-1203
> URL: https://issues.apache.org/jira/browse/TUSCANY-1203
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP
>Reporter: Caroline Maynard
> Attachments: Tuscany-1203.patch
>
>
> This one occurs when deleting a DataObject which has several open properties.
> The logic in the destructor is:
> while (i != PropertyValues.end())
> {
> unsigned int pindx = (*i).first;
> DataObjectImplPtr dol = (*i).second;
> unset(pindx);
> i = PropertyValues.begin();
> if (i != PropertyValues.end() && (*i).first == pindx )
> {
> // unset has not removed the item from the list - do it
> // here instead
> PropertyValues.erase(i);
> i = PropertyValues.begin();
> }
> }
> However what happens in the unset() method is that if the property is open,
> undefineProperty() is called. This removes the open property and "shuffles
> up" the rest, so that a different property is assigned the property index
> pindx. Which means that even though the unset has removed the item from the
> list, the test (*).first==pindx passes, which results in the next property
> being removed from the list even though it has not yet been unset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()
[ https://issues.apache.org/jira/browse/TUSCANY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1202: -- Patch Info: [Patch Available] I'vve added to 1147 a combined patch for 1147, 1202 and 1203, which should be simpler to apply. > AccessViolation in DataObjectImpl::logDeletion() > > > Key: TUSCANY-1202 > URL: https://issues.apache.org/jira/browse/TUSCANY-1202 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: PHP >Reporter: Caroline Maynard > Attachments: Tuscany-1202.patch > > > Like Tuscany 1147, this problem is seen running the SDOAPITest PHPUNIT > testcase. The scenario is the same, but this time ChangeLogging type objects > exist in the tree (note that Logging does not need to be turned on to see the > problem). As with 1147, the problem is seen when the code using Tuscany holds > references to objects at different levels in the tree, such that they are > held after the root object no longer exists. > It's the standard company->departments->employees setup. When the company is > dropped, the Tuscany code does reset the container and the applicable change > summary for the department. But it doesn't drill down and do the same for the > employee. The consequence is that the employee still has a changesummary > pointer to the company's changesummary. When that gets referenced, in this > testcase when unsetting the employee from the department, the changesummary > value is tested and an AccessViolation occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-combined.patch I've appended a combined patch for 1147, 1202 and 1203, which should be simpler to apply. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: SDOAPITest.php, Tuscany-1147.patch, Tuscany-1147.patch, > Tuscany-1147.patch, Tuscany-combined.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()
[ https://issues.apache.org/jira/browse/TUSCANY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1202: -- Attachment: Tuscany-1202.patch I'm not convinced that it's worth the trouble of caching the changesummaryobject, given the problems it causes. This patch eliminates the cache, calculating the changesummaryobject by walking up the containment tree when necessary instead. > AccessViolation in DataObjectImpl::logDeletion() > > > Key: TUSCANY-1202 > URL: https://issues.apache.org/jira/browse/TUSCANY-1202 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: PHP >Reporter: Caroline Maynard > Attachments: Tuscany-1202.patch > > > Like Tuscany 1147, this problem is seen running the SDOAPITest PHPUNIT > testcase. The scenario is the same, but this time ChangeLogging type objects > exist in the tree (note that Logging does not need to be turned on to see the > problem). As with 1147, the problem is seen when the code using Tuscany holds > references to objects at different levels in the tree, such that they are > held after the root object no longer exists. > It's the standard company->departments->employees setup. When the company is > dropped, the Tuscany code does reset the container and the applicable change > summary for the department. But it doesn't drill down and do the same for the > employee. The consequence is that the employee still has a changesummary > pointer to the company's changesummary. When that gets referenced, in this > testcase when unsetting the employee from the department, the changesummary > value is tested and an AccessViolation occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
[
https://issues.apache.org/jira/browse/TUSCANY-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1203:
--
Attachment: Tuscany-1203.patch
My solution is to check the property value as well as the property index.
It might be better to work out why unset() sometimes doesn't remove the
property. This way works, though.
> Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
> --
>
> Key: TUSCANY-1203
> URL: https://issues.apache.org/jira/browse/TUSCANY-1203
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: PHP
>Reporter: Caroline Maynard
> Attachments: Tuscany-1203.patch
>
>
> This one occurs when deleting a DataObject which has several open properties.
> The logic in the destructor is:
> while (i != PropertyValues.end())
> {
> unsigned int pindx = (*i).first;
> DataObjectImplPtr dol = (*i).second;
> unset(pindx);
> i = PropertyValues.begin();
> if (i != PropertyValues.end() && (*i).first == pindx )
> {
> // unset has not removed the item from the list - do it
> // here instead
> PropertyValues.erase(i);
> i = PropertyValues.begin();
> }
> }
> However what happens in the unset() method is that if the property is open,
> undefineProperty() is called. This removes the open property and "shuffles
> up" the rest, so that a different property is assigned the property index
> pindx. Which means that even though the unset has removed the item from the
> list, the test (*).first==pindx passes, which results in the next property
> being removed from the list even though it has not yet been unset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
Yet another AccessViolation in DataObjectImpl::~DataObjectImpl
--
Key: TUSCANY-1203
URL: https://issues.apache.org/jira/browse/TUSCANY-1203
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: PHP
Reporter: Caroline Maynard
This one occurs when deleting a DataObject which has several open properties.
The logic in the destructor is:
while (i != PropertyValues.end())
{
unsigned int pindx = (*i).first;
DataObjectImplPtr dol = (*i).second;
unset(pindx);
i = PropertyValues.begin();
if (i != PropertyValues.end() && (*i).first == pindx )
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
i = PropertyValues.begin();
}
}
However what happens in the unset() method is that if the property is open,
undefineProperty() is called. This removes the open property and "shuffles up"
the rest, so that a different property is assigned the property index pindx.
Which means that even though the unset has removed the item from the list, the
test (*).first==pindx passes, which results in the next property being removed
from the list even though it has not yet been unset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()
AccessViolation in DataObjectImpl::logDeletion() Key: TUSCANY-1202 URL: https://issues.apache.org/jira/browse/TUSCANY-1202 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP Reporter: Caroline Maynard Like Tuscany 1147, this problem is seen running the SDOAPITest PHPUNIT testcase. The scenario is the same, but this time ChangeLogging type objects exist in the tree (note that Logging does not need to be turned on to see the problem). As with 1147, the problem is seen when the code using Tuscany holds references to objects at different levels in the tree, such that they are held after the root object no longer exists. It's the standard company->departments->employees setup. When the company is dropped, the Tuscany code does reset the container and the applicable change summary for the department. But it doesn't drill down and do the same for the employee. The consequence is that the employee still has a changesummary pointer to the company's changesummary. When that gets referenced, in this testcase when unsetting the employee from the department, the changesummary value is tested and an AccessViolation occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1201) AccessViolation in DataObjectImpl::logDeletion()
AccessViolation in DataObjectImpl::logDeletion() Key: TUSCANY-1201 URL: https://issues.apache.org/jira/browse/TUSCANY-1201 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, PHP 5.2.1 Reporter: Caroline Maynard Priority: Critical Problem observed when SDO A refers to SDO B. The reference to SDO A is dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in the SDODataObject destructor, in DataObjectImpl::clearReferences(). I believe this is because the reference was not properly cleared at the time of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1201) AccessViolation in DataObjectImpl::logDeletion()
[ https://issues.apache.org/jira/browse/TUSCANY-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1201. - Resolution: Invalid > AccessViolation in DataObjectImpl::logDeletion() > > > Key: TUSCANY-1201 > URL: https://issues.apache.org/jira/browse/TUSCANY-1201 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 > Reporter: Caroline Maynard >Priority: Critical > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-1147.patch OK, here's version 3. This one has the same code to fix the problem of the dangling reference. But it also deals with the problem mainfested in testcase b46617b. What's happening there (incidentally, that testcase was adapted from one of the PHP tests!) is that the employee of the month is also the CEO. Both CEO and EOTM are properties of the company type. When the company is discarded, it happens that the CEO property is unset first. Part of unsetting the CEO is to clear references, which include the EOTM. The code reenters the unset method, and the references array gets corrupted. My patch simply separates the loop for deleting the references from the loop for unsetting them, so avoids the corruption. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: SDOAPITest.php, Tuscany-1147.patch, Tuscany-1147.patch, > Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485502 ] Caroline Maynard commented on TUSCANY-1147: --- Sorry, there's a mistake in the test case I uploaded. The line unset($ron); should not be there. In fact it illustrates the point I was making in parentheses at the end of my previous comment - that if the employee is dropped first, the AccessViolation does not occur. It must be commented out to see the problem. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: SDOAPITest.php, Tuscany-1147.patch, Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[
https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caroline Maynard updated TUSCANY-1147:
--
Attachment: SDOAPITest.php
Here's an extremely stripped-down version of the test in question. It's just a
company with one employee, who is the EOTM (not much competition there). The
references are not dropped explicitly in the php source. Therefore what happens
is that when the function ends and the variables go out of scope, the php
runtime releases them. FIrst it (successfully) frees the company. Then it tries
to free the employee, which crashes like so:
commonj::sdo::DataObjectImpl::clearReferences() line 3410 + 58 bytes
commonj::sdo::DataObjectImpl::~DataObjectImpl() line 3270
commonj::sdo::DataObjectImpl::`scalar deleting destructor'(unsigned int
0x0001) + 37 bytes
commonj::sdo::RefCountingObject::releaseRef() line 71 + 56 bytes
commonj::sdo::RefCountingPointer::operator=(const
commonj::sdo::RefCountingPointer & {...}) line 148
sdo_do_object_free_storage(void * 0x020e81f0, void * * * 0x003d29b8) line 98 +
32 bytes
the failing line being the the one starting refs[i]->getDataObject below:
void DataObjectImpl::clearReferences()
{
for (unsigned int i=0;igetDataObject()->unset(refs[i]->getProperty());
delete refs[i];
}
refs.clear();
}
What my fix does is to make sure that when company->EOTM is unset, that the
reference is cleared at that time, and it does eliminate the crash.
(Note that if the DOs are destroyed in the right order, that is, if I
explicitly drop the $ron reference within the function, so that only the
company is left to be freed by the php runtime later, the problem does not
occur. But that's not what real users do ...)
> AccessViolation in DataObjectImpl::clearReferences()
>
>
> Key: TUSCANY-1147
> URL: https://issues.apache.org/jira/browse/TUSCANY-1147
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
> Environment: Win32, PHP 5.2.1
>Reporter: Caroline Maynard
>Priority: Critical
> Attachments: SDOAPITest.php, Tuscany-1147.patch, Tuscany-1147.patch
>
>
> Problem observed when SDO A refers to SDO B. The reference to SDO A is
> dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in
> the SDODataObject destructor, in DataObjectImpl::clearReferences().
> I believe this is because the reference was not properly cleared at the time
> of A's destruction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-1147.patch Here's the two-line fix, which should be an improvement on the previous one-line fix. I ran the tests and they worked for me. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1147.patch, Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Caching the types parsed from XSDs
Pete Robbins wrote: XSDHelperPtr myHelper = HelperProvider::getXSDHelper(); myHelper->defineTypes(wsdlHelper->getDefinedTypes()); which creates a new XSDHelper and DataFactory containing the Types and Properties from the wsdlHelper + all the schema information (which is held in the TypeDefinitions). Pete, that looks just what we need in the PHP implementation. The time taken to reload the schema gets us some grief - your proposal would allow us to parse the file just once and cache the results, which would be a great help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Caching the types parsed from XSDs
Pete Robbins wrote: XSDHelperPtr myHelper = HelperProvider::getXSDHelper(); myHelper->defineTypes(wsdlHelper->getDefinedTypes()); which creates a new XSDHelper and DataFactory containing the Types and Properties from the wsdlHelper + all the schema information (which is held in the TypeDefinitions). Pete, that looks just what we need in the PHP implementation. The time taken to reload the schema gets us some grief - your proposal would allow us to parse the file just once and cache the results, which would be a great help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-960) Spurious xsi:type="OpenDataObject" attribute generated
[ https://issues.apache.org/jira/browse/TUSCANY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-960. > Spurious xsi:type="OpenDataObject" attribute generated > -- > > Key: TUSCANY-960 > URL: https://issues.apache.org/jira/browse/TUSCANY-960 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Caroline Maynard > Assigned To: Pete Robbins >Priority: Minor > Fix For: Cpp-current > > > I have a schema where a property has an open data type. I read in an XML > document: > http://diveintomark.org/";> > http://www.w3.org/1999/xhtml";> > >[Update: The Atom draft is finished.] > > >Hello > > > > then I convert it back to a string, and it looks like this: > base="http://diveintomark.org/";>enhttp://diveintomark.org/ > > >[Update: The Atom draft is finished.] > > myclass >Hello > > > > The type attributes add no value and make the output cluttered and confusing. > Please eliminate them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-963) Spurious elements generated
[ https://issues.apache.org/jira/browse/TUSCANY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-963. > Spurious elements generated > --- > > Key: TUSCANY-963 > URL: https://issues.apache.org/jira/browse/TUSCANY-963 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Reporter: Caroline Maynard > Assigned To: Pete Robbins >Priority: Critical > Fix For: Cpp-current > > > I have a schema like so: > > http://www.w3.org/2005/Atom"; > xmlns="http://www.w3.org/2005/Atom"; > xmlns:xs="http://www.w3.org/2001/XMLSchema";> > http://www.w3.org/XML/1998/namespace"; > schemaLocation="xml.xsd" /> > http://www.w3.org/1999/xhtml"; > schemaLocation="xhtml1-strict.xsd" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > and a document like so: > > http://www.w3.org/2005/Atom"; > xmlns:tns="http://www.w3.org/2005/Atom"; > xml:base="blah" xml:lang="blah2" /> > I load the schema with XSDHelper::defineFile(), and then load the document > with XMLHelper::loadFile(). > Then I do a save() of the document. The output is: > > http://www.w3.org/2005/Atom"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:tns="http://www.w3.org/2005/Atom"; > base="blah" lang="blah2"> > blah > blah2 > > So not only do I have the lang and base attributes on , I get some > elements thrown in for free, too. > You'll notice that id is both sequenced and open. I'll find out if both these > conditions are necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1103) Won't compile with VC6
[ https://issues.apache.org/jira/browse/TUSCANY-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1103. - > Won't compile with VC6 > -- > > Key: TUSCANY-1103 > URL: https://issues.apache.org/jira/browse/TUSCANY-1103 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: WinXP, VC6 >Reporter: Caroline Maynard > Assigned To: Geoff Winn >Priority: Critical > Fix For: Cpp-current > > Attachments: Tuscany-1103.patch > > > Yes, I know the compiler of choice for Tuscany is now VC8. However the > compiler used by the automated Windows builds for PHP is VC6, and there are > issues preventing the PHP community from upgrading at present. Therefore, to > avoid diverging the code, it would be helpful if Tuscany could keep the code > compatible with VC6. > The issue we've fallen over is a well-known deficiency in VC6: > http://support.microsoft.com/kb/241569, where A is SDOTypeInfo and x is > MAX_TRANSIENT_SIZE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1133) Support the PHP extension under Windows
[ https://issues.apache.org/jira/browse/TUSCANY-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard resolved TUSCANY-1133. --- Resolution: Fixed Update has been committed. > Support the PHP extension under Windows > --- > > Key: TUSCANY-1133 > URL: https://issues.apache.org/jira/browse/TUSCANY-1133 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-current > Reporter: Caroline Maynard >Priority: Minor > Fix For: Cpp-current > > Attachments: Tuscany-1133.patch > > > I've been battling with getting this working under Windows, and attach a > patch with my latest efforts. Note that these changes work hand-in-hand with > corresponding changes to the Tuscany bindings for PHP SCA, which are already > in place in the AVOCET branch in the PECL repository. > On my Windows box with the patch installed, the PHP Calculator sample runs > clean, with no crashes on shutdown and no reported leaks of PHP memory. > I've also done quite a bit of tidying up, to make the inner workings a more > standard use of the PHP engine. In particular, I've broken out the big > php_eval_script() into its component parts, which makes it much easier to > debug. Unfortunately I haven't had time to refactor > SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at > present and could do with further prettying. I also hid the SCA_Tuscany > object handle from user space, because exporting the handle as a reference > was rather dangerous code. > One thing I haven't yet tackled is getting the thread context right for > reentrant paths through the extension. I've been investigating this, and I > think it's going to require saving a thread context in each of the mediator > objects, and restoring the correct one on invoke(). However what's there > seems to work OK in the simple environment of the PHP Calculator sample. > I'm out for a few days now - could someone give it a spin on *IX and make > sure that's still OK? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1166) Won't compile with VC6 (again)
[ https://issues.apache.org/jira/browse/TUSCANY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-1166. - > Won't compile with VC6 (again) > -- > > Key: TUSCANY-1166 > URL: https://issues.apache.org/jira/browse/TUSCANY-1166 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, MSVC++ 6 >Reporter: Caroline Maynard >Priority: Critical > Fix For: Cpp-current > > Attachments: Tuscany-1166.patch > > > Compilation error : > SDOXSDWriter.cpp > c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : > redefinition > NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2' > Stop. > This is another well-known problem with variable scope in VC6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-959) Please use thread-safe libraries
[ https://issues.apache.org/jira/browse/TUSCANY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard closed TUSCANY-959. Thanks > Please use thread-safe libraries > > > Key: TUSCANY-959 > URL: https://issues.apache.org/jira/browse/TUSCANY-959 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current > Reporter: Caroline Maynard >Priority: Minor > Fix For: Cpp-M3 > > Attachments: SAX2Parser.959 > > > One of our SDO for PHP users is planning to run in a multi-threaded web > server. > They have run an evaluation tool and only found one thread-safety issue - the > use of localtime() rather than localtime_r() in commonj/sdo/SDODate.cpp. > Please would you modify this call accordingly? It's fine for this to be a > conditional compile if you prefer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++
The news is all good. Both problems were in the PHP SDO testcases, and were showed up now that Tuscany's support for adding properties to a data object through the sequence interface is fixed. Sorry for the noise. On 21/03/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > Just wanted quickly to report that I've updated my local copy of the > PHP > > extension for SDO to Tuscany revision level 520962, and I am seeing > two > > regressions in previously working testcases. I don't have enough > evidence > > yet to say if these are Tuscany issues or errors introduced in the PHP > side, > > but FWIW, one of them getting a > > > > SDO_UnsupportedOperationException: Sequence::add of property which > already > > exists in sequence > > > > when working with Sequences of Open types, and the other is occurring > in a > > ChangeSummary test. I'll update the list as soon as I can with more > detail. > > -- Caroline
Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++
I've now gone back to 519688 and there were no files changed in the sdo part of the tree, so the failures don't result from a post-M3 change. The last level we shipped in a PHP release was 495327, and I know these tests worked then. I have had some intermediate levels working since, but I can't be completely sure what levels they were. On 21/03/07, Pete Robbins <[EMAIL PROTECTED]> wrote: On 21/03/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: > Just wanted quickly to report that I've updated my local copy of the PHP > extension for SDO to Tuscany revision level 520962, and I am seeing two > regressions in previously working testcases. I don't have enough evidence > yet to say if these are Tuscany issues or errors introduced in the PHP side, > but FWIW, one of them getting a > > SDO_UnsupportedOperationException: Sequence::add of property which already > exists in sequence > > when working with Sequences of Open types, and the other is occurring in a > ChangeSummary test. I'll update the list as soon as I can with more detail. > > -- > Caroline > FYI the M3 release is at revision 519688. What was your previous working revision? -- Pete -- Caroline
Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++
Just wanted quickly to report that I've updated my local copy of the PHP extension for SDO to Tuscany revision level 520962, and I am seeing two regressions in previously working testcases. I don't have enough evidence yet to say if these are Tuscany issues or errors introduced in the PHP side, but FWIW, one of them getting a SDO_UnsupportedOperationException: Sequence::add of property which already exists in sequence when working with Sequences of Open types, and the other is occurring in a ChangeSummary test. I'll update the list as soon as I can with more detail. -- Caroline
Re: Native M3 Release Candidate
Would you please include my patch for https://issues.apache.org/jira/browse/TUSCANY-1166? AFAIK this is not contentious. -- Caroline
[SDO C++] compilation error
After getting up to date, I'm seeing:
SequenceImpl.cpp
c:\dev\pecl\sdo\commonj\sdo\sequenceimpl.h(344) : error C4716:
'commonj::sdo::SequenceImpl::seq_item::operator=' : must return a value
NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2'
Stop.
Now the code in question is
// Copy assignment
seq_item& operator=(const seq_item& sin)
{
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
}
which indeed doesn't return a value. I'm just puzzled why this is only
happening to me. I would raise a JIRA, but it doesn't seem like a VC6
problem, and I can't see why else it would be different.
--
Caroline
[jira] Updated: (TUSCANY-1166) Won't compile with VC6 (again)
[ https://issues.apache.org/jira/browse/TUSCANY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1166: -- Priority: Critical (was: Major) > Won't compile with VC6 (again) > -- > > Key: TUSCANY-1166 > URL: https://issues.apache.org/jira/browse/TUSCANY-1166 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, MSVC++ 6 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1166.patch > > > Compilation error : > SDOXSDWriter.cpp > c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : > redefinition > NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2' > Stop. > This is another well-known problem with variable scope in VC6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1166) Won't compile with VC6 (again)
[ https://issues.apache.org/jira/browse/TUSCANY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1166: -- Attachment: Tuscany-1166.patch Workaround for VC6 variable scope problem. > Won't compile with VC6 (again) > -- > > Key: TUSCANY-1166 > URL: https://issues.apache.org/jira/browse/TUSCANY-1166 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, MSVC++ 6 >Reporter: Caroline Maynard > Attachments: Tuscany-1166.patch > > > Compilation error : > SDOXSDWriter.cpp > c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : > redefinition > NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2' > Stop. > This is another well-known problem with variable scope in VC6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1166) Won't compile with VC6 (again)
Won't compile with VC6 (again) -- Key: TUSCANY-1166 URL: https://issues.apache.org/jira/browse/TUSCANY-1166 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, MSVC++ 6 Reporter: Caroline Maynard Compilation error : SDOXSDWriter.cpp c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : redefinition NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2' Stop. This is another well-known problem with variable scope in VC6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476960 ] Caroline Maynard commented on TUSCANY-1147: --- My bad. It wasn't intuitive to me :-) By drop, I mean, cause the reference count to decrement to zero. In the case of the PHP impl, by setting the referring pointer to NULL. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476934 ] Caroline Maynard commented on TUSCANY-1147: --- That doesn't surprise me too much, there seems to be quite a network of these dependencies, which will all creep out one by one as we break down the previous one. Obviously I don't know what you have at 0xb46617b (!) so I can't guess what you're seeing. Would you agree with the fix by inspection? If you want to try it, the scenario is the classic company->departments->employees, where company->employeeOfTheMonth is a reference to one of the employees. So first drop the company, while still holding a reference to the employee, then drop the employee. Bang. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Priority: Critical (was: Major) > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 > Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-1147.patch Attached is a patch which resolves this issue for me. Note that the size of the patch is not proportional to the effort expended in producing it. Although this appears to fix the scenario I described, there are more complex scenarios involving many-valued properties which are still failing. I will investigate further. > AccessViolation in DataObjectImpl::clearReferences() > > > Key: TUSCANY-1147 > URL: https://issues.apache.org/jira/browse/TUSCANY-1147 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Win32, PHP 5.2.1 > Reporter: Caroline Maynard > Attachments: Tuscany-1147.patch > > > Problem observed when SDO A refers to SDO B. The reference to SDO A is > dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in > the SDODataObject destructor, in DataObjectImpl::clearReferences(). > I believe this is because the reference was not properly cleared at the time > of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
AccessViolation in DataObjectImpl::clearReferences() Key: TUSCANY-1147 URL: https://issues.apache.org/jira/browse/TUSCANY-1147 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, PHP 5.2.1 Reporter: Caroline Maynard Problem observed when SDO A refers to SDO B. The reference to SDO A is dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in the SDODataObject destructor, in DataObjectImpl::clearReferences(). I believe this is because the reference was not properly cleared at the time of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SCA PHP Extension patches
I had attached it to my post, and it appeared to get through OK for me, but perhaps not for others. So I've now raised https://issues.apache.org/jira/browse/TUSCANY-1133 and attached it to that. On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote: I can't find the JIRA that you attached the patch to. Can you point me in the right direction? -- Caroline
[jira] Updated: (TUSCANY-1133) Support the PHP extension under Windows
[ https://issues.apache.org/jira/browse/TUSCANY-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1133: -- Attachment: Tuscany-1133.patch > Support the PHP extension under Windows > --- > > Key: TUSCANY-1133 > URL: https://issues.apache.org/jira/browse/TUSCANY-1133 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-current > Reporter: Caroline Maynard >Priority: Minor > Fix For: Cpp-current > > Attachments: Tuscany-1133.patch > > > I've been battling with getting this working under Windows, and attach a > patch with my latest efforts. Note that these changes work hand-in-hand with > corresponding changes to the Tuscany bindings for PHP SCA, which are already > in place in the AVOCET branch in the PECL repository. > On my Windows box with the patch installed, the PHP Calculator sample runs > clean, with no crashes on shutdown and no reported leaks of PHP memory. > I've also done quite a bit of tidying up, to make the inner workings a more > standard use of the PHP engine. In particular, I've broken out the big > php_eval_script() into its component parts, which makes it much easier to > debug. Unfortunately I haven't had time to refactor > SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at > present and could do with further prettying. I also hid the SCA_Tuscany > object handle from user space, because exporting the handle as a reference > was rather dangerous code. > One thing I haven't yet tackled is getting the thread context right for > reentrant paths through the extension. I've been investigating this, and I > think it's going to require saving a thread context in each of the mediator > objects, and restoring the correct one on invoke(). However what's there > seems to work OK in the simple environment of the PHP Calculator sample. > I'm out for a few days now - could someone give it a spin on *IX and make > sure that's still OK? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1133) Support the PHP extension under Windows
Support the PHP extension under Windows --- Key: TUSCANY-1133 URL: https://issues.apache.org/jira/browse/TUSCANY-1133 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor Fix For: Cpp-current I've been battling with getting this working under Windows, and attach a patch with my latest efforts. Note that these changes work hand-in-hand with corresponding changes to the Tuscany bindings for PHP SCA, which are already in place in the AVOCET branch in the PECL repository. On my Windows box with the patch installed, the PHP Calculator sample runs clean, with no crashes on shutdown and no reported leaks of PHP memory. I've also done quite a bit of tidying up, to make the inner workings a more standard use of the PHP engine. In particular, I've broken out the big php_eval_script() into its component parts, which makes it much easier to debug. Unfortunately I haven't had time to refactor SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at present and could do with further prettying. I also hid the SCA_Tuscany object handle from user space, because exporting the handle as a reference was rather dangerous code. One thing I haven't yet tackled is getting the thread context right for reentrant paths through the extension. I've been investigating this, and I think it's going to require saving a thread context in each of the mediator objects, and restoring the correct one on invoke(). However what's there seems to work OK in the simple environment of the PHP Calculator sample. I'm out for a few days now - could someone give it a spin on *IX and make sure that's still OK? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SCA PHP Extension patches
I've been battling with getting this working under Windows, and attach a patch with my latest efforts. Note that these changes work hand-in-hand with corresponding changes to the Tuscany bindings for PHP SCA, which are already in place in the AVOCET branch in the PECL repository. On my Windows box with the patch installed, the PHP Calculator sample runs clean, with no crashes on shutdown and no reported leaks of PHP memory. I've also done quite a bit of tidying up, to make the inner workings a more standard use of the PHP engine. In particular, I've broken out the big php_eval_script() into its component parts, which makes it much easier to debug. Unfortunately I haven't had time to refactor SCA_TuscanyWrapper::invoke() subsequently, so it is rather a long sprawl at present and could do with further prettying. I also hid the SCA_Tuscany object handle from user space, because exporting the handle as a reference was rather dangerous code. One thing I haven't yet tackled is getting the thread context right for reentrant paths through the extension. I've been investigating this, and I think it's going to require saving a thread context in each of the mediator objects, and restoring the correct one on invoke(). However what's there seems to work OK in the simple environment of the PHP Calculator sample. I'm out for a few days now - could someone give it a spin on *IX and make sure that's still OK? On 07/02/07, Simon Laws <[EMAIL PROTECTED]> wrote: I've just checked in some changes to the VC project on windows which will hopefully work for you now. I've also updated the build for the PHP Calculator sample. Having said this I can't get it to run on my windows box. As I've said before I'm a bit suspicious of my windows configuration but I'm not getting the same error as before so it's likely that ithis is a real problem with the PHP Extension code. Would still be useful to know if you see a failure in the PHP engine code also. -- Caroline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-547) Discriminated types
On 09/02/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: Next, I'm seeing quite a few access violations. Investigating ... After much fretting about reference-couting pointers, a completely clean build sorted those out. I'm left with only one problem from running the PHP tests, which is very impressive considering the scope of the updates. I'll characterise the problem and report back. -- Caroline
Re: [jira] Updated: (TUSCANY-547) Discriminated types
On 08/02/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: Geoff, sorry I hadn't responded to this sooner, but I was working on a release of SCA and SDO for PHP and didn't want to pick up your latest code at that point. The release is done now, so I'll give the new stuff a whirl and see how it goes. Looks like it's now in HEAD, right? First trouble was that it didn't compile for me. I've raised http://issues.apache.org/jira/browse/TUSCANY-1103 for this. Next, I'm seeing quite a few access violations. Investigating ... -- Caroline
[jira] Updated: (TUSCANY-1103) Won't compile with VC6
[ https://issues.apache.org/jira/browse/TUSCANY-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1103: -- Attachment: Tuscany-1103.patch Of course I meant A is DataTypeInfo in the above. I've attached the patch that fixes this for me. I actually moved the constant into SDODataConverter, because that is the only place where it's used, and it was simpler to do so. YMMV. > Won't compile with VC6 > -- > > Key: TUSCANY-1103 > URL: https://issues.apache.org/jira/browse/TUSCANY-1103 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: WinXP, VC6 >Reporter: Caroline Maynard >Priority: Critical > Attachments: Tuscany-1103.patch > > > Yes, I know the compiler of choice for Tuscany is now VC8. However the > compiler used by the automated Windows builds for PHP is VC6, and there are > issues preventing the PHP community from upgrading at present. Therefore, to > avoid diverging the code, it would be helpful if Tuscany could keep the code > compatible with VC6. > The issue we've fallen over is a well-known deficiency in VC6: > http://support.microsoft.com/kb/241569, where A is SDOTypeInfo and x is > MAX_TRANSIENT_SIZE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1103) Won't compile with VC6
Won't compile with VC6 -- Key: TUSCANY-1103 URL: https://issues.apache.org/jira/browse/TUSCANY-1103 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: WinXP, VC6 Reporter: Caroline Maynard Priority: Critical Yes, I know the compiler of choice for Tuscany is now VC8. However the compiler used by the automated Windows builds for PHP is VC6, and there are issues preventing the PHP community from upgrading at present. Therefore, to avoid diverging the code, it would be helpful if Tuscany could keep the code compatible with VC6. The issue we've fallen over is a well-known deficiency in VC6: http://support.microsoft.com/kb/241569, where A is SDOTypeInfo and x is MAX_TRANSIENT_SIZE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [ANNOUNCEMENT] SCA_SDO-1.1.2 (stable) Released.]
FYI - a point release of the SCA and SDO extensions for PHP. Original Message Subject: [ANNOUNCEMENT] SCA_SDO-1.1.2 (stable) Released. Date: 7 Feb 2007 10:20:43 - From: PECL Announce <[EMAIL PROTECTED]> To: PECL developers list <[EMAIL PROTECTED]> Newsgroups: gmane.comp.php.pecl.devel The new PECL package SCA_SDO-1.1.2 (stable) has been released at http://pecl.php.net/. Release notes - Fix for bug #9845 - Relational DAS is failing when one parent and two children Changed from namespaceURI.type to namespaceURI#type (conform to spec) Update to Apache Tuscany C++ SDO revision level 495327 (namespace fixes, performance improvements) Package Info - Service Data Objects (SDOs) enable PHP applications to work with data from different sources (like a database query, an XML file, or a spreadsheet) using a single interface. SCA for PHP allows a PHP programmer to write reusable components (classes) in PHP, which can be called either locally, or remotely via Web Services, with an identical interface. Related Links - Package home: http://pecl.php.net/package/SCA_SDO Changelog: http://pecl.php.net/package-changelog.php?package=SCA_SDO Download: http://pecl.php.net/get/SCA_SDO-1.1.2.tgz Authors ----- Caroline Maynard <[EMAIL PROTECTED]> (lead) Graham Charters <[EMAIL PROTECTED]> (lead) Matthew Peters <[EMAIL PROTECTED]> (lead) Simon Laws (lead) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-547) Discriminated types
Geoff, sorry I hadn't responded to this sooner, but I was working on a release of SCA and SDO for PHP and didn't want to pick up your latest code at that point. The release is done now, so I'll give the new stuff a whirl and see how it goes. Looks like it's now in HEAD, right? Geoff Winn (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn updated TUSCANY-547: --- Attachment: TUSCANY-SDOValue.patch The attached patch is a first draft of a sizeable revision of SDO to eliminate a good deal of macro code. This particular patch will not be applied to the repository (since it hasn't been tried on Linux yet, for example) but if anyone would like to try it then I'd appreciate the feedback. In theory the external behaviour of SDO hasn't changed. in practice there are bound to be a few places where things hav ealtered a bit, the areas most at risk are a) Exceptions thrown in case of problems may occur at different points, so from a users point of view may be thrown sooner or later than expected. b) Data conversions may not be identical. I'll fix any of these that we find. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Fri, 05 Jan 2007 02:50:01 -0800 Excellent. Thank you. I've applied that patch. Works for me, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
On 04/01/07, Geoffrey Winn <[EMAIL PROTECTED]> 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
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 * 0x) line 436 + 17 bytes commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x) line 1318 + 17 bytes commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88, unsigned char 0x00, const void * 0x) 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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 * 0x) line 436 + > 17 > bytes > commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x) line > 1316 > + 17 bytes > commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0, > unsigned char 0x00, const void * 0x) 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) 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Caroline > > -- Yang ZHONG -- Caroline
