SDO for PHP
Readers of this list may be interested to know that the first stable release of SDO for PHP recently shipped on the PHP Extension Community Library: http://pecl.php.net/package/sdo This project uses the Tuscany SDO for C++ library internally, but presents a native PHP interface. -- Caroline Maynard
Re: [C++] Options for string handling in SDO
Just to emphasise that point, the SDO for PHP implementation depends on the C-style string interfaces in Tuscany C++. It already has to copy strings from Tuscany to the internal PHP format for string data, so another level of indirection would be most unwelcome. I imagine that other wrappers for Tuscany C++ might have the same issue. Simon Laws [EMAIL PROTECTED] wrote on 12/05/2006 15:53:26: Also why is this an either/or? It would seem like a useful thing to have an interface that allows string objects to be used but not sure I would want to loose the ability to use C strings as well. -- Caroline
Re: [SDO C++] Representing strings as objects rather than C style character pointers
At the risk of repeating myself, my major concern is with avoiding unnecessary copying of the data. So, if you feel the need to change the APIs as a one-off, well, I can live with that - at this stage of development I don't expect you to support old APIs for ever. But I really don't want to have to allocate memory for a temporary copy of the data in order to pass it into the PHP engine. Working within the PHP engine, we're fairly constrained as to how we manipulate strings - if you're interested to see how the PHP SDO implementation uses the C++ APIs, take a peek at http://cvs.php.net/pecl/sdo . Most of the internal interfaces to the PHP engine require either a null-terminated char* or a non-terminated char* and a length. -- Caroline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update on cross language interop testing
I'm confused about this proposal. Didn't you say earlier that the php tests would be added to the PECL repository? In which case the logical place would be pecl/sdo/tests/interop/. But (I'm guessing) your tuscanyphp directory is in the Apache repository. And why is it tuscanyphp/ and not tuscany/php/ like the other languages? Ok, Ant, that sounds like a good compromise. So we have two copies of the common resources 1/ tuscany/interop/resources 2/ tuscanyphp/sdo-1.0.1/tests/interop The test programs themselves live in test directories under the appropriate projects. I'm just refactoring the XSD/XML files a little so when they are done I'll raise a JIRA and attach patches. Anyone else have a view? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany blog
Sorry if I'm being dense, but I can't see a feed URL. Ok we've http://apache-tuscany.blogspot.com/ ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++ SDO] Results from PHP testing
I tried building the M1 candidate in the PHP environment on Windows, with the following observations and issues: One backward-compatibility compilation problem: Type::SDOTypeNamespaceURI has been changed from a const char * to a const SDOString. This is easy enough to program round, but it seems unnecessary. Can this be reversed? One crash: See http://issues.apache.org/jira/browse/TUSCANY-529 One infrastructure comment: the runtime version is declared as 0.9.3, and has been for rather a long time. Shouldn't this be updated more regularly, in particular whenever API incompatibilities are introduced? This would make it easier to manage the code. Once I'd bypassed the two problems above, the PHP tests ran through OK, so it's looking promising. Now for some more platforms - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++ SDO] Results from PHP testing
Edward Slattery [EMAIL PROTECTED] wrote on 10/07/2006 21:20:25: thankyou for that. The crash is something which we need to fix, and I will apply your change asap. I guess it probably wouldnt stop a release, but if we are re-spinning for any other reason I will make sure its in there. OK I think with the SDOString it was intended that we put in place a cast operator so that current users of the const char* would be unaffected. Would you consider directly casting the value to a (const char*) as an acceptable alternative? Yes, that would be fine. As things stand I have to invoke c_str(), which is not so neat. You are right, I forgot to update the release version number - and it should be updated with the SDOString stuff . Will update that at the same time. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Tuscany C++ Milestone 1 Release
The Apache Tuscany community is pleased to announce its first C++ milestone release. -- Pete Congratulations! We hope to follow this up soon with a PHP SDO release exploiting the latest C++ code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO for PHP release 1.0.3 has shipped using Tuscany C++ SDO
We've just shipped this new release of SDO for PHP, based on the Tuscany C++ SDO M1 release. This is the first time the PHP implementation has used the Tuscany code, and it's looking good. Thanks, guys! Original Message Subject: [ANNOUNCEMENT] sdo-1.0.3 (stable) Released. Date: 9 Aug 2006 10:54:01 - From: [EMAIL PROTECTED] (PECL Announce) To: PECL developers list [EMAIL PROTECTED] Newsgroups: php.pecl.dev The new PECL package sdo-1.0.3 (stable) has been released at http://pecl.php.net/. Release notes - Compatibility with Tuscany C++/SDO M1 release and some bug fixes over 1.0.2 - Update the base C++/SDO implementation to be the Tuscany CPP Milestone 1 release: cpp-0.1.incubating-M1 - Tested with Linux AMD 64-bit architecture - new 3-argument version of SDO_DAS_XML::createDocument() allows an SDO_DAS_XML_Document to be created from an SDO - fix defect 7878 Silent failure with malformed SQL - fix defect 7879 Improve error message in SDO_DAS_Relational_DatabaseHelper:executeStatement - fix defect 8280 Remove spaces from source files - fix defect 8300 Optimistic concurrency failure - fix defect 8374 Exception hierarchy (temporary fix) 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. Related Links - Package home: http://pecl.php.net/package/sdo Changelog: http://pecl.php.net/package-changelog.php?package=sdo Download: http://pecl.php.net/get/sdo-1.0.3.tgz Authors - Caroline Maynard [EMAIL PROTECTED] (lead) Graham Charters (lead) Matthew Peters [EMAIL PROTECTED] (lead) Simon Laws (lead) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Why is writeXSIType hard-coded?
There's a question about the behaviour of SDOXMLWriter::write(XMLDocumentPtr doc, int indent) over on the PHP SOA group: http://groups.google.co.uk/group/phpsoa/browse_frm/thread/e09432b81df0ae32 Does anyone know the answer? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
We'd be interested to make use of this feature in the PHP SDO project, too. I can see one possible workaround and one possible fix for this. The workaround is that you provide an xsd that defines just the root element giving it open content. In your case that would be something like xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=customer type=customerType/ xsd:complexType name=customerType xsd:sequence xsd:any namespace=##other processContents=lax/ /xsd:sequence /xsd:complexType /xsd:schema Then the root element has a type and will be processed normally, and everything it contains will be processed as open content. I tried this and it seems to work. The fix would be for me to hack the code so that when we find that a root element has no corresponding type (or possibly when there are no user defined types at all) then I could automagically create an open type for it. This would give the same behaviour as the previous case but spare you the need to provide the .xsd I'm inclined to just go ahead and do that since its not obviously any worse than the current behaviour but I'm open to other ideas. Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Leaking libxml memory
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
?xml version=1.0?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=courses
xsd:complexType
xsd:sequence
xsd:element name=course minOccurs=0
maxOccurs=unbounded
xsd:complexType
xsd:sequence
xsd:element name=title type=xsd:string/
xsd:element name=description
type=xsd:string/
xsd:element name=credits type=xsd:decimal/
xsd:element name=lastmodified
type=xsd:dateTime minOccurs=1/
/xsd:sequence
xsd:attribute name=cid type=xsd:ID/
/xsd:complexType
/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh-defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) ID
1 981 4 malloc() in none(0) xsd
2 971 3 malloc() in none(0) ID
3 968 4 malloc() in none(0) xsd
4 875 9 malloc() in none(0) dateTime
5 872 4 malloc() in none(0) xsd
6 861 9 malloc() in none(0) dateTime
7 858 4 malloc() in none(0) xsd
8 770 8 malloc() in none(0) decimal
9 767 4 malloc() in none(0) xsd
10756 8 malloc() in none(0) decimal
11753 4 malloc() in none(0) xsd
12677 7 malloc() in none(0) string
13674 4 malloc() in none(0) xsd
14663 7 malloc() in none(0) string
15660 4 malloc() in none(0) xsd
16584 7 malloc() in none(0) string
17581 4 malloc() in none(0) xsd
18570 7 malloc() in none(0) string
19567 4 malloc() in none(0) xsd
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ SCA and SDO M2 Release Candidate 1 now available
Andrew Borley [EMAIL PROTECTED] wrote on 12/10/2006 23:25:36: Hi everyone, I have posted candidates for the C++ SCA and SDO M2 release here: http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC1 Please take a look, read the docs, build run the libraries and samples let us know how you find it so that we can either re-spin the release or vote on it asap. I've updated the PHP code to use this without any major problems. Various compile errors as a result of new overloaded methods (XSDHelper::generate, XMLHelper::load) and String changes, but once these were all overcome, the tests ran clean. So it's all systems go from me. The changes are backward-compatible, so they are all checked in to PECL for any other PHPers who want to use M2 right away. If you do this, you'll need to hand-edit config.m4 / config.w32 to remove SDOString.cpp, because these files won't be updated until the version of the Tuscany code in PECL is refreshed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 2
Hi everyone, I have posted a 2nd candidate for the milestone 2 C++ release here: http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC2/ Andy, can you summarise the changes since RC1 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 2
FWIW, it's +1 from me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Thread safety ?
One of our SDO for PHP users is planning to run in a multi-threaded web server, and has asked us for a position on thread-safety. They have run an evaluation tool and only found one thread-safety issue - the use of localtime() rather than localtime_r() in in commonj/sdo/SDODate.cpp. So I intend to raise a JIRA to ask you to change that - this could be a conditional compile if you don't want to use the thread-safe libraries by default. However I expect you may have some more general thoughts about potential issues around thread-safety, which I would be interested to hear ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Root data object is null after serializing
I have a problem report from an SDO for PHP user which I'd like to discuss. You can read it at http://pecl.php.net/bugs/bug.php?id=9339, but here's what happens. The schema is: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; http://www.w3.org/2001/XMLSchema%22 targetNamespace=http://AnnotationTest; http://AnnotationTest%22 xs:element name=testTriggerEvent xs:complexType xs:sequence /xs:sequence /xs:complexType /xs:element /xs:schema We create a DataFactory and do a define using the above schema. Then use the DataFactory to create an XMLDocument of type testTriggerEvent. So the XMLDocument looks like: ?xml version=1.0 encoding=UTF-8? testTriggerEvent xmlns=http://AnnotationTest; xmlns:tns=http://AnnotationTest/ At this time we can do a XMLDocument::getRootDataObject() which returns a rather uninteresting SDO without any properties. Now we serialize the model (by doing getTypes() on the DataFactory and passing the result into XSDHelper::generate()), and the document. The serialized model comes out as: xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:sdo=commonj.sdo xmlns:sdoxml=commonj.sdo/xml xsd:element name=rootType type=RootType/ xsd:complexType name=RootType xsd:sequence xsd:element name=testTriggerEvent type=testTriggerEvent minOccurs=0/ /xsd:sequence /xsd:complexType xsd:element name=testTriggerEvent type=testTriggerEvent/ xsd:complexType name=testTriggerEvent/ /xsd:schema Then we propagate the serialized model and the document and attempt to unserialize it, by creating a DataFactory and using XSDHelper::define(), followed by XMLHelper::load() to reconstruct the XMLDocument. These apparently work OK, but then XMLDocument::getRootDataObject() returns null. This may seem like a pathological case, but there are sound reasons for doing it. I'm just not sure where the problem lies - is it the reconstruction of the XMLDocument, or is the serialized model wrong? Is there an alternative way to code the empty element which would get the desired outcome? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Root data object is null after serializing
Thanks, that was helpful. I've fixed up the serialization so that it pulls the URI from the type of the data object we're serializing, and it's now getting through OK. The generated schema looks much more appealing: xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:sdo=commonj.sdo xmlns:sdoxml=commonj.sdo/xml xmlns:tns=http://AnnotationTest; targetNamespace=http://AnnotationTest xsd:element name=testTriggerEvent type=testTriggerEvent/ xsd:complexType name=testTriggerEvent/ /xsd:schema I think this may be a regression, perhaps introduced with the string changes, because the php code hasn't changed for a while, and it has always passed in a NULL and the Right Thing used to happen. I hadn't considered that an XMLDocument might validly have no root data object, but I've put in a check for this in unserialize, and probably need one in some other places too. On 17/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Looks from the code that you have to specify the targetNamespace on the XSDHelper::generate() call (sorry about the wacky formatting in my first msg, btw. It was supposed to be plain text :-( ) -- Caroline
Re: [SDO C++] Thread safety ?
On 17/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote: As far as I know, the development of SDO to date has given zero consideration to running in a multithreaded environment. I am a little surprised that they were only able to identify one thread safety issue. The first one that occurs to me is - what happens if two or more threads are using the same data factory and one thread attempts to modify a data object that the other is deleting? Or - one thread adds a property to a type while the other is creating a data object of that type. Etc. Most likely your customer would dismiss these scenarios with something like oh, we will never do that, however, in general, SDO is not thread safe, and it will take a good deal of effort to make it so. I'm not aware of any major objection to using the thread safe libraries, however I am a little concerned that doing so may give the impression that SDO is thread safe when it absolutely isn't. I'm not too surprised to get that response. But remember, I didn't ask whether Tuscany SDO C++ would be thread-safe in some unknown and general scenario. We're talking about it running within the context of the PHP engine, where application programmers would not get the opportunity to share data between threads. The risk is that threads might interact accidentally because of static data in the library. So I think the scan does have some validity. -- Caroline
Re: [SDO C++] Thread safety ?
On 20/11/06, Caroline Maynard [EMAIL PROTECTED] wrote: There's a comment against that posting about exactly this situation, where an external library may or may not be thread-safe, and the answer is it depends. Of course we also depend on libxml2 as well as your implementation, but that is a well-trodden path for PHP extensions. FYI, the statement about libxml2 and thread-safety is here: http://xmlsoft.org/threads.html -- Caroline
SCA_SDO v1.1.0 for PHP released
The first formal release of SCA for PHP is now available. It has been combined with SDO for PHP as a single package in the PECL repository: http://pecl.php.net/SCA_SDO/. There's a more detailed change log on the project page. Thanks to the Tuscany C++ folk for some last-minute fixes! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] Is Type::OpenDataObjectType part of the API?
I've recently started seeing the value Type::OpenDataObjectType returned from a getTypeEnum(). I was a bit surprised to see this - I know it was introduced some months back internally to Tuscany, but my understanding was that it is not part of the API, or indeed of the specification. The circumstance is when an element which is not a known type is created in the graph. An attempt to introspect the model then results in this type being returned. For example, a schema like: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.org/test; xmlns:tns=http://www.example.org/test; complexType name=TestType mixed=true sequence element name=jim type=string/ any namespace=##any processContents=lax/ /sequence /complexType element name=test type=tns:TestType/ /schema and a document like: ?xml version=1.0 encoding=UTF-8? tns:test xmlns:tns=http://www.example.org/test; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.org/test cdata2.xsd jimjim_value/jim entryentry_value/entry /tns:test will provoke this problem when I try to get the type of entry. Unfortunately for me, the SDO for PHP code is littered with big switches whose discriminator is the TypeEnum, and the valid cases end with TextType :-( . I can go and revisit them all to add OpenDataObjectType, but first I'd like to understand whether it was your intention to expose this type to the user of the API, or if it is showing through where it shouldn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 29/11/06, Pete Robbins [EMAIL PROTECTED] wrote: This was introduced when opentype support was added. Is it needed? Don't know. What do you expect to be returned when you try to get the type of entry?? I've considered your question, and I can't see a valid alternative. I don't intend to surface it through the PHP APIs, because we can exploit dynamic typing there, but I'll go and fix up all my big switches to handle the OpenDataObjectType case. There is another aspect to this - when the document containing the open content is written out or serialized, it contains a lot of xsi:type=OpenDataObject attributes. I can't see any use for these, and they look fussy and complicated. Do you agree they can and should be eliminated? If so I'll raise a JIRA. Example input (where all the types are open): content type=xhtml xml:lang=en xml:base=http://diveintomark.org/;http://diveintomark.org/ div xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml p i[Update: The Atom draft is finished.]/i /p div class=myclass pHello/p /div /div /content example output: content type=xhtml lang=en base= http://diveintomark.org/;langen/langbasehttp://diveintomark.org//basehttp://diveintomark.org/ div xsi:type=OpenDataObject p xsi:type=OpenDataObject i xsi:type=OpenDataObject[Update: The Atom draft is finished.]/i /p div xsi:type=OpenDataObject class=myclass classmyclass/class p xsi:type=OpenDataObjectHello/p /div /div /content You'll no doubt notice a second problem with the output :-). I'll be raising a JIRA for that one too. -- Caroline
Re: [SDO C++] Thread safety ?
On 21/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote: As far as SDO itself is concerned, I think we would be OK if the user of SDO could guarantee that whenever an SDO artifact (data factory, data object, type, XSDHelper ...) is created then that artifact will be used _exclusively_ by the thread that created it. If that's acceptable to you then I'll check the code to ensure that my claim is correct. Yes, that's how it would be. The SDO for PHP implementation doesn't keep references to Tuscany objects in static data. As you observed earlier we will need to resolve the localtime issue. I'll raise a JIRA for that. Outside of SDO we will also need to check the various libraries that we depend on. You mentioned libxml2 but there is also zlib and iconv too. Based on a quick look at the libxml2 reference that you supplied we wll need a small change to the SDO build process but also possibly some code changes too. Both zlib and iconv are also part of the normal PHP environment, because libxml2 depends on them, so I don't expect issues with them. But FYI, zlib has a faq: http://www.zlib.net/zlib_faq.html#faq21 As for iconv, I think that libxml2 will use whatever iconv implementation it finds on the platform, which is not necessarily libiconv, so a general statement may not be possible. -- Caroline
Re: [SDO C++] Thread safety ?
This is now http://issues.apache.org/jira/browse/TUSCANY-959
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Ah a test!! Would it be that classs is serialized as both an attribute and an element?? Indeed. Not only class, but xml:base and xml:lang, too. I've opened http://issues.apache.org/jira/browse/TUSCANY-960 for the xsi:type=OpenDataObject issue. -- Caroline
Re: [SDO C++] Thread safety ?
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Do you think that we should build with the thread safe libs by default? or have 2 bin libraries one thread safe, one not but faster? The question applies to both Linux and Windows, and I'm not sure but we may have different answers for different systems. This isn't important for the PHP implementation, because we build the Tuscany code from source at present, so all we need is a compile switch. But in general, the expectation is that binaries are provided for Windows, but *IX users will build it themselves. Caroline, maybe I missed it in the email thread, but do your users need this on Linux? Windows? both? Both. Actually anywhere where they might be running an Apache HTTP Server with a threaded MPM and MOD_PHP. For example FreeBSD, Linux AMD_64 or Mac OS X, to name but a few. Have you considered how to maintain the status of the thread-safe variant as new code is added? -- Caroline
[SDO C++] WSDL generation failure
I just raised http://issues.apache.org/jira/browse/TUSCANY-962 to describe a problem that's occurring in the SCA for PHP implementation. This is a really hot one for the SCA team, because it's broken their SOAP bindings, so they would appreciate some attention to it. The regression occurred fairly recently, so I would expect that http://issues.apache.org/jira/browse/TUSCANY-920 or http://issues.apache.org/jira/browse/TUSCANY-919 is the culprit. However if we revert to a previous revision, we'll lose other fixes which are almost as important. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] WSDL generation failure
Thanks very much. On 01/12/06, Pete Robbins [EMAIL PROTECTED] wrote: Fix checked in. -- Caroline
Re: [C++] Who is working on which SDO problems
I created http://issues.apache.org/jira/browse/TUSCANY-963 for the attributes as elements problem. The WSDL problem was http://issues.apache.org/jira/browse/TUSCANY-962, which Pete has a fix for.
Re: [SDO C++] Thread safety ?
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: OK, I was asking because it seems more interesting to support threaded MPMs on Windows (as a threaded MPM is the default) than on Linux/Unix where I think the majority of people use forking/multi-process MPMs. So I was initially thinking of having the default binary distribution be multi-threaded on Windows and mono-threaded on Linux, but I'm interested in your input and what you've seen in terms of actual usage on both platforms. We know that, as you said, pretty much all options are possible on all platforms, and people are expecting binary distributions on Windows but in general build from source on Linux, but I'm looking for the right defaults... I would agree with those defaults for the binaries, provided there's no negative effects for the non-threaded Windows user. Have you considered how to maintain the status of the thread-safe variant as new code is added? What do you mean by maintain the status of the thread-safe variant? document it? continue to make sure that it works when adding new code? anything else? I meant the latter - with quite a few different people contributing code and patches, there's a likelihood that new thread-unsafe code may be introduced. -- Caroline
Re: [C++] SDO sequenced data objects
On 05/12/06, Pete Robbins [EMAIL PROTECTED] wrote: On 05/12/06, Simon Laws [EMAIL PROTECTED] wrote: The CopyHelper will have to copy the sequenced SDO by using the sequence API and then using the DataObject getter/setted methods to copy properties that were xml attributes. Can we remove this difference between sequences and DOs I don't understand this. Pete's describing the internal implementation of CopyHelper::copy(). This isn't stuff that the user would have to do. I think what you're asking for is that the copy function itself can either be: DataObjectPtr copy(DataObjectPtr dataObject); or SequencePtr copy(SequencePtr sequence); and that the created DO together with its Sequence would be the same regardless of the method signature? -- Caroline
Re: [C++] Who is working on which SDO problems
On 05/12/06, Pete Robbins [EMAIL PROTECTED] wrote: Which other SDO defects are holfing folk up? I just created http://issues.apache.org/jira/browse/TUSCANY-980. This is closely related to many of the issues discussed on this thread, but I don't think it's a dup.
Re: [C++] SDOXMLWriter not writing ns prefixes correctly
On 12/12/06, Pete Robbins [EMAIL PROTECTED] wrote: What namespace is the element return supposed to be in? In the first it is in tns2 and in the second the default namespace http://tempuri.org. What Types/Properties are defined in the DataFactory? I'll take a look at this. There have been a number of fixes in this area and each change breaks something else! It's likely this was the http://issues.apache.org/jira/browse/TUSCANY-962fix. Please make sure this scenario continues to work, as it's crucial for SOAP support.
Re: [C++] Who is working on which SDO problems
There's a lot of hard work gone into fixing all the problems we're seeing with sequenced and open types, which is much appreciated. Can we now discuss another set of problems we're seeing with the schema support, concerned with performance issues? Although you may not want to do much detailed work on performance at this stage, with a newish project like Tuscany, there are likely to be some low-hanging fruit which could make a lot of difference if picked off. Performance seems fine with simple schema, but more complex schema such as Atom are taking a surprisingly long time to load. Some of the reasons are apparently: - cyclic dependencies within the schema cause recursive type-checking. - schemas are loaded too many times. I think this is a problem exclusively in the way our code uses Tuscany, but I'll add it to this list in case you think Tuscany may be contributing to it too. - schemas once loaded are not cached. - Tuscany looks in too many places to find the schema, for example http://issues.apache.org/jira/browse/TUSCANY-907. I realise the spec is quite open in the area of how to interpret the schemaLocation value and what to do if it is missing, and perhaps some configuration options are needed here.
Re: [jira] Commented: (TUSCANY-959) Please use thread-safe libraries
When Tuscany is being used as a library under Apache and PHP or similar, libxml will already have been initialized, so please make this a compiler option to avoid xmlInitParser being called more than once. On 15/12/06, Geoff Winn (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-959?page=comments#action_12458823] Geoff Winn commented on TUSCANY-959: Item 4 is harder than I first thought. On Linux we can ensure that the initialisation routine is called exactly once by using pthread_once. However, Windows has no direct equivalent to that and we have to use the dllmain functionality instead to ensure that the xmlInitParser is called exactly once and before any thread uses SDO. I'm looking into this at the moment. We cannot use static initialisation because in general there is no way to know when such a variable will be initialised. For example, it is possible the initialisation will be attempted on a thread that then gets pre-empted by a second, and that thread executes a libxml2 operation before the initialisation has completed. I'll update this JIRA when I have more information. Please use thread-safe libraries Key: TUSCANY-959 URL: http://issues.apache.org/jira/browse/TUSCANY-959 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Caroline
Re: [C++] The saga of writing xml element namespace prefixes ...
Pete et al, The latest code from HEAD is still broken - it fails the http://issues.apache.org/jira/browse/TUSCANY-962 scenario. This is the #1 use case for SCA - we cannot use this latest code with PHP. -- Caroline
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
Thanks, we're OK to stick with the old level for now. I understood this thread to say that the latest version would work both for Sebastien's scenario and for the WSDL generation, but it seems I was confused. I'll keep waiting for the ultimate fix ... On 20/12/06, Pete Robbins [EMAIL PROTECTED] wrote: Yes I know and it will likely remain that way for some time as I'm on leave... I believe r485600 gives you the behaviour you want (though it is incorrect it just happens to work for your scenario) so I would recommend sticking with that until we can find a good solution. -- Caroline
Re: [jira] Commented: (TUSCANY-959) Please use thread-safe libraries
On 15/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Does it mean that we'll need two different SDO distributions? one for use inside Apache Httpd, another for use outside? What happens if we init Libxml multiple times? does it crash? is it a performance issue? does it break other components using Libxml in the same process? Is there a way to detect that Libxml is already initialized, instead of a compiler option? I've looked at the code, and it does have a simple check to make sure the code is only executed once. However there's no locking around it, so a race condition can occur if it is called on multiple threads. So, if Tuscany is being used as a library within an environment like httpd with PHP, where we know that xmlInitParser() will already have been called, you may feel free to call it as often as you wish, and it will make no difference. This question is discussed quite a bit on the libxml2 list: http://news.gmane.org/gmane.comp.gnome.lib.xml.general -- Caroline
Re: [SDO] Thread safety ?
On 14/12/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've just checked in the change for localtime, replacing it with localtime_r on Unix and localtime_s on Windows. Ah. Unfortunately this is a backward compatibility issues with MS compilers. localtime_s() does not exist in VC++ 6. But localtime() is deprecated in VC++ 8 in favour of localtime_s(). See http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f712f39b702000af ? Unless you intend to drop support for VC++ 6 users, you'll need to use a preprocessor macro, like _MSC_VER*, *to check which function to use. In case you're wondering how the PHP engine does this, it defines a macro php_localtime_r, which is always used internally in place of any localtime variant. This uses localtime_r, if it is available. If the system doesn't have localtime_r, then it uses localtime but adds its own locking around the call. It never invokes localtime_s. Gory details in http://cvs.php.net/viewvc.cgi/php-src/main/reentrancy.c. You may deduce from this that the best solution for me would be if you were to introduce, say, tuscany_localtime_r, to do whatever you want to do for your general user, and which I could then redefine to php_localtime_r. -- Caroline
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
It works for me! Sebastien? On 21/12/06, Pete Robbins [EMAIL PROTECTED] wrote: I have checked in a fix which I believe works for the PHP wsdl generation scenario and for our SCA samples. -- 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) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn resolved TUSCANY-990. Resolution: Fixed Fix Version/s: Cpp-current Patch applied. The standard tests now produce just 5 I/O warnings about failing to load an external entity. Avoid duplicated/infinite loading - Key: TUSCANY-990 URL: https://issues.apache.org/jira/browse/TUSCANY-990 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Yang ZHONG Fix For: Cpp-current Attachments: AvoidInfiniteLoading.990, AvoidInfiniteLoading.990 While working on http://issues.apache.org/jira/browse/TUSCANY-907 I've observed duplicated XSD loading. It could be infinite loading. I might have a way to avoid that. http://pecl.php.net/bugs/bug.php?id=9243 has the Test Case: 1. http://ping.chip.org/phr/xml/insurance.xsd imports http://ping.chip.org/phr/xml/types.xsd 2. http://ping.chip.org/phr/xml/insurance.xsd imports http://ping.chip.org/phr/xml/contact.xsd which also imports http://ping.chip.org/phr/xml/types.xsd I've observed http://ping.chip.org/phr/xml/types.xsd is loaded/parsed multiple times during loading http://ping.chip.org/phr/xml/insurance.xsd That impacts performance, especially types.xsd is remote. More deadly, that may cause infinite loading or stack overflow. Imagine A imports B which imports A, or X imports Y which imports Z which imports X. We can have a LoadingContext/ResourceSet to cache loaded/parsed resources, and reuse parsing results if a location/URI has been loaded/parsed already. 3-1. The LoadingContext/ResourceSet can be a Thread Local 3-2. The LoadingContext/ResourceSet can be explicitly passed into each parser 3-3. Currently ParserErrorSetter is explicitly passed into each parser, which can host the LoadingContext/ResourceSet Above has been discussed on thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html and Caroline has also requested this improvement ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Caroline -- Yang ZHONG -- Caroline
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] 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]
[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
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
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: [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: [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
[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
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
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: [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++
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: [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]
{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
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
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
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
[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]
[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]
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]
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: 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
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: [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]
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]
[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: [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]
[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: [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++] 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-setType('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]
[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]
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-setType('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]
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]
[jira] Created: (TUSCANY-529) Access violation in XMLHelperImpl::save
Access violation in XMLHelperImpl::save
---
Key: TUSCANY-529
URL: http://issues.apache.org/jira/browse/TUSCANY-529
Project: Tuscany
Type: Bug
Components: C++ SDO
Versions: Cpp-M1
Environment: WinXP
Reporter: Caroline Maynard
Occurs in the case where the root element URI and name are both null.
MSVCRTD! 00379060()
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::assign(const char * 0x) line 138 + 16 bytes
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::basic_stringchar,std::char_traitschar,std::allocatorchar (const char *
0x, const std::allocatorchar {...}) line 51 + 39 bytes
commonj::sdo::SDOString::SDOString(const char * 0x) line 53 + 51 bytes
commonj::sdo::SDOXMLWriter::write(commonj::sdo::RefCountingPointercommonj::sdo::XMLDocument
{...}, int 0x) line 124 + 52 bytes
commonj::sdo::XMLHelperImpl::save(commonj::sdo::RefCountingPointercommonj::sdo::XMLDocument
{...}, int 0x) line 256
commonj::sdo::XMLHelperImpl::save(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
{...}, const char * 0x, const char * 0x, int 0x) line
268 + 68 bytes
Here's a patch which worked for me. YMMV:
--- SDOXMLWriter.cpp2006-07-06 19:45:10.0 +0100
+++ /cygdrive/c/phpbuild/pecl/sdo/commonj/sdo/SDOXMLWriter.cpp 2006-07-10
11:56:57.664945600 +0100
@@ -121,15 +121,15 @@
{
elementURI = root-getType().getURI();
}
-SDOString elementName = doc-getRootElementName();
-if (elementName.empty())
+SDOXMLString elementName = doc-getRootElementName();
+if (elementName.isNull() || elementName.equals())
{
elementName = root-getType().getName();
elementName = elementName.toLower(0,1);
writeXSIType = true;
}
-writeDO(root, elementURI, elementName.c_str(), true, true);
+writeDO(root, elementURI, elementName, true, true);
}
rc = xmlTextWriterEndDocument(writer);
if (rc 0) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import
[SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import -- Key: TUSCANY-625 URL: http://issues.apache.org/jira/browse/TUSCANY-625 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M1 Reporter: Caroline Maynard Priority: Minor 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: xsd:import namespace=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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-641) Warning messages during compilation
Warning messages during compilation --- Key: TUSCANY-641 URL: http://issues.apache.org/jira/browse/TUSCANY-641 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: WinXP Reporter: Caroline Maynard Priority: Trivial It would be nice to eliminate the warning messages that are seen during the compilation of Tuscany SDO C++ for the SDO for PHP Windows libraries: PropertyImpl.cpp C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Nil' : identifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Nilrefs' : identifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ' : identifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::const_iterator' : identifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::iterator' : identifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Kfn,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue * ::_Node' : iPropertyList.cpp dentifier was truncated to '255' characters in the debug information C:\PROGRA~1\MICROS~2\VC98\INCLUDE\xmemory(34) : warning C4786: 'std::_Treestd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,commonj::sdo::DASValue *,std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,commonj::sdo::DASValue *,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorcommonj::sdo::DASValue
[jira] Created: (TUSCANY-705) XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true
XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true --- Key: TUSCANY-705 URL: http://issues.apache.org/jira/browse/TUSCANY-705 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: WinXP Reporter: Caroline Maynard Priority: Critical Attachments: bug8506.patch See http://pecl.php.net/bugs/bug.php?id=8506 for the test example. The schema is: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=http://ConvertedStockQuote; xs:element name=getQuote xs:complexType xs:sequence xs:element name=ticker type=xs:string nillable=true/ /xs:sequence /xs:complexType /xs:element /xs:schema When the ticker element's value is not nil, the output is: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; tickerIBM/ticker /getQuote but when it is nil, my user gets: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; getQuote xmlns=http://ConvertedStockQuote; xsi:nil=true/ /getQuote I've attached a proposed patch. I removed the namespace URI to be consistent with the non-nil case, apologies if this is incorrect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-759) XPath test failure with compound queries
XPath test failure with compound queries Key: TUSCANY-759 URL: http://issues.apache.org/jira/browse/TUSCANY-759 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: PHP 5.1.6, WinXP Reporter: Caroline Maynard Part of the SDO for PHP core unit tests uses a standard company-departments[]-employees[] model and tests Xpath expressions. All these tests worked with Tuscany C++ SDO revision level 431903. I recently ran them with 436761 and there was a failure. I then reverted to 433676 and the tests were successful. It's possible that the Tuscany-539 fix was the culprit. The failing test is attempting to read company[departments[name='ShoeDept']/employees[name='Jane Smith']] The values for name are both valid, but in the failing revision level an exception was thrown with the message Invalid path: followed by the xpath above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-907) Schema Import is noisy when schemaLocation is an abolute URI
Schema Import is noisy when schemaLocation is an abolute URI Key: TUSCANY-907 URL: http://issues.apache.org/jira/browse/TUSCANY-907 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Java-M1 Reporter: Caroline Maynard See http://pecl.php.net/bugs/bug.php?id=9243. SDO for PHP user is importing a schema with import statements like import namespace=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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-907) Schema Import is noisy when schemaLocation is an abolute URI
[ http://issues.apache.org/jira/browse/TUSCANY-907?page=all ] Caroline Maynard updated TUSCANY-907: - Attachment: Tuscany-907.patch Possible patch for Tuscany-907 Schema Import is noisy when schemaLocation is an abolute URI Key: TUSCANY-907 URL: http://issues.apache.org/jira/browse/TUSCANY-907 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Java-M1 Reporter: Caroline Maynard 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 import namespace=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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-950) CopyHelper::copy() forgets sequence information
CopyHelper::copy() forgets sequence information --- Key: TUSCANY-950 URL: http://issues.apache.org/jira/browse/TUSCANY-950 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-959) Please use thread-safe libraries
Please use thread-safe libraries Key: TUSCANY-959 URL: http://issues.apache.org/jira/browse/TUSCANY-959 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-960) Spurious xsi:type=OpenDataObject attribute generated
Spurious xsi:type=OpenDataObject attribute generated -- Key: TUSCANY-960 URL: http://issues.apache.org/jira/browse/TUSCANY-960 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor I have a schema where a property has an open data type. I read in an XML document: content type=xhtml xml:lang=en xml:base=http://diveintomark.org/; div xmlns=http://www.w3.org/1999/xhtml; p i[Update: The Atom draft is finished.]/i /p div class=myclass pHello/p /div /div /content then I convert it back to a string, and it looks like this: content type=xhtml lang=en base=http://diveintomark.org/;langen/langbasehttp://diveintomark.org//base div xsi:type=OpenDataObject p xsi:type=OpenDataObject i xsi:type=OpenDataObject[Update: The Atom draft is finished.]/i /p div xsi:type=OpenDataObject class=myclassclassmyclass/class p xsi:type=OpenDataObjectHello/p /div /div /content The type attributes add no value and make the output cluttered and confusing. Please eliminate them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-962) Incorrect namespace for open content
Incorrect namespace for open content
Key: TUSCANY-962
URL: http://issues.apache.org/jira/browse/TUSCANY-962
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Caroline Maynard
Priority: Blocker
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 service child object (type
http://schemas.xmlsoap.org/wsdl/#tService) on the root
- create a port child object (type http://schemas.xmlsoap.org/wsdl/#tPort) on
the service
- create an address 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 open dataObject 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:
?xml version=1.0 encoding=UTF-8?
definitions xmlns=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;
service
port
address xsi:type=tns2:tAddress location=http://example.com/
/port
/service
/definitions
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-963) Spurious elements generated
Spurious elements generated Key: TUSCANY-963 URL: http://issues.apache.org/jira/browse/TUSCANY-963 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Critical I have a schema like so: ?xml version=1.0 encoding=utf-8 ? xs:schema targetNamespace=http://www.w3.org/2005/Atom; xmlns=http://www.w3.org/2005/Atom; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:import namespace=http://www.w3.org/XML/1998/namespace; schemaLocation=xml.xsd / xs:import namespace=http://www.w3.org/1999/xhtml; schemaLocation=xhtml1-strict.xsd / xs:element name=content type=contentType minOccurs=0 / xs:complexType name=contentType mixed=true xs:sequence xs:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded / /xs:sequence xs:attribute name=type type=xs:string default=text / xs:attribute name=src type=xs:string / !-- uriType -- xs:attributeGroup ref=commonAttributes/ /xs:complexType xs:attributeGroup name=commonAttributes xs:attribute ref=xml:base / xs:attribute ref=xml:lang / xs:anyAttribute/ /xs:attributeGroup /xs:schema and a document like so: ?xml version=1.0 encoding=UTF-8? content xmlns=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: ?xml version=1.0 encoding=UTF-8? content xmlns=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 baseblah/base langblah2/lang /content So not only do I have the lang and base attributes on content, 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-963) Spurious elements generated
[ http://issues.apache.org/jira/browse/TUSCANY-963?page=comments#action_12454956 ] Caroline Maynard commented on TUSCANY-963: -- It's not necessary for the element to be open for this to occur, it's sufficient for it to be sequenced. Spurious elements generated --- Key: TUSCANY-963 URL: http://issues.apache.org/jira/browse/TUSCANY-963 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Critical I have a schema like so: ?xml version=1.0 encoding=utf-8 ? xs:schema targetNamespace=http://www.w3.org/2005/Atom; xmlns=http://www.w3.org/2005/Atom; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:import namespace=http://www.w3.org/XML/1998/namespace; schemaLocation=xml.xsd / xs:import namespace=http://www.w3.org/1999/xhtml; schemaLocation=xhtml1-strict.xsd / xs:element name=content type=contentType minOccurs=0 / xs:complexType name=contentType mixed=true xs:sequence xs:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded / /xs:sequence xs:attribute name=type type=xs:string default=text / xs:attribute name=src type=xs:string / !-- uriType -- xs:attributeGroup ref=commonAttributes/ /xs:complexType xs:attributeGroup name=commonAttributes xs:attribute ref=xml:base / xs:attribute ref=xml:lang / xs:anyAttribute/ /xs:attributeGroup /xs:schema and a document like so: ?xml version=1.0 encoding=UTF-8? content xmlns=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: ?xml version=1.0 encoding=UTF-8? content xmlns=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 baseblah/base langblah2/lang /content So not only do I have the lang and base attributes on content, 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-980) DataObject assigned into open property goes missing
DataObject assigned into open property goes missing --- Key: TUSCANY-980 URL: http://issues.apache.org/jira/browse/TUSCANY-980 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard I have a schema like so: schema xmlns=http://www.w3.org/2001/XMLSchema; element name=jungle complexType sequence any minOccurs=0 maxOccurs=unbounded/ /sequence /complexType /element element name=mixedJungle complexType mixed=true sequence any minOccurs=0 maxOccurs=unbounded/ /sequence /complexType /element /schema and another one like so: schema xmlns=http://www.w3.org/2001/XMLSchema; complexType name=snakeType sequence element name= name type=string/ element name= length type=positiveInteger / /sequence /complexType complexType name=bearType sequence element name= name type=string/ element name= weight type=positiveInteger / /sequence /complexType complexType name=pantherType sequence element name= name type=string/ element name= colour type=string / /sequence /complexType /schema 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: ?xml version=1.0 encoding=UTF-8? jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; bear xsi:type=bearType nameBaloo/name weight700/weight /bear panther xsi:type=pantherType nameBagheera/name colourinky black/colour /panther snake xsi:type=snakeType nameKaa/name length25/length /snake /jungle 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: ?xml version=1.0 encoding=UTF-8? jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; bear xsi:type=bearType name=Baloo weight=700/ panther xsi:type=pantherType name=Bagheera colour=inky black/ snake xsi:type=snakeType name=Kaa length=25/ /jungle 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: ?xml version=1.0 encoding=UTF-8? mixedJungle xmlns:xsi=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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-988) Xpath doesn't work with nested open properties
Xpath doesn't work with nested open properties
--
Key: TUSCANY-988
URL: http://issues.apache.org/jira/browse/TUSCANY-988
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Caroline Maynard
I'm using the same Jungle schema as before, but this time my bear type is
itself open. So the jungle is:
schema
xmlns=http://www.w3.org/2001/XMLSchema;
element name=jungle
complexType
sequence
any minOccurs=0 maxOccurs=unbounded/
/sequence
/complexType
/element
/schema
and the bear is:
schema xmlns=http://www.w3.org/2001/XMLSchema;
complexType name=bearType
sequence
any minOccurs=0 maxOccurs=unbounded/
element name= name type=string/
element name= weight type=positiveInteger /
/sequence
/complexType
/schema
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:
?xml version=1.0 encoding=UTF-8?
jungle xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
bear xsi:type=bearType
nameMummy Bear/name
weight700/weight
bear xsi:type=bearType
nameBaby Bear/name
weight100/weight
/bear
/bear
/jungle
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_stringchar,std::char_traitschar,std::allocatorchar
{0x01131b69 bear/bear}) line 3228 + 42 bytes
commonj::sdo::DataObjectImpl::getProperty(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
{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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [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]
[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-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]
[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-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]
[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] 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] 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] 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]
