Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++
I've downloaded the SDO src distribution on XP and it builds and runs as advertised. +1 from me. Geoff. On 20/03/07, ant elder [EMAIL PROTECTED] wrote: +1 ...ant On 3/16/07, Pete Robbins [EMAIL PROTECTED] wrote: Please vote to approve the release of milestone 3 of Tuscany SCA Native and Tuscany SDO C++. The SDO release includes performance improvements (30-40%) along with improvements to robustness. The SCA release includes support for C++, Python and Ruby languages and sca, webservice and REST bindings. The distribution artifacts are here: - linux and Mac OS X (source only) - http://people.apache.org/~robbinspg/M3-RC4/linux-macosx/ - windows (source and binary) - http://people.apache.org/~robbinspg/M3-RC4/win32/ The RAT tool output for the release artifacts is here: http://people.apache.org/~robbinspg/M3-RC4/ The SDO release is tagged here http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-sdo-1.0.incubating-M3-RC1/ The SCA release is tagged here http://svn.apache.org/repos/asf/incubator/tuscany/tags/native-sca-1.0.incubating-M3-RC4/ Thank you. -- Pete
[SDO for C++] SDO builds with MSVC++ 8 Professional
In case it becomes relevant, I've just built the C++ version of SDO using Microsoft Visual Studio 2005 Professional Edition (ie the one you have to pay for) and it works straight out of the box, with no modifications at all. I realise this is what we would hope for, but it's nice to get it confirmed. Geoff.
[SDO for C++] Design notes added to repository
For a while now I've been adding design notes for SDO to the Wiki ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/DesignNotes) whenever I came across something useful. I've updated that page to describe the re-write that I did a few weeks ago to eliminate a lot of C style macro code. I've also taken a copy of the page and added it to repository at sdo/doc/DesignNotes.htm as a backup copy. Geoff.
Re: SDO CTS: TUSCANY-1117
It is important. Please do upload it again and then I'll apply it. Regards, Geoff. On 22/02/07, Robbie Minshall [EMAIL PROTECTED] wrote: I intended to grant the licence. I am happy to leave it up there as is. If it is important to have the attachment with the ASF granted licence checked will upload it again and grant the licence. On 2/21/07, Geoffrey Winn [EMAIL PROTECTED] wrote: I'll take a look at this. Can I just check one thing. In the text of the JIRA there are two patches; one posted on 15-Feb and one posted 16-Feb but the more recent one does not have the ASF granted license. Do you really want that one deleted? Regards, Geoff. On 19/02/07, Robbie Minshall [EMAIL PROTECTED] wrote: Trying to get a feel as to when a commiter could take a look at TUSCANY-1117. If it is going to be a day or so then I will upload another update/patch in order to keep our source in sync with tuscany. If it can be looked at soon then great and I will avoid continued development within our own source env and consider moving to a development environment where the java/cts/sdo2.1 provides our primary source tree. thanks, Robbie -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
Re: Tuscany Native M3 release
I've changed my mind about changes to SDO that should be in M3. I've just checked in an alteration to Type::getProperties that is good for a 25% speed-up in the overall execution of SDO. (See TUSCANY-1136, r510951). I would like to see that included in M3. Regards, Geoff. On 19/02/07, Geoffrey Winn [EMAIL PROTECTED] wrote: Pete, There are no pending changes in SDO that we should wait for if you are looking to generate a candidate this week (week beginning 19-Feb). I will aim to complete as much as I can from 1078 (which may help resolve some php issues), 959 (which I am part way through) and 747 (load an XML document without a schema). I also think we should close 750 and 95. 750 describes schema validation and that is not likely to be done in advance of the spec group's conclusions. 95 describes the type safe interface, which again is unlikely to ever be done for C++. Regards, Geoff. On 16/02/07, Pete Robbins [EMAIL PROTECTED] wrote: On 16/02/07, Geoffrey Winn [EMAIL PROTECTED] wrote: On 15/02/07, Pete Robbins [EMAIL PROTECTED] wrote: I'll review the SCA Jiras and we can agree on which are must-fix for the release. Can someone review the SDO C++ Jiras and propose a list of must-fix? I'll do the JIRA review for SDO C++ Geoff. Thanks Geoff. Are there any features in the pipeline that should be in the M3 release? Assuming we cut a candidate next week is there anything we should wiat for? Cheers, -- Pete
Re: SDO CTS: TUSCANY-1117
I'll take a look at this. Can I just check one thing. In the text of the JIRA there are two patches; one posted on 15-Feb and one posted 16-Feb but the more recent one does not have the ASF granted license. Do you really want that one deleted? Regards, Geoff. On 19/02/07, Robbie Minshall [EMAIL PROTECTED] wrote: Trying to get a feel as to when a commiter could take a look at TUSCANY-1117. If it is going to be a day or so then I will upload another update/patch in order to keep our source in sync with tuscany. If it can be looked at soon then great and I will avoid continued development within our own source env and consider moving to a development environment where the java/cts/sdo2.1 provides our primary source tree. thanks, Robbie
Re: Tuscany Native M3 release
Pete, There are no pending changes in SDO that we should wait for if you are looking to generate a candidate this week (week beginning 19-Feb). I will aim to complete as much as I can from 1078 (which may help resolve some php issues), 959 (which I am part way through) and 747 (load an XML document without a schema). I also think we should close 750 and 95. 750 describes schema validation and that is not likely to be done in advance of the spec group's conclusions. 95 describes the type safe interface, which again is unlikely to ever be done for C++. Regards, Geoff. On 16/02/07, Pete Robbins [EMAIL PROTECTED] wrote: On 16/02/07, Geoffrey Winn [EMAIL PROTECTED] wrote: On 15/02/07, Pete Robbins [EMAIL PROTECTED] wrote: I'll review the SCA Jiras and we can agree on which are must-fix for the release. Can someone review the SDO C++ Jiras and propose a list of must-fix? I'll do the JIRA review for SDO C++ Geoff. Thanks Geoff. Are there any features in the pipeline that should be in the M3 release? Assuming we cut a candidate next week is there anything we should wiat for? Cheers, -- Pete
Re: Tuscany Native M3 release
On 15/02/07, Pete Robbins [EMAIL PROTECTED] wrote: I'll review the SCA Jiras and we can agree on which are must-fix for the release. Can someone review the SDO C++ Jiras and propose a list of must-fix? I'll do the JIRA review for SDO C++ Geoff.
Re: Content for next milestone
Does it do any actual harm to have a branch, even if not everyone thinks it's necessary? Presumably that gives the people that want stability a place to work and at worst they've bought themselves some extra work merging back into the main development stream later. My previous experience (3 major occasions) has been that code branches often turn out to be more trouble than they are worth, but just occasionally they can be the right answer. Geoff. On 08/02/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On 2/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Like Venkat I'm also looking for a more stable runtime environment. I want that stable environment to bring-up end to end scenarios, including Bigbank, variations of BigBank and Calculator similar to what we've been running with the C++ runtime, our integration test suite, and the new integration test cases that I want to add to cover the requirements on the Wiki. Right now I can't get even simple samples working with the trunk and we can't run any integration tests as the itest plugin does not even compile. I understand why the kernel is evolving so much and so quickly and this is good and exciting, but integrating all the pieces and making the fixes and improvements here and there to get the end to end story working is difficult enough... that we can't be distracted or broken all the time by the refactoring and ongoing changes in the trunk. So I think we need a branch to do this stabilization work, with the goal of having the scenarios and integration tests in place by March. I think that it will be good for the project if people interested in stabilizing and improving basic function can do it in a more stable environment while the kernel is getting refactored in parallel. When the trunk settles I'll be happy to synchronize with pieces of it, as long as the samples and integration tests work. I'll try to create the branch some time tomorrow morning (Thursday) PST. I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. If the issue here is that trunk is unstable, then we should stabilize trunk. None of the current samples will run against trunk because they are still using the 0.95 apis. I have updated kernel to use the 1.0 ones and I am in the process of implementing the proposal I made on the list on how to migrate the runtime. I could certainly use help migrating the samples and itests to 1.0. If the purpose of the stabilization branch is to prep for a release (like we did with M2), I would like to know what we are planning to release. There's a list of requirements on the wiki but we've not discussed those as a community at all. Most of them pertain to new functionality and I struggle to see how we can stabilize code that is not yet written. If the purpose is to implement new features, we have a place for that: trunk. Things like complex properties, XML ordering, contribution processing, and assembly changes are all kernel features and can all be implemented in the kernel's trunk without dependency on any runtime. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ getUserData method
Adriano, getUserData is not an alternative to getInteger (and similar). As best I can tell, it was added to allow people to add some user specific data to a data object. The data is supplied (in setUserData) as a void* so it really can be anything. This option exists for all data objects, regardless of their type. I believe the PHP SDO extension uses this mechanism so that every data object holds an identifier that points back to some corresponding PHP entity. Does that help? Regards, Geoff. On 30/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I'm trying to find out how the method void* DataObject::getUserData(const SDOString path) works. I thought it was the same as, for example, long DataObject::getInteger(const SDOString path): DataObject do; do.setInteger(id, 123); long id1 = do.getInteger(id); long* id2 = (long*) do.getUserData(id); I thought the id1 would be the equals id2. Am I misunderstanding the getUserData functionality? Adriano Crestani
Re: [SDO CTS] Anyone avail to commit TUSCANY-1048 TUSCANY-1081 ?
On 29/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Kelvin has been appling patches for us in the CTS, but he's quite tied up at the moment... can anyone else apply the patches for these two Jiras for us ? Once applied 300 SDO tests being run against Tuscany's SDO when you mvn the cts... hopefully a good start plenty more to come - with any luck Many thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dan, I've never worked on the Java implementation of SDO, however it would probably be a good idea if I had some exposure to it. If you can help me set up an environment where I can build and test your changes then I'll help out. I won't be offended if you get a better offer from someone who is already working on that stuff. Regards, Geoff.
Re: [C++] SDO Memory management
I'm interested in that. I'm re-writing most of DataObjectImpl currently, including the destructor so I may fix that one by accident. I've never encountered valgrind before so if you can help me get started with it I'll try to use it with SDO more regularly. Geoff. On 25/01/07, Simon Laws [EMAIL PROTECTED] wrote: Hi I note that there are serveral cases in SDO (as used during the model loading stage of the SCA CPPCalculator samples) where valgrind reports memory being deleted more that once. I have the example here and in my case the problem is in ~SAX2Parser ~DataObjectImpl ~SDORuntimeException Logger::LogArgs1() Logger::LogArgs2() I really thought these were are the root of my PHP extension problems but alas no. As I'm knee deep in trying to sort this at the moment so I'm not going to chase these any further at the moment but thought it best to warn people. I'll raise a suitable JIRA with just this info. If anyone wants to have a go pick an application that uses SDO and run it under valgrind. I should point out that, for me, Purify didn't report these errors on windows. I wouldn't read too much into that as I have so many other problems at the moment it's not clear actually what is going on. Regards Simon
How to update the Tuscany website?
Apologies if this has already been covered. I would like to update the FAQ page of the website ( http://incubator.apache.org/tuscany/faq.html, if that makes a difference). How do I do that? Is it enough to edit site/site-author/faq.xml or do I have to change anything else? Thanks in advance. Regards, Geoff.
Re: How to update the Tuscany website?
Venkat, Thank you for the offer. Normally I wouldn't be lazy and would get on and do the work, but it's only a small change, so I'll accept. I'd like to add the following as a third bullet point. * Does SDO for C++ provide a static interface as the Java implementation does? No. It is not clear that this is a useful feature in a language like C++ so we have no plans to implement it. Thank you for your help. Regards, Geoff. On 19/01/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Geoff, Since I have done this before I can help if you can simply provide the udpated faq.xml. I shall take care of building it to html and then updating the site. Let me know. - Venkat On 1/19/07, Andrew Borley [EMAIL PROTECTED] wrote: Hi Geoff, Take a look at http://svn.apache.org/repos/asf/incubator/tuscany/site/README.txt You need to edit the xml, regenerate the HTML from the XML, svn commit those changes and then log into people.apache.org and run an svn update there. It's a bit of a complex process - one that we should perhaps think about improving... Cheers Andy On 1/19/07, Geoffrey Winn [EMAIL PROTECTED] wrote: Apologies if this has already been covered. I would like to update the FAQ page of the website ( http://incubator.apache.org/tuscany/faq.html, if that makes a difference). How do I do that? Is it enough to edit site/site-author/faq.xml or do I have to change anything else? Thanks in advance. Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Simon Laws for Tuscany committer
+1 Actually, since he's also applied fixes to SDO for C++, am I allowed a +2? On 17/01/07, kelvin goodson [EMAIL PROTECTED] wrote: +1 On 17/01/07, ant elder [EMAIL PROTECTED] wrote: I'd like to nominate Simon Laws to become a Tuscany committer. Simon has has done lots of different things for Tuscany - patches, interop work, the website, release testing, participating in discussions etc, and he's been contributing to Tuscany since April last year! Here's my +1. ...ant
Re: SDO Java/C++
On 15/01/07, Frank Budinsky [EMAIL PROTECTED] wrote: DataObjectBase.java is the base class for static (generated) SDOs. I don't believe there is C++ static SDO support, so there is no equivalent in SDO C++. Frank Adriano Crestani [EMAIL PROTECTED] wrote on 01/15/2007 12:49:23 AM: What is the class equivalent to DataObjectBase.java in SDO C++? Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Frank is correct that there is no static interface in SDO for C++, hence we don't have a need for a class like that. Regards, Geoff.
Re: SDO Java/C++
On 15/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: What is the class equivalent to DataObjectBase.java in SDO C++? Adriano Crestani I'll talk to someone who is familiar with the Java implementation and get back to you tomorrow. Regards, Geoff.
Re: DAS C++ needing volunteers and advises
Going back to your original questions, I'll try to comment on some of them
one at a time, starting with ...
On 09/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
- DASObject: I initially created this class to set in place of the Java
Object class. The DAS Java has some functions that takes the Object class
as
arguments and as C++ has nothing like it(as far as I know) I created this
class. I've not assigned any function to this class(an empty class). Maybe
there is another simpler way to substitute the Java Object class, needing
some suggestions here too.
You are right, C++ has nothing like the Java Object class, so C++ has no
common root to its object hierarchies. I think you will find it hard to
create a C++ class that can function like Java Object. For one thing _every_
class that you create will have to inherit from DASObject (or whatever),
furthermore, what do you then do about STL classes like vector and list? You
might need to create your own versions of those, such as DASvector which
will have to inherit from both std::vector and DASObject. So, in my opinion,
the general case is too hard.
A better thing to do is look at exactly what values the Java spec is passing
into those Object parameters and try to create a common root class for just
those values. For example, in SDO we encounter this problem when trying to
deal with the various primitive data types (boolean, short, float, ...). The
Java spec defines some methods that take (or return) an Object type,
intending that type to be a wrapped primitive value (eg Byte for a byte
etc). C++ has no direct equivalent, however we can define an SDOValue class
that looks a bit like
class SDOValue {
union {
bool a;
float f;
// etc
} value;
enum {
SDObool,
SDOfloat,
// etc
} datatype;
}
and then we can pass instances of SDOValue around within methods that are
interested in any one of the primitive data types.
There's nothing magic about this particular class, it's just an example. The
important point is that in SDO for Java, in many of the places where Object
is used as a type, what is _really_ meant is not any object at all but
rather one of the primitive data types. If you can spot cases similar to
that in DAS then you can create classes to represent the things that are
really being passed instead of trying to recreate a generic Object class.
Please let me know if that doesn't make sense and I'll have another go :-)
Regards,
Geoff.
Re: DAS C++ needing volunteers and advises
On 09/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: Luciano Resende and me are developing the DAS C++. I started developing it translating the classes from DAS Java to DAS C++. I've already converted most of classes to C++, but the project is not compiling successfully yet and I think it will take some time to. There are many things to be done yet: - As I am not used to work with pointers and references explicity as C++ does, there are some pointers and refereces that are not being used correctly and need to be fixed. - Most of functions' arguments and return are referenced objects. There is necessary to rethink which function argument and return need to be a pointer or a reference. I'm begginer with C++ and I need some advises about it. - To define which argument, return and function will be set as const or not. - To define which function will be set as virtual or not. - To evaluate which and where to delete the allocated objects. I really need some advises, cause it's being difficult for me to see which is the best to delete these objects. Any volunteer to help with that I'm accepting ; ). But I think I can get by for while. However I'd like invite some volunteers to help me in the implementation of these classes: - ResultSet, ResultSetMetaData, PreparedStatement and CallableStatement: these classes belongs to the JDBC API and they are used a lot in DAS Java. As known, the ODBC API is a procedural API and turns to be very difficult to use a procedural API in a OO application. There is no need to implement these classes as complex as they are in JDBC, only what is really necessary for DAS C++. - DASObject: I initially created this class to set in place of the Java Object class. The DAS Java has some functions that takes the Object class as arguments and as C++ has nothing like it(as far as I know) I created this class. I've not assigned any function to this class(an empty class). Maybe there is another simpler way to substitute the Java Object class, needing some suggestions here too. I will sending right now to Luciano the DAS C++ project, then he may upload it in his sandbox as soon as possible. Adriano Crestani Some of the issues you describe are common to SDO for C++ (and possiby SCA too - I'm not sufficiently familiar with the code there). I can describe what we did with SDO if that helps. I'm not sure if I'll have time to actually contribute very much but I'll see what I can do. More to follow. Geoff.
Re: [SDO] Thread safety ?
I've just checked in a change to SDODate.cpp so that we define a macro called tuscany_localtime_r and set it to whichever is appropriate for Linux or MS VC8 and then use the macro wherever we would have called localtime. The macro is guarded by an #ifndef so you can override it with a compiler switch if needs be. Regards, Geoff. On 20/12/06, Caroline Maynard [EMAIL PROTECTED] wrote: 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: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
Excellent. Thank you. I've applied that patch. On 04/01/07, Yang ZHONG [EMAIL PROTECTED] wrote: xmlCanonicPath and comment have been attached as http://issues.apache.org/jira/secure/attachment/12348285/WindowsPath.support On 1/4/07, Caroline Maynard [EMAIL PROTECTED] wrote: 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 -- Yang ZHONG
Re: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading
I have a couple of comments. 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain what the code is doing and why. 2. Regarding xmlCanonicPath, performance is not an issue. This section of code won't be called often enough to matter, whereas reliability and clarity (for people reading it in future) are essential. So whether we use xmlCanonicPath or not should be based on which one is easier to understand in future. Caroline, I've looked on the libxml2 website and the description of xmlCanonicPath that I found is pretty thin. Do you have a pointer to a decent explanation of what it does? Regards, Geoff. On 04/01/07, Yang ZHONG [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/secure/attachment/12348234/WindowsPath.support throws SDOFileNotFoundException for non-existent path. As for xmlCanonicPath, it always allocates new memory and expects xmlFree where try/finally simulation may also complicate code. Trading off for performance, mine only allocates new memory when necessary and implicitly frees on destruction. I can't make up my mind. Anyone preferring xmlCanonicPath can go ahead modify the patch even source (after applying) directly. On 1/3/07, Caroline Maynard [EMAIL PROTECTED] wrote: The good news is that the fix does work for me. Though I would suggest thinking about using xmlCanonicPath() to keep the Tuscany code simpler and the URI function in libxml where it belongs. xmlCanonicPath() will silently handle platform-specific paths, too. The bad news is that the tests still fail. This time the problem is a test which deliberately calls defineFile() with a non-existent file spec. I get the same traceback for the access violation: MSVCRTD! 00239060() commonj::sdo::SAX2Parser::parse_twice(const char * 0x) line 436 + 17 bytes commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x) line 1318 + 17 bytes commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88, unsigned char 0x00, const void * 0x) line 556 + 17 bytes commonj::sdo::XSDHelperImpl::defineFile(const char * 0x02d92f88, unsigned char 0x00) line 111 + 21 bytes The cause is the same as the first example - xmlBuildURI() is returning null when passed an invalid location, and there is no guard for this condition. Before your fix was applied, Tuscany would throw an SDOFileNotFoundException. On 03/01/07, Yang ZHONG [EMAIL PROTECTED] wrote: I've tried http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990 and I think it supports Windows path on Windows (only). Let me know if your case still fails. -- Caroline -- Yang ZHONG
Re: [SDO] Thread safety ?
I've just checked in the change for localtime, replacing it with localtime_r on Unix and localtime_s on Windows. Geoff. On 09/12/06, Yang ZHONG [EMAIL PROTECTED] wrote: Maybe we can also consider Thread Safety from another perspective: User Experience. That makes the following discussion also apples to SDO Java. SDO has two parts: metadata and instances. Some modeling frameworks go as far as metadata are also instances of other metadata, it's out of scope of normal users. Many SDO users do not expect instances thread-safe: 1. Thread-safe *instances* have overhead which single-thread users and thread-instance users don't want 2. Users do not necessarily use the instance itself as the lock, e.g. they may use a lock to synchronize collection of Data Graphs, processing, resource accessing and so on Many SDO users do expect metadata are thread-safe: 1. create instances from same Type on different threads 2. retrieve same Type/Property info on different threads 3. checking isInstanceOf against same Type on different threads Hope we can keep improving SDO User Experience. -- Yang ZHONG
Re: [SDO for C++] Issues from reviewing SequenceImpl.cpp
On 11/12/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 10/12/06, Pete Robbins [EMAIL PROTECTED] wrote: On 10/12/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Further to another thread that was discussing how sequences should be maintained, I have been reviewing the code of SequenceImpl.cpp and I've made some changes that don't (shouldn't?) alter its behaviour but should make it easier to work with. It contains a number of C style macros that are used to define families of methods that are functionally similar but operate on a range of data types. As it happens, four of these macros are only actually used once each, so we get all the problems associated with macros for no gain. I've expanded the macros into inline code and also deleted the original macros which makes the code easier to read and debug. If anyone objects, the original version is still in SVN. Along the way, I noticed some odd behaviours in the code that I think are wrong, but I'd like to get a second opinion. The three methods bool SequenceImpl::addDataObject(const char* propertyName, RefCountingPointerDataObject v) bool SequenceImpl::addDataObject(unsigned int propertyIndex, RefCountingPointerDataObject v) bool SequenceImpl::addDataObject(const Property p, RefCountingPointerDataObject v) are intended to append a (property, value) pair to the end of the sequence, and differ only in how the property is identified. The middle one just calls the third more or less directly, but the other two have a significant difference. The first checks whether the property being added is part of the data object's type and if not, it checks whether the data object's type is open. If the type is open then the new property and value are added to the data object. Then it calls the third of these methods. The third method checks whether the property is many valued and if it is adds the value v to the list of values for this property. Then it exits, without altering the sequence. If the property is not many valued then the method scans the sequence and as long as the property is not already in the sequence it both sets the property value in the data object and appends a new setting to the end of the sequence. Throughout the SDO APIs there should be consistency and there always seems to be 3 ways of identifying a property: 1. Property prop - fairly straightforward 2. int propertyIndex - again validate the index and get on with it 3. char* propertyName - this could be name or XPath 1. is the one that does the work 2. should just find the Property and call 1 3. should find the property, using XPath if necessary, and then call 1. For an open type it may have to create the property before calling 1. I think this is wrong twice. Once because depending on whether you specify the property by name or object reference then you may or may not be able to add a property to an open content type. If you have the object reference (and I assume you mean the Property here) then this property must already be defined... otherwise how did you locate it? Secondly, because adding an additional value to a many valued property should result an an extra setting in the sequence. That sounds like a bug. You are right a new setting should be added to the sequence. The macros that are still in the source mean that these problems are replicated in a good many methods. Unless anyone can explain this behaviour I plan to make them consistent and also partition the code into smaller methods that might be easier to re-use when we try to update a sequence as part of setting data object property values. Regards, Geoff. This sounds like the right thing to do. ALL the macros in the code should be removed at some point. They are a pain to maintain/debug. Cheers, -- Pete I've just checked in the change that eliminates the macros that were only used once. I'll also fix the bug(s) where the sequence isn't getting set Geoff. The handling of sequences is a bit more complicated than I thought. There are already some places where a set operation will cause an update to a data object's sequence (if it has one) notably when reading open types from an XML document - unfortunately there are plenty more places where this isn't done. Then there are cases where a (property, value) pair have been added to a sequence, the property or value gets removed from the data object but the sequence is left as is, containing a reference to something that no longer exists. I'll start fixing these cases one at a time because I think all of this at once is bound to break something. Geoff.
Re: [SDO for C++] Issues from reviewing SequenceImpl.cpp
On 10/12/06, Pete Robbins [EMAIL PROTECTED] wrote: On 10/12/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Further to another thread that was discussing how sequences should be maintained, I have been reviewing the code of SequenceImpl.cpp and I've made some changes that don't (shouldn't?) alter its behaviour but should make it easier to work with. It contains a number of C style macros that are used to define families of methods that are functionally similar but operate on a range of data types. As it happens, four of these macros are only actually used once each, so we get all the problems associated with macros for no gain. I've expanded the macros into inline code and also deleted the original macros which makes the code easier to read and debug. If anyone objects, the original version is still in SVN. Along the way, I noticed some odd behaviours in the code that I think are wrong, but I'd like to get a second opinion. The three methods bool SequenceImpl::addDataObject(const char* propertyName, RefCountingPointerDataObject v) bool SequenceImpl::addDataObject(unsigned int propertyIndex, RefCountingPointerDataObject v) bool SequenceImpl::addDataObject(const Property p, RefCountingPointerDataObject v) are intended to append a (property, value) pair to the end of the sequence, and differ only in how the property is identified. The middle one just calls the third more or less directly, but the other two have a significant difference. The first checks whether the property being added is part of the data object's type and if not, it checks whether the data object's type is open. If the type is open then the new property and value are added to the data object. Then it calls the third of these methods. The third method checks whether the property is many valued and if it is adds the value v to the list of values for this property. Then it exits, without altering the sequence. If the property is not many valued then the method scans the sequence and as long as the property is not already in the sequence it both sets the property value in the data object and appends a new setting to the end of the sequence. Throughout the SDO APIs there should be consistency and there always seems to be 3 ways of identifying a property: 1. Property prop - fairly straightforward 2. int propertyIndex - again validate the index and get on with it 3. char* propertyName - this could be name or XPath 1. is the one that does the work 2. should just find the Property and call 1 3. should find the property, using XPath if necessary, and then call 1. For an open type it may have to create the property before calling 1. I think this is wrong twice. Once because depending on whether you specify the property by name or object reference then you may or may not be able to add a property to an open content type. If you have the object reference (and I assume you mean the Property here) then this property must already be defined... otherwise how did you locate it? Secondly, because adding an additional value to a many valued property should result an an extra setting in the sequence. That sounds like a bug. You are right a new setting should be added to the sequence. The macros that are still in the source mean that these problems are replicated in a good many methods. Unless anyone can explain this behaviour I plan to make them consistent and also partition the code into smaller methods that might be easier to re-use when we try to update a sequence as part of setting data object property values. Regards, Geoff. This sounds like the right thing to do. ALL the macros in the code should be removed at some point. They are a pain to maintain/debug. Cheers, -- Pete I've just checked in the change that eliminates the macros that were only used once. I'll also fix the bug(s) where the sequence isn't getting set Geoff.
Re: [C++] Who is working on which SDO problems
On 01/12/06, Simon Laws [EMAIL PROTECTED] wrote: I have been chatting with the PHP SCA team about their various SDO problems and I would be interested to know who is working on what so I look at things in transit. I'm particularly interested in the following problems: http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious xsi:type=OpenDataObject attribute generated http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets sequence information (not sure which bug - i seem to remember a post about it) - Attributes repeated as elements on output http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open this one up again if I can as it's got a bit missing w.r.t copying open content. But of course it would be worth noting anything else that's going on at the moment that might have an impact on copying problems Regards Simon I'll be on vacation for the first three days of next week, but when I get back I'll take a look at whichever ones need attention. Regards, Geoff.
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 28/11/06, Caroline Maynard [EMAIL PROTECTED] wrote: 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] Caroline, It is not part of the specification and, as far as I know, there is no likelihood that it will be. As bst I can tell the change was introduced in May in revision 405735 althoughthere isn't much explanation of what drove it. Does that help? Regards, Geoff.
New committer unable to commit changes
Hi. I recently received a note from the ASF with details of my committer account. I was able to access these to change passwords, however, when I attempt to check-in a changed file, I get the following error. Modified: Tuscany\SDO Development\Apache01\sdo\runtime\core\src\commonj\sdo\DataGraphImpl.cpp Error: Commit failed (details follow): Error: CHECKOUT of '/repos/asf/!svn/ver/452786/incubator/tuscany/cpp/sdo/runtime/core/src/commonj/sdo/DataGraphImpl.cpp': 403 Forbidden (https://svn.apache.org) I had checked the code out using TortoiseSVN and I specified the https address for the repository rather than http. Does ayone know either what I'm doing wrong or what else I need? Thanks in advance. Regards, Geoff.
[SDO for C++] Does SDO depend on zlib?
When I first set up a build environment for SDO for C++ I had to install zlib 1.2.2 as well. However, that doesn't seem to be mentioned in the documentation anymore and when I removed my copy of zlib, SDO still builds and runs without a problem. Did someone take that dependence away? Regards, Geoff.
Re: [C++] Pending SDO patches available
On 21/11/06, Pete Robbins [EMAIL PROTECTED] wrote: 907 now applied. On 21/11/06, Pete Robbins [EMAIL PROTECTED] wrote: And 730 was applied by Andy in September according to the Jira subversion log. 730 and 873 now resolved On 21/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Agh deja vu! I could have sworn I'd already applied 873! Done now -- Pete -- Pete -- Pete I've just posted a revised patch for 908 that I've tested on RHEL 3 and XP/VC6. Regards, Geoff.
Re: [SDO C++] Thread safety ?
On 21/11/06, Caroline Maynard [EMAIL PROTECTED] wrote: 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 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. As you observed earlier we will need to resolve the localtime issue. 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. Regards, Geoff.
Re: [C++] A single windows build?
On 20/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 19/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: On 11/19/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Hi, I just modified the Axis2Dispatcher class to use our logs instead of the AXIS2 logs, so we now need to link tuscany_sca_ws_dispatcher with the tuscany_sca lib. I made the changes to the Linux build, tested with VC++ express 2005 but can't make or test the changes to the VC6 and VC7 builds. This raises a bigger question. - We have VC6 and VC7 build projects/solutions checked into SVN - I am not sure which command line build works, VC6? VC7? both? - VC++ express 2005 users have to convert the VC7 projects to VC++ express projects - SCA builds OK with VC++ express 2005 but as far as I know SDO doesn't. Could we simplify our Windows story and do the following: - A single build story for windows, working with both SDO and SCA - with VC++ express 2005 + the Win32 platform SDK (because both are free) - working from the command line? I think this would be much less confusing for everybody: One working Windows build, instead of 2 or 3 broken ones :) For this to work, we will need to stop maintaining the VC6/VC7 builds and make the VC++ express build the single master build. Thoughts? Correction: I am able to build the SDO runtime with VC++ express 2005 and run the 112 SDO test cases. -- Jean-Sebastien +1 - happy to move compilers. I don't know if VC++ express 2005 allows generation of the command-line makefiles - we may have to manage them by hand if we still want a command-line build. I know VC7 doesn't let you generate them - we currently use VC6 to generate them, after which they can be used with VC6 or VC7 (don't know about VC++ express). I don't know how much hassle it will be to manage them by hand, but I personally think a single windows build system would be worth the hassle. Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Andy, I think it is important to have a command line build. I couldn't find a .mak generator in VC++ express 2005 either, but there's a vcbuild.exe command line tool which directly takes a project or solution file. Would it make sense to use that? I already raised TUSCANY-918 for this work and have been fiddling around with it when I've had the time. vcbuild.exe sounds like what we need but if it doesn't work how we want it we will have to hand craft and manage the makefiles... like we do on Linux. Cheers, -- Pete I'd prefer it if we didn't single out an IDE at all. I think we ought to have a command line build as the one common supported build process, and then anyone who wants to can contribute the instructions/support to use their favourite IDE. There's too much stuff hidden in the IDE configuration files that's either hard to find or just plain impossible to see (eg the contents of a .suo file). Since we need a command line build for releases anyway, why not standardise on that? Regards, Geoff.
Re: Use std::string as an example to discuss object vs. /* to reduce heap allocation/release and memory copying
On 21/11/06, Yang ZHONG [EMAIL PROTECTED] wrote:
There's a way of using std::string in Tuscany which might allocate/release
heap and copy memoery too frequently.
Could you please verify that's the case and brainstorm an optimization?
std::string is just an example, using object vs. using /* is the more
generic topic.
This's the code snippet:
typedef std::string SDOString;
SDOString DataFactoryImpl::getFullTypeName(const SDOString uri, const
SDOString inTypeName) const
{
return uri + # + inTypeName;
}
void DataFactoryImpl::addType(const char* pccUri, const char*
pccTypeName,...)
{
SDOString fullTypeName = getFullTypeName(pccUri, pccTypeName);
...
}
1. getFullTypeName(pccUri,pccTypeName) call will allocate stack for
std::string instance uri and inTypeName.
Since a URI is likely longer than 16(see std::string implementation), a
heap(5-1) piece will be allocated.
pccUri and pccTypeName will be copied into uri(7-1) and inTypeName(7-2)
respectively
2. uri+# will allocate stack and *heap*(5-2) for a new std::string
instance, and uri will be copied(7-3)
3. ...+inTypeName will allocate stack and *heap*(5-3) for another new
std::string instance, and above(2.) std::string(7-4) and inTypeName(7-5)
will be copied
4. getFullTypeName return will allocate stack and *heap*(5-4) for yet
another new std::string instance, and return value will be copied(7-6)
5. The assignment to local variable fullTypeName, will allocate stack and
*heap*(5-5) for one more new std::string instance, and value will be
copied(7-7)
Could you please verify that's the case?
If true, it's too frequent that simple 2 lines of code allocate/release
heap
*five* times and copy memory *seven* times.
Could you please brainstorm an optimization?
This might be a start:
SDOString DataFactoryImpl::getFullTypeName(SDOString stringBuffer,
const char* inTypeName) const
{
stringBuffer += #;
return stringBuffer += inTypeName;
}
void DataFactoryImpl::addType(const char* pccUri, const char*
pccTypeName,...)
{
SDOString fullTypeName = pccUri;
getFullTypeName(fullTypeName, pccTypeName);
...
}
It allocates/releases heap 4 times less and copys memory 5 times less.
In general, we may want to consider and * while using an object.
A huge difference for Java developer to notice when programming C++ is,
Java
Object variable is by reference(/* in C++) while C++ object is by
*value*.
--
Yang ZHONG
Part of the problem here is that we haven't completed the move to
std::string from char* as the way to represent text strings. The delay is
unavoidable because we need some things resolved in the spec, however, until
then we are left with a mixture of methods with some using std::string and
some using char* and the compiler inserting conversions. The two
std::strings allocated in your step 1
1. getFullTypeName(pccUri,pccTypeName) call will allocate stack for
std::string instance uri and inTypeName.
arise in exactly this way and won't be once we complete the conversion.
Your points about the efficiency of the appends is a good one. We should use
+= more than we do.
Regards,
Geoff.
Re: [SDO C++] Thread safety ?
On 17/11/06, Caroline Maynard [EMAIL PROTECTED] wrote: 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 ... 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. Regards, Geoff.
Re: SDO - dealing with CDATA
On 08/11/06, Simon Laws [EMAIL PROTECTED] wrote: OK, so I've take my option 1 approach (see previous mail) and implemented a solution in C++ SDO which allows CDATA sections and their strange markers to appear in SDO properties. In this way the API for reading and creating CDATA sections is the normal SDO string API. In a way this is just a preliminary stab to allow us to play with CDATA and see whether this simple approach is satisfactory. From the previous mails there was discussion of alternative approaches where special markers are introduced to indicate where CDATA appears hence removing the need to maintain the CDATA markers in text. However there are some tricky cases. Particularly where one or more CDATA sections appear within primitive text string. As schema gives us no help in locating CDATA sections this leaves the model at a bit of a loss in terms of representing them. We would potentially end up adding scaffolding around primitive string types, or preferably create a new type, that is able to represent accurately the combination of text and CDATA sections. Anyhow something more complex may be appropriate in the future but this simple solution allows us to offer something to our PHP SDO users quickly that I don't think causes us big problems for the future. If in the future we have special flags we can always reproduce the CDATA markers if required. I created a JIRA to record progress on this issue ( http://issues.apache.org/jira/browse/TUSCANY-908) Simon Simon, I've looked through your patch and I think that's a sensible approach. It will obviously be a while (at least) before the specification has anything definitive to say on this subject and what you are doing at least gives the SDO user sight of the CDATA text. (Unlike the current situation where it is silently discarded.) Have you tried building your patch on Linux? Regards, Geoff.
Re: SDO C++: Getting Involved -- Tests/Samples
Bryan, Sorry for the delay in progressing with this. I've been trying to build the tests you contributed and I've run into a couple of problems. I started trying to compile and link DataObjectTest.cppand .h. Looking at the .h file, it includes rwsf/core/XmlName.h and rwsf/core/utility. h and I don't have either of those. It also includes something called DataConverter.h. That one appears among the standard SDO header files - although it isn't a standard header as far as I know. Do I need those files or can I just delete the includes? Regards, Geoff. On 31/10/06, Bryan Luoma [EMAIL PROTECTED] wrote: Yes Geoff, that does sound feasible. All of the cxxtest Macros (asserts etc...) will need to be removed. Let me know if you have any questions. Thanks, Bryan -Original Message- From: Geoffrey Winn [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 5:30 AM To: tuscany-dev@ws.apache.org Subject: Re: SDO C++: Getting Involved -- Tests/Samples On 24/10/06, Bryan Luoma [EMAIL PROTECTED] wrote: Hello, I also attached a few sample C++ unit tests used at Rogue Wave Software. http://issues.apache.org/jira/browse/TUSCANY-840 There are 3 Example RW C++ unit tests using cxxTest Framework. sdo.zip archive consists of 3 tests: DataObjectTest: 213 test cases DataObjectGetSetPrimitivesTest: 72 test cases DataObjectListTest: 64 test cases This is an initial drop of example C++ unit tests used at Rogue Wave Software. These tests use RW implementation specific classes and will need refactoring before use with Tuscany. The intent is to get the discussion moving forward on design considerations and integration. Thanks, Bryan Hi Bryan, As you probably know, there are some questions around whether the licensing for cxxtest is compatible with Apache. While that is being sorted out I thought I'd see how hard it is to take out the cxxtest dependencies in your code and run the tests some other way. Does that sound feasible to you? If so I'll make a start on it tomorrow (Tuesday). Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Subversion property configuration
On 06/11/06, kelvin goodson [EMAIL PROTECTED] wrote: To save other Windows TortoiseSVN users the hassle of working out what to do here, it would appear that the thing to do is to bring up the Windows Explorer TortoiseSVN context menu and select settings, then on the general tab of the dialog that appears, click the edit button, add the contents of https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props to the auto-props area of the file which appears in an editor and remove the comment from the enable-auto-props = yes line. Kelvin I've just done that and I noticed two small things that were a bit confusing. I had an out of the box installation of TortoiseSVN and it already had a non-empty [auto-props] section so my first thought was whether I was supposed to replace or append to that section. In fact the section is almost all disabled by comment characters, so an append is fine. I also found that in my installation the enable-auto-props = yes was already uncommented. Geoff.
[SDO for C++] Making the definition of types more user friendly
Various people have complained about the fact that the process for defining types (metadata) in SDO for C++ locks the type system as soon as the first data object is created. I've submitted a patch under JIRA 546 that relaxes that restriction a fair bit. With the patch in place, you can now create new types whenevr you wish and every time a data object is created any types added since the last data object was created are merged into the type system. However, once a type is resolved in this way it becomes read-only (as it was before the patch). I've done a small amount of testing to show that existing functionality isn't broken, however, I'd be interested in some feedback on a) whether this works adn b) whether it is useful. Regards, Geoff.
Re: SDO C++: Getting Involved -- Tests/Samples
On 24/10/06, Bryan Luoma [EMAIL PROTECTED] wrote: Hello, I also attached a few sample C++ unit tests used at Rogue Wave Software. http://issues.apache.org/jira/browse/TUSCANY-840 There are 3 Example RW C++ unit tests using cxxTest Framework. sdo.zip archive consists of 3 tests: DataObjectTest: 213 test cases DataObjectGetSetPrimitivesTest: 72 test cases DataObjectListTest: 64 test cases This is an initial drop of example C++ unit tests used at Rogue Wave Software. These tests use RW implementation specific classes and will need refactoring before use with Tuscany. The intent is to get the discussion moving forward on design considerations and integration. Thanks, Bryan Hi Bryan, As you probably know, there are some questions around whether the licensing for cxxtest is compatible with Apache. While that is being sorted out I thought I'd see how hard it is to take out the cxxtest dependencies in your code and run the tests some other way. Does that sound feasible to you? If so I'll make a start on it tomorrow (Tuesday). Regards, Geoff.
Re: Reminder. Request for Project Ideas for University Students
Thanks for that. I'm clear about both of those and I'll discuss them with the 2 universities. I took another look at the third suggestion ... *DAS and non-SDO data types* Currently, Tuscany DAS only generate static or dynamic Service Data Objects. This project consist in generating different object types as a result of a DAS command. This project would include extending DAS to understand what types should be generated, investigating and solving problems like how to handle change summaries, etc.This could be applied not only for the current DAS RDB implementation, but in conjunction with other implementations like XML DAS. I don't follow this one at all (this may be because I mostly work with SDO for C++ which doesn't have a static interface). As I understand it, static and dynamic types are the only choices, so I'm not sure what you mean by generating different object types as a result of a DAS command. Apologies for being a bit slow, on the other hand, if I don't understand then maybe potenial students won't either. Thanks and regards, Geoff. On 18/10/06, Luciano Resende [EMAIL PROTECTED] wrote: C++ DAS would be a DAS implementation in C++. When I said SDOHelper, I should have said XMLHelper. As for XML DAS, you got it right, and as far as I know we don't have anyone looking into that as of now, at least in the Java side. - Luciano On 10/18/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 18/10/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Geoff I have started creating some project descriptions for the DAS ideas listed on the referenced wiki page. Please find my draft at : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/DAS_Subprojects Please let me know if you want any specific type of contents to help you sell the ideas to the university/students. - Luciano Resende Looking at the first item * * *C++ DAS* Today, Tuscany C++ SDO work in conjunction with SDOHelper to map back-end data representation to Service Data Objects. There is a need for a C++ DAS implementation that would interop with the C++ SDO and mediate between the SDO and the back-end store. Could explain a little more about this? What is the SDOHelper? I'm not aware that SDO for C++ has an SDOHelper. And for the second item *XML DAS* Currently, Tuscany DAS only support RDB back-ends, altough the idea is that DAS could access and mediate data trough various backends representations, XML being one of them. This project consists in designing the DAS implementation over XML, how the commands would be structured (e.g using XQuery, XPath, etc) and also contribute important feedback to a possible DAS spec. I'd like to check that I understand this correctly. SDO already has an XMLHelper that will read an XML document and generate a data graph. I think you mean a DAS that will selectively read fragments of an XML document and generate data objects corresponding to those fragments. Is that somewhere near? If so, I think that's the sort of thing that would work well as a student project. Thanks and regards, Geoff.
Re: Reminder. Request for Project Ideas for University Students
On 18/10/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Geoff I have started creating some project descriptions for the DAS ideas listed on the referenced wiki page. Please find my draft at : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/DAS_Subprojects Please let me know if you want any specific type of contents to help you sell the ideas to the university/students. - Luciano Resende Thank you very much for that. I'll take a closer look later today an see if anything else might help. Regards, Geoff.
[SDO for C++] How to raise JIRAs for 2.1 spec compliance
I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff.
Re: [SDO for C++] How to raise JIRAs for 2.1 spec compliance
Are you sure about the SDO C++ part in square brackets? These JIRAs will already have their component property set to C++ SDO so they are easy enough to identify as belonging to SDO for C++. I was trying not to clutter the summary too much. Regards, Geoff. On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, there is a specification category for Jiras so when you raise one you can select SDO C++ and specification. Prefixing the summary field is a good idea.. maybe [SDO C++ 2.1 Spec] as the specification classification covers Java/C++ and sdo/sca. Actually I'm not sure if the specification category is for changes we, Tuscany, want to see in the specs... Just raise them against SDO C++ with the [SDO C++ 2.1 Spec] summary prefix Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff. -- Pete
Re: [SDO for C++] How to raise JIRAs for 2.1 spec compliance
On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Whatever you like. You don't see the component in the Jira created message so maybe we should put this in there. That's a good point. OK, I'm persuaded. I'll use [SDO C++ 2.1 Spec] Regards, Geoff. Or... get Jira to add it in automagically if anyone knows how?? Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Are you sure about the SDO C++ part in square brackets? These JIRAs will already have their component property set to C++ SDO so they are easy enough to identify as belonging to SDO for C++. I was trying not to clutter the summary too much. Regards, Geoff. On 17/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, there is a specification category for Jiras so when you raise one you can select SDO C++ and specification. Prefixing the summary field is a good idea.. maybe [SDO C++ 2.1 Spec] as the specification classification covers Java/C++ and sdo/sca. Actually I'm not sure if the specification category is for changes we, Tuscany, want to see in the specs... Just raise them against SDO C++ with the [SDO C++ 2.1 Spec] summary prefix Cheers, On 17/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I am working through the draft 2.1 version of the SDO for Java spec, migrating the changes into the C++ spec. That will create requirements to change the SDO implementation to comply with the new spec. My preference is to raise JIRAs for these items, with those JIRAs clearly labelled so that we can distinguish them from all the rest should we need to. My suggestion is that we do that in the summary field so that the JIRAs would include say [ 2.1 spec] at the beginning of the summary field. Anyone have any better ideas? Regards, Geoff. -- Pete -- Pete
Re: [C++ Wiki] Links on the Tuscany for C++ page broken
I'v eupdated the Wiki site as discussed - at least the links al lead somewhere now. On 13/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Geoff, Is the process for building on Ubuntu very different to our general Linux instructions? Cheers Andy No, it isn't. The main difference is that Ubuntu has its own mechanism for finding and installing pre-reqs - so it's all point and click with the mouse rather than copying and then gzip/tar. I took the opportunity to update the notes on running tests but that stuff obviously changes over time anyway. I'll add a text copy of my notes to the Wiki and then we can decide whether any of it would be useful in the real distribution. Regards, Geoff.
Re: SDO Java: Getting Involved -- Tests/Samples
Reading Tom's note, Rogue Wave have Java and C++ tests. Do we need a separate JIRA for any C++ related work? Geoff. On 12/10/06, kelvin goodson [EMAIL PROTECTED] wrote: Tom, Welcome to Tuscany! that's great! Thanks for offering to get involved. How should we proceed? I'd be most happy to assist you to integrate what you have to offer. We currently have a small collection of tests using the junit framework (see https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/ ) but there's significant scope for enhancement. BTW I'm going to make my response Java centric as Andrew has offered to help look at the C++ side of things. How about this for a proposal for how to proceed? I have opened a JIRA (this is our issue or bug tracking system if you are not familiar with these things --- please tell me if you are already an expert). The JIRA can be seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you can upload attachments to the JIRA, so we could perhaps use that to first attach a typical RogueWave test or two. I guess it's likely that there will be some modifications that need to be made with regards to setting up the test within our environment, but that way we could play and discuss how we might proceed with more tests. How does that sound? Best Regards, Kelvin. On 11/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Tom, Coming from the C++ side of Tuscany, I know we'd certainly be interested in those C++ SDO tests - please get involved! Cheers Andrew On 10/11/06, T Gould [EMAIL PROTECTED] wrote: Kelvin - We at Rogue Wave have been developing an SDO product, HydraSDO, and have a seires of tests that might be easiliy modified so as to exercise your Java SDO product. We would be very interested in providing our tests as well as helping create a test environment (unless this has already been done) to futher test the SDO product. Additionally, we also have C++ tests. tom gould --- As the Java M2 release is imminent it occured to me that it would be really useful if there are users out there who are putting our code through its paces that you may be developing samples/tests which could usefully be contributed back to the Tuscany project and make it more robust. If you are in such a position it would be really great to hear from you. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++ Wiki] Links on the Tuscany for C++ page broken
The first five links on the Tuscany C++ page on the Wiki ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp) are links to pages on the main Tuscany web site. Unfortunately four of them are broken (see below) - presumably following the recent reorganisation of the main site. - The main tuscany site http://incubator.apache.org/tuscany/ - [image: [WWW]] The installation instructions for SCA and SDO in C++http://incubator.apache.org/tuscany/installcpp.html - [image: [WWW]] The C++ user guide for SCA and SDO in C++http://incubator.apache.org/tuscany/userguidecpp.html - [image: [WWW]] The SCA for C++ Documentationhttp://incubator.apache.org/tuscany/documentationscacpp.html - [image: [WWW]] The SDO for C++ Documentationhttp://incubator.apache.org/tuscany/documentationsdocpp.html It's not obvious how to fix this since, for example, there doesn't seem to be a single page that is the installation instructions for SCA and SDO. Does anyone have any strong opinions about how we re-organise this? I think the bottom two could reasonably be pointed to http://incubator.apache.org/tuscany/cpp_sca_overview.html and http://incubator.apache.org/tuscany/cpp_sdo_overview.html and maybe the third one deleted. Then perhaps the second one should open another Wiki page where we list or link to installation instructions for various combinations of product and platform. I was intending to add instructions on how to set up a build environment on Ubuntu but as things stand there's no obvious place to put it. Regards, Geoff.
Re: [C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples
OK. I tried invoking ./runclient as described and it tells me that 5 divided by 2 is 2.5 which seems reasonable. Is it worth me posting instructions on how to build on Ubuntu? Geoff. On 11/10/06, Pete Robbins [EMAIL PROTECTED] wrote: On 11/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: On 10/10/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Proxies are generated by the scagen tool. The tool is written in Java and uses an XSL stylesheet to generate the Proxy code. The code for the tool is under under sca/tools/scagen. It has always been working well for me on Redhat Linux. Can you try to run this from the sample.calculator directory: java -jar $TUSCANY_SCACPP/bin/scagen.jar -dir . -output . and see if you get any error messages or exceptions? That worked without apparent error, but ... Also which JDK are you using? 1.5.0 as stated in your instructions, but ... I bungled the PATH setting, with the result that the javac command activates the 1.5 compiler, but the JVM is still the 1.4 version. Once I sorted that out the problem went away and the samples build without a problem. Unfortunately, I still can't run scatest.sh successfully. In your instructions it says To run the SCA runtime tests: cd $HOME/tuscany/cpp/sdo ./scatest.sh However, when I do this I get [EMAIL PROTECTED]:~/tuscany/Generic/sca$ ./scatest.sh Using SCA installed at /home/gwinn/tuscany/Generic/sca/deploy Using SDO installed at /home/gwinn/tuscany/Generic/sdo/deploy Using Axis2C installed at /home/gwinn/tuscany/axis2c-bin-0.94-linux ./scatest.sh: line 52: cd: /home/gwinn/tuscany/Generic/sca/deploy/bin/test: No such file or directory ./scatest.sh: line 53: ./tuscany_sca_test: No such file or directory which looks as though something hasn't been built. I also tried scatest no longer exists so I'm not surprised it doesn't run ;- To run the SCA calculator sample: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/bin ./runclient.sh and that doesn't work because the deploy directory doesn't have a bin sub-directory. Is there an extra step in the SCA build process to build the tests? The deployment layout has changed for M2 and the doc you are following is no longer valid. Try: cd $HOME/tuscany/cpp/sca/deploy /samples/Calculator/deploy/sample.calculator.client ./runclient.sh Cheers, -- Pete
[C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples
I've been using the instructions that Sebastian posted a while ago for building on Linux to try to build the C++ versions of SDO and SCA on Ubuntu Linux. SDO works fine and the tests run successfully. The SCA runtime builds OK too, but the samples fail to build and I've appended the build output at the end of this note. The failure occurs when compiling CalculatorImpl_CalculatorService_Proxy.cpp and when I examine that file it contains floatfloatfloatfloatfloatfloatfloatfloatfloatfloatfloatfloat I'm not joking. That line is the entire contents of the file. I've tried the obvious approach of just deleting everything and re-running it but I still get the same result. I assume this is a generated file, in which case there's probably some failure in the code generation. Can anyone give me some hints about where to look? Regards, Geoff. [EMAIL PROTECTED]:~/tuscany/Generic/sca/samples$ make make all-recursive make[1]: Entering directory `/home/gwinn/tuscany/Generic/sca/samples' Making all in Calculator make[2]: Entering directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator' Making all in sample.calculator make[3]: Entering directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator/sample.calculator' java -jar /home/gwinn/tuscany/Generic/sca/deploy/bin/scagen.jar -dir . -output . make all-am make[4]: Entering directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator/sample.calculator' if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/home/gwinn/tuscany/Generic/sca/deploy/extensions/cpp/include -I/home/gwinn/tuscany/Generic/sca/deploy/include -I/home/gwinn/tuscany/Generic/sdo/deploy/include-g -O2 -MT CalculatorImpl.lo -MD -MP -MF .deps/CalculatorImpl.Tpo -c -o CalculatorImpl.lo CalculatorImpl.cpp; \ then mv -f .deps/CalculatorImpl.Tpo .deps/CalculatorImpl.Plo; else rm -f .deps/CalculatorImpl.Tpo; exit 1; fi mkdir .libs g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/home/gwinn/tuscany/Generic/sca/deploy/extensions/cpp/include -I/home/gwinn/tuscany/Generic/sca/deploy/include -I/home/gwinn/tuscany/Generic/sdo/deploy/include -g -O2 -MT CalculatorImpl.lo -MD -MP -MF .deps/CalculatorImpl.Tpo -c CalculatorImpl.cpp -fPIC -DPIC -o .libs/CalculatorImpl.o if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/home/gwinn/tuscany/Generic/sca/deploy/extensions/cpp/include -I/home/gwinn/tuscany/Generic/sca/deploy/include -I/home/gwinn/tuscany/Generic/sdo/deploy/include-g -O2 -MT CalculatorImpl_CalculatorService_Proxy.lo -MD -MP -MF .deps/CalculatorImpl_CalculatorService_Proxy.Tpo -c -o CalculatorImpl_CalculatorService_Proxy.lo CalculatorImpl_CalculatorService_Proxy.cpp; \ then mv -f .deps/CalculatorImpl_CalculatorService_Proxy.Tpo .deps/CalculatorImpl_CalculatorService_Proxy.Plo; else rm -f .deps/CalculatorImpl_CalculatorService_Proxy.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/home/gwinn/tuscany/Generic/sca/deploy/extensions/cpp/include -I/home/gwinn/tuscany/Generic/sca/deploy/include -I/home/gwinn/tuscany/Generic/sdo/deploy/include -g -O2 -MT CalculatorImpl_CalculatorService_Proxy.lo -MD -MP -MF .deps/CalculatorImpl_CalculatorService_Proxy.Tpo -c CalculatorImpl_CalculatorService_Proxy.cpp -fPIC -DPIC -o .libs/CalculatorImpl_CalculatorService_Proxy.o CalculatorImpl_CalculatorService_Proxy.cpp:1:61: warning: no newline at end of file CalculatorImpl_CalculatorService_Proxy.cpp:1: error: expected constructor, destructor, or type conversion at end of input make[4]: *** [CalculatorImpl_CalculatorService_Proxy.lo] Error 1 make[4]: Leaving directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator/sample.calculator' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator/sample.calculator' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gwinn/tuscany/Generic/sca/samples/Calculator' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gwinn/tuscany/Generic/sca/samples' make: *** [all] Error 2
Re: [C++] SDO can't load an XML doc with no namespace
Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. 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. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - 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
That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. 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. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] SDO can't load an XML doc with no namespace
That is still a separate issue from the one Sebastian raised. Sebastian specifically stated that he did not have an xsd and didn't want one. Loading an XML instance without type information in that situation can be done, via a small xsd file immediately (as a workaround), and via small code change soon. The issue of frozen type systems affects other things besides this one. It needs to be fixed, but it's still a separate question. Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Well it depends on which DataFactory you are using during the loading of the xml. I would usually create an XSDHelper and load a schema. I'd then create an XMLHelper using the DataFactory from the XSDHelper. I then load my xml. If I now load a schemaless xml using that XMLHelper how do you create the new Open Type? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: That's a different question. As I understand it, Sebastian (and others) were asking about loading an XML instance document without a corresponding xsd (or any other type information) and as above there is a way to do that and I can hack it to make it a little easier. As you say, you cannot create any type at all after the first data object is created. I'm looking into relaxing that too, but it is a separate issue from processing XML without a schema. Regards, Geoff. On 09/10/06, Pete Robbins [EMAIL PROTECTED] wrote: Can you create an open type on the fly? Is the datafactory not locked once the first DO is created? Cheers, On 09/10/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastian, I looked into this a bit more and it may not be as bad as it appears. Currently, when the XML parser encounters an element for which there is no type defined, it ignores that element and all of its content, resuming the parse once that unknown element has ended. The exception to this is when the element is a member of a parent that is defined to have open content. In your example, the root element has no type definition and, of course, it can't have a parent with open content, so it and all of its contents are ignored, which explains the output that you see. 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. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Pete
Reminder. Request for Project Ideas for University Students
In mid-September I posted some material to the mailing list and Wiki regarding the possibility of M.Sc students at Oxford working on Tuscany as the project element of their course. I am also now talking to a University in France (Ecole des Mines de Nantes) about a similar proposal, although in the case of EMN, the project represents about 4 months of effort, compared to Oxford's 1 or 2. Various people suggested project titles, that are listed here http://wiki.apache.org/ws/Tuscany/CommunityBuilding, however, there isn't sufficient detail to allow me to sell the ideas, or an interested student to assess whether the subject is worth pursuing. If you are active in any of the areas listed, could you supply more detail, either on the Wiki page, or direct to me if that is easier. Thanks in advance.
Re: [C++][SDO] Use of std::string
No objection from me. Geoff. On 02/10/06, Pete Robbins [EMAIL PROTECTED] wrote: So, does anyone have any objection if I check in the updates to typedef SDOString as std::string? -- Pete
Re: [C++][SDO] Use of std::string
I'd like to get support for stdcxx in the Linux build as it already is in the XP one. I'm planning to review the JIRA list this week to see what's urgent or blocking other people. Geoff. On 02/10/06, Andrew Borley [EMAIL PROTECTED] wrote: Not me! On a releated note - is there any particular functionality or big fixes that would be good to get into M2 for SDO? We have a good list for SCA, but not much for SDO. Cheers Andy On 10/2/06, Pete Robbins [EMAIL PROTECTED] wrote: So, does anyone have any objection if I check in the updates to typedef SDOString as std::string? -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO for C++] Problem with modifying build configuration files for MS VC 7.1
I tried that and it fixes one instance, but there are at least 4! I've attached the .suo file from my working stdcxx case to the 724 JIRA. Could you apply that and see what we get? Thanks Geoff. On 29/09/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Geoff, Looks like it's the projectsvc7/tucany_sdo/tuscany_sdo.suo file that holds this info. Unfortunately it's in some binary format which makes management of it via svn harder as binary files don't get included in patches. I've put it up with the Working Directory property set - let me know if it works OK, or pass me your version I'll commit that instead. Cheers Andy On 9/28/06, Geoffrey Winn [EMAIL PROTECTED] wrote: In JIRA 724 I contributed changes to SDO for C++ to make stdcxx a build option, specifically by adding new build configurations for release and debug builds. Unfortunately, the effect of applying that patch is to damage all of the build configurations for MS VC 7.1. The problem is that before the patch was applied, all the build configurations set the Working Directory property of the Debugging pane to ..\..\..\runtime\core\test. Since the patch was applied, that field is blank - not just in the 2 new configurations that I added, but also in the two that were there before. Therefore, the tests all fail because they are running in the wrong directory. My patch modified the tuscany_sdo.sln file and also the sdo_runtime.vcproj and sdo_test.vcproj files. The build tree that was the source of that patch does still have the Working Directory property set correctly and yet the current tree does not. I'm puzzled. I can't find where that property is stored, even in the source tree where it works. Does anyone have any idea where that property is recorded because presumably that is the thing I need to check in to complete this change? Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO for C++] Problem with modifying build configuration files for MS VC 7.1
That did it. Thanks. All the build configurations have the Working Directory set correctly and the tests run successfully out of the box. Regards, Geoff. On 29/09/06, Andrew Borley [EMAIL PROTECTED] wrote: No probs - it's in. Cheers Andy On 9/29/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I tried that and it fixes one instance, but there are at least 4! I've attached the .suo file from my working stdcxx case to the 724 JIRA. Could you apply that and see what we get? Thanks Geoff. On 29/09/06, Andrew Borley [EMAIL PROTECTED] wrote: Hi Geoff, Looks like it's the projectsvc7/tucany_sdo/tuscany_sdo.suo file that holds this info. Unfortunately it's in some binary format which makes management of it via svn harder as binary files don't get included in patches. I've put it up with the Working Directory property set - let me know if it works OK, or pass me your version I'll commit that instead. Cheers Andy On 9/28/06, Geoffrey Winn [EMAIL PROTECTED] wrote: In JIRA 724 I contributed changes to SDO for C++ to make stdcxx a build option, specifically by adding new build configurations for release and debug builds. Unfortunately, the effect of applying that patch is to damage all of the build configurations for MS VC 7.1. The problem is that before the patch was applied, all the build configurations set the Working Directory property of the Debugging pane to ..\..\..\runtime\core\test. Since the patch was applied, that field is blank - not just in the 2 new configurations that I added, but also in the two that were there before. Therefore, the tests all fail because they are running in the wrong directory. My patch modified the tuscany_sdo.sln file and also the sdo_runtime.vcproj and sdo_test.vcproj files. The build tree that was the source of that patch does still have the Working Directory property set correctly and yet the current tree does not. I'm puzzled. I can't find where that property is stored, even in the source tree where it works. Does anyone have any idea where that property is recorded because presumably that is the thing I need to check in to complete this change? Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Project Ideas for M.Sc Students
Oops. I forgot to mention, The stuff that I posted to the Wiki about project work for M.Sc students is at http://wiki.apache.org/ws/Tuscany/CommunityBuilding Geoff On 22/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Raymond, Thank you, that worked fine. Geoff. On 21/09/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, In the wiki page, go to attachmens and upload your file as an attachment with a name such as ws.pdf. Then use a tag attachment:ws.pdf to make it available to your page. Or you can create a URL link pointing to your attachment. Thanks, Raymond - Original Message - From: Geoffrey Winn [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, September 21, 2006 8:41 AM Subject: Re: Request for Project Ideas for M.Sc Students I have a .pdf document that describes the web services course at Oxford and I agreed to add that to the Wiki, but I can't see how to do that. Can anyone help me with that? Thanks in advance. Geoff. On 19/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've added a page to the Wiki to cover Community Building issues and following on from yesterday's IRC chat I've listed the various project ideas that were mentioned. I've also added some background about what a proposal would need to look like to get University approval. I'll add more detail to that as soon as I get it. Geoff. On 11/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've been talking to the Computing Lab at the University of Oxford about various ways in which Tuscany might be useful to them. One subject that came up was that we could offer project work to their part-time M.Sc students ie students that are typically already working as full time software developers. The project is officially supposed to take 200 hours of effort, including writing a dissertation which is the thing that is actually assessed towards the degree. In practice, most students spend far longer than that, typically three times as much. Therefore, I would estimate that we could propose projects that represent about 4-6 weeks of development effort. This is an opportunity for us to attract developers to Tuscany and at the same time raise its profile with a variety of employers. If anyone has any suggestions please post them as replies to this note or contact me directly. Please bear in mind that the students will not necessarily have any knowledge of SOA or Tuscany and may well need support - to get started at least. Regards, Geoff. - 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
I won't be able to do anything about this until the week after next at the earliest (ie early October) - but even then I have other commitments. I'll try to find some time to look at it then. Regards, Geoff. On 21/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Geoffrey Winn wrote: I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Do you guys have any update on this one? What would it take to fix it? As Simon said earlier in this thread, getting open content to work would be really handy for script based applications where interfaces and operations are not always known in advance. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Project Ideas for M.Sc Students
I have a .pdf document that describes the web services course at Oxford and I agreed to add that to the Wiki, but I can't see how to do that. Can anyone help me with that? Thanks in advance. Geoff. On 19/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've added a page to the Wiki to cover Community Building issues and following on from yesterday's IRC chat I've listed the various project ideas that were mentioned. I've also added some background about what a proposal would need to look like to get University approval. I'll add more detail to that as soon as I get it. Geoff. On 11/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've been talking to the Computing Lab at the University of Oxford about various ways in which Tuscany might be useful to them. One subject that came up was that we could offer project work to their part-time M.Sc students ie students that are typically already working as full time software developers. The project is officially supposed to take 200 hours of effort, including writing a dissertation which is the thing that is actually assessed towards the degree. In practice, most students spend far longer than that, typically three times as much. Therefore, I would estimate that we could propose projects that represent about 4-6 weeks of development effort. This is an opportunity for us to attract developers to Tuscany and at the same time raise its profile with a variety of employers. If anyone has any suggestions please post them as replies to this note or contact me directly. Please bear in mind that the students will not necessarily have any knowledge of SOA or Tuscany and may well need support - to get started at least. Regards, Geoff.
Re: [SDO for C++] How to integrate stdcxx as a build option?
I've added a section to the Wiki ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/DesignNotes) explaining the changes I made to get SDO to build with stdcxx on XP with MSVC 7.1. The corresponding changes should work for any other C++ project on XP. Geoff.
Re: Request for Project Ideas for M.Sc Students
I've added a page to the Wiki to cover Community Building issues and following on from yesterday's IRC chat I've listed the various project ideas that were mentioned. I've also added some background about what a proposal would need to look like to get University approval. I'll add more detail to that as soon as I get it. Geoff. On 11/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I've been talking to the Computing Lab at the University of Oxford about various ways in which Tuscany might be useful to them. One subject that came up was that we could offer project work to their part-time M.Sc students ie students that are typically already working as full time software developers. The project is officially supposed to take 200 hours of effort, including writing a dissertation which is the thing that is actually assessed towards the degree. In practice, most students spend far longer than that, typically three times as much. Therefore, I would estimate that we could propose projects that represent about 4-6 weeks of development effort. This is an opportunity for us to attract developers to Tuscany and at the same time raise its profile with a variety of employers. If anyone has any suggestions please post them as replies to this note or contact me directly. Please bear in mind that the students will not necessarily have any knowledge of SOA or Tuscany and may well need support - to get started at least. Regards, Geoff.
Re: [jira] Commented: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
That's a shame. OK. I guess I'll have to do it the hard way and install VC++
Express.
On 12/09/06, Jean-Sebastien Delfino (JIRA) tuscany-dev@ws.apache.org
wrote:
[
http://issues.apache.org/jira/browse/TUSCANY-719?page=comments#action_12434304]
Jean-Sebastien Delfino commented on TUSCANY-719:
Hi Geoff,
I tried your patch on Windows / VC++ express 2005 and got the same
exception as before: incompatible list iterator
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Priority: Minor
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
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
Re: [C++] Adding -lxml2 to link libtuscany_sdo.so on Linux
I agree with that change. It is certainly linked as part of the build on MSVC++ so I don't see why it wouldn't be on Linux. Geoff. On 12/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, On Linux, shared library libtuscany_sdo.so references symbols from libxml2.so but is not linked with it. Programs that use libtuscany_sdo.so then need to be linked with libxml2.so to resolve these undefined symbols. I just ran into this as the Ruby extension shared library could not be loaded because of these undefined references to libxml2. I think this is a bug as a user of SDO should not have to know that SDO is implemented on top of libxml2 or whatever other XML handling library. I am adding a -lxml2 directive for now to the SDO Makefile.am to fix this. I think this is a good change but could you please take a look and confirm? Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
Sebastian,
I've installed Microsoft Visual C++ 2005 Express Edition and used it to open
the tuscany_sdo.sln file in a fresh extract from svn and a debug build fails
claiming that it can't find odbc32.lib. Have you seen that before? I'm a bit
puzzled because it ran a wizard that claimed to be migrating the projects
and they all build happily in MS VC 7.1.
Regards,
Geoff.
On 13/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
That's a shame. OK. I guess I'll have to do it the hard way and install
VC++ Express.
On 12/09/06, Jean-Sebastien Delfino (JIRA) tuscany-dev@ws.apache.org
wrote:
[
http://issues.apache.org/jira/browse/TUSCANY-719?page=comments#action_12434304]
Jean-Sebastien Delfino commented on TUSCANY-719:
Hi Geoff,
I tried your patch on Windows / VC++ express 2005 and got the same
exception as before: incompatible list iterator
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Priority: Minor
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...}
}) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...}
}) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible);
There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end ())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually
a
sure way to shoot yourself in the foot :) so I may be wrong but I
sense
a bug somewhere in this loop...
--
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
Re: Exception in SDO runtime on Windows, was: [C++] windows build system
Hi. I've created JIRA 719 describing this issue and attached the patch file to it. Geoff. On 12/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi Geoff, Thanks! I'm now ready to test again on Windows with VC++ express 2005, but for some reason I can't get the attachment out of this email. Could you please attach it to a JIRA issue, or can it be committed directly if as you say it doesn't do any harm? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request for Project Ideas for M.Sc Students
I've been talking to the Computing Lab at the University of Oxford about various ways in which Tuscany might be useful to them. One subject that came up was that we could offer project work to their part-time M.Sc students ie students that are typically already working as full time software developers. The project is officially supposed to take 200 hours of effort, including writing a dissertation which is the thing that is actually assessed towards the degree. In practice, most students spend far longer than that, typically three times as much. Therefore, I would estimate that we could propose projects that represent about 4-6 weeks of development effort. This is an opportunity for us to attract developers to Tuscany and at the same time raise its profile with a variety of employers. If anyone has any suggestions please post them as replies to this note or contact me directly. Please bear in mind that the students will not necessarily have any knowledge of SOA or Tuscany and may well need support - to get started at least. Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in SDO runtime on Windows, was: [C++] windows build system
That code is called frequently in the SDo test suite so I've been stepping
through it in the debugger to try to get a feel for what it is doing. At the
moment the execution sequence I'm seeing makes no sense. If I step over the
line
unset((*i).first);
I'd expect to reach the if statement on the following line. In fact the
debugger jumps to the
PropertyValueMap::iterator i = PropertyValues.begin();
which doesn't make much sense. This is true whether I use the Microsoft or
stdcxx libraries. Since this is happening in a destructor I'm wondering if
maybe something has been deallocated too soon. Anyway,
1. I can't immediately see anything wrong with the use of the iterator
2. I'm looking into it.
Geoff.
On 07/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
Jean-Sebastian,
By an odd coincidence I'm currently looking at a list iterator bug in SDO
that is exposed when I build against the stdcxx library rather than the
standard Microsoft one. Is thsi issue urgent? If possible I'd like to
re-visit your case after I've resolved the stdcxx one (hopefully later
today) By then I might understand it all :-)
On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
[snip]
I just tried it and was able to import our VC7 solution into it. I ran
into two issues:
- A minor issue, I had to remove the ODBC libraries from the link
configuration
- A more serious issue, the SDO runtime breaks with exceptions
complaining about incompatible list iterators in
DataObjectImpl::~DataObjectImpl()
This is probably easy to fix - although I have no idea how to fix it
:)
Geoff,
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin ();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
Could you please take a look and see if there's a quick fix for this?
Thanks.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in SDO runtime on Windows, was: [C++] windows build system
Jean-Sebastian,I've stepped through the code and I believe the problem arises because of an incorrect check for a reference counted pointer being null. However, I can't reproduce this particular problem so could you try applying the patch that I've attached to this note and let me know if it helps? I've run it against the usual SDO test suite so at least it shouldn't do any harm.
Geoff.On 08/09/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
That code is called frequently in the SDo test suite so I've been stepping through it in the debugger to try to get a feel for what it is doing. At the moment the execution sequence I'm seeing makes no sense. If I step over the line
unset((*i).first);I'd expect to reach the if statement on the following line. In fact the debugger jumps to the PropertyValueMap::iterator i = PropertyValues.begin();
which doesn't make much sense. This is true whether I use the Microsoft or stdcxx libraries. Since this is happening in a destructor I'm wondering if maybe something has been deallocated too soon. Anyway,
1. I can't immediately see anything wrong with the use of the iterator2. I'm looking into it.Geoff.On 07/09/06,
Geoffrey Winn
[EMAIL PROTECTED] wrote:
Jean-Sebastian,By an odd coincidence I'm currently looking at a list iterator bug in SDO that is exposed when I build against the stdcxx library rather than the standard Microsoft one. Is thsi issue urgent? If possible I'd like to re-visit your case after I've resolved the stdcxx one (hopefully later today) By then I might understand it all :-)
On 07/09/06, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:[snip] I just tried it and was able to import our VC7 solution into it. I ran into two issues: - A minor issue, I had to remove the ODBC libraries from the link
configuration - A more serious issue, the SDO runtime breaks with exceptions complaining about incompatible list iterators in DataObjectImpl::~DataObjectImpl() This is probably easy to fix - although I have no idea how to fix it :)
Geoff,Here's the Exception and call stack I'm getting from sdo_test onWindows, built with VC++ Express 2005: msvcp80d.dll!104f9961() [Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll] tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1::_Compat(conststd::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} })Line309 + 0x17 bytesC++tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1 _Right={first=3452816845 second={...} })Line290C++ tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++ tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deletingdestructor'()+ 0x2b bytesC++ tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()Line
69 + 0x4c bytesC++sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()Line 133 + 0x15 bytesC++ sdo_test.exe!sdotest::scopetest()Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018)Line 48 +0x5 bytesC++ sdo_test.exe!__tmainCRTStartup()Line 586 + 0x19 bytesC sdo_test.exe!mainCRTStartup()Line 403C
The exception is raised in list.cpp - line 309: #if _HAS_ITERATOR_DEBUGGINGvoid _Compat(const _Myt_iter _Right) const{// test for compatible iterator pairif (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{_DEBUG_ERROR(list iterators incompatible); There_SCL_SECURE_TRAITS_INVALID_ARGUMENT;}}This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();while (i != PropertyValues.end()){unset((*i).first);if (i == PropertyValues.begin())-- There
{// unset has not removed the item from the list - do it// here insteadPropertyValues.erase(i);}i = PropertyValues.begin
();}And I am a little puzzled by the code in the above loop... Although Ididn't spend much time trying to grasp the logic here, and I have notbeen playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually asure way to shoot yourself in the foot :) so I may be wrong but I sensea bug somewhere in this loop...Could you please take a look and see if there's a quick fix for this?
Thanks.--Jean-Sebastien-To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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
I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/lastName/customer I have no XSD for this document, and don't want to have one or have to define specific SDO types for it. I just want to load this XML into an SDO DataObject. XMLDocumentPtr doc = XMLHelper::load(xml); gives me an XMLDocumentPtr with no root DataObject. char* xml = XMLHelper::save(doc); gives me this: ?xml version=1.0 encoding=UTF-8? Is this supported by our SDO/C++ implementation? or is it a bug? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO for C++] How to integrate stdcxx as a build option?
I've built SDO for C++ using the Apache stdcxx C++ library on Windows XP. Interstingly it does require a few code changes which I will submit as a patch since they are fixing latent bugs in the current source. However, this leaves the question of how to modify the build to allow stdcxx as an option. For the MSVC build it seems to me that the best option is to create two additional configurations derived from the existing Debug and Release configurations but with the necessary changes to build against the debug or release versions of stdcxx. I'll also update the build instructions to explain these new options. On Linux I'm assuming I can adapt the makefiles to use stdcxx if some environment variable is defined eg one that supplies the location of the stdcxx library. Does anyone have a better ideas? Geoff.
Re: [C++] windows build system
The dependence on MSVC struck me as odd for an open source project when I first saw it but I was reluctant to try to alter something that basically works. I don't think going to the Express Edition helps much since we would still be dependent on a Microsoft product - even if it is free. I think it is better to provide a command line build (as we already do on Linux) as the definitive way to build the product and then anyone who wants to can adapt their favourite IDE to work with that. So I vote for option 2. On 04/09/06, Simon Laws [EMAIL PROTECTED] wrote: Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. Thoughts? Simon
Re: [SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
OK. That's pretty conclusive. I'll raise a JIRA for it and implement option 2. Geoff. On 30/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/08/06, Andrew Borley [EMAIL PROTECTED] wrote: On 8/30/06, Geoffrey Winn [EMAIL PROTECTED] wrote: snip. Using the Apache stdcxx library instead would provide us with a number of benefits Agreed. +1 for this. yup! The one difficulty is that once SDO links against the stdcxx library then all users of SDO must also do so. I think this gives us two options 1. Just do it, and live with the consequences. In this case we will (one way or another) pre-req stdcxx on all platforms, and all users of SDO for C++ will be required to use stdcxx as their C++ standard library. 2. Create a build time switch that chooses between whatever the platform offers (ie the current arrangement) and stdcxx. Presumably defaulting to the current arrangement. I prefer option 2 but obviously it somewhat complicates our build process and perhaps more seriously adds another complication to our test cases. What does the team think? My preference is also for option 2 as it gives our users more choice. However, we may find ourselves #ifdef-ing chunks of code out to get around the aforementioned differences in libraries (see Pete's map problem on Windows yesterday..) which will make code less readable, etc. I think starting this with the SDO codebase is a good idea, as this is a relatively standalone set of code, and will give us a good idea what the issues are with this approach. Defintiely option 2! A side question - SDO has a couple of pre-reqs (libxml2, etc) - will these need to be rebuilt against stdcxx as well? libxml2 is C rather than c++ so I don't think this is an issue. Same for Axis2C for the sdo_axiom utility. Cheers, -- Pete Generall I +1 the move to stdcxx and specifically to option 2 because... In PHP SDO land, which of course uses Tuscany SDO, we tend to have faily autonomous builds, i.e. we expect our users to be able to download the SDO package and build it without having to download too much other stuff. At least other stuff that isn't already known to the PHP build system . We already depend on libxml2, iconv zlib but these are generally available in linux at stable versions. If we add a mandatory dependency on the apache incubator version of stdxx then we have added another barrier to entry as there is another packge to download that people may not be familiar with and may cause clashes with other extensions that use other solutions. We won't know until we try it. It may also cause problems for the automatic windows build that takes place on the PECL servers outside of our control. I don't really know the details of this though so would have to look into it. Simon +1 for option 2 as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO for C++] Opinions Requested: Adopting stdcxx as C++ library
There is an Apache incubator project to develop an implementation of the standard C++ library (their web site is here http://incubator.apache.org/stdcxxhttp://incubator.apache.org/stdcxx/#platforms). Currently, in SDO for C++, we use the library provided by whichever platform we happen to run on. Using the Apache stdcxx library instead would provide us with a number of benefits - It is available on a wide range of platforms - It is the same implementation on all of them (so avoids obscure bugs from slight differences in C++ libraries) - It is open source so we can contribute fixes rather than writing around problems. - We become better citizens of the Apache community The one difficulty is that once SDO links against the stdcxx library then all users of SDO must also do so. I think this gives us two options 1. Just do it, and live with the consequences. In this case we will (one way or another) pre-req stdcxx on all platforms, and all users of SDO for C++ will be required to use stdcxx as their C++ standard library. 2. Create a build time switch that chooses between whatever the platform offers (ie the current arrangement) and stdcxx. Presumably defaulting to the current arrangement. I prefer option 2 but obviously it somewhat complicates our build process and perhaps more seriously adds another complication to our test cases. What does the team think? Geoff.
Re: [C++] Build instructions on Web site
Yes, definitely. Would it be worth adding them to the Wiki rather than the web page? That type of setup information tends to change and having it on the Wiki makes it wasier to keep up to date. Alternatively, add it to the website with a pointer to the Wiki for recent changes (or some such). Geoff. On 29/08/06, Andrew Borley [EMAIL PROTECTED] wrote: I think these would be a good addition to our docs. Probably best under a Development - Getting Started page rather than How to build, as they're about more than just building Tuscany C++. Andy On 8/28/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Would it make sense to publish this: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05276.html and this: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05379.html on a How to build page on the Tuscany C++ Web site? Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Creating an SDO DataObject for the properties of a component
Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Geoff. On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Sebastien, I'm fixing this. It shouldn't take long. Cheers, On 22/08/06, Pete Robbins [EMAIL PROTECTED] wrote: ah! On 22/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It doesn't work at all now. With SCDL 0.9 a component declaration looked like that: component properties v:Fredabc/v:Fred v:Joexyz/v:Joe v:Joetuv/v:Joe /properties /component The DataObject loaded from that looked exactly like what the client Cpp code expected, allowing you to code ComponentContext.getProperties()-getCString(Fred)... SCDL 0.95 now looks pretty different: component property name=Fredabc/property property name=Joexyz/property property name=Joetuv/property /component ... missing the convenient properties parent element and in a very different form now. I'm guessing that we don't want the client code to change, so we need to massage the DataObject loaded from SCDL to look like what the client code wants to see. The other thing is that we should use the property types specified in the component type instead of guessing the types from the instance properties in the component declaration. So I'm basically trying to fix ModelLoader to created the expected DataObject from what we get from SCDL. In the SupplyChain scenario I have multiple Manufacturer and Warehouse components, same implementation but configured with different properties so I need to get this property stuff working... Ok I understand the problem. I wasn't up to date with the latest definition of properties. If the current interface to properties is not workable then we can always feed that back to the spec group. Anyho... I think what we need to do is 1)create a DataFactory for the properties and populate it with the types required for the properties (basic xml types will be there by default but any user defined complex types will have to be defined in a schema somewhere so lets stick to simple types for now). 2) When loading the definitions of the properties from the componentType we need to create a new SDO Type for properties associated with this component and add it to the DataFactory. So we would do something like: dataFactory-addType(someNamespace, componentProperties, ) dataFactory-addPropertyToType((propertyName, propType for each of the properties defined) 3) create a DO of someNamespace, componentProperties type and save the DOPtr in the Component defintion in the model 4) For each property set propertyDO-set(propertyName, value) 5) ComponentContext::GetProperties will return the propertyDO from the Component voila! So we need to create a datafactory per componentType I think. -- Pete Cool, Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Creating an SDO DataObject for the properties of a component
Oh I give up! I meant DataFactoryImpl not DataObjectImpl in the previous post. Regards, Geoff. On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Pete, The DataObjectImpl class has a variety of public setDefault methods that will set a default value for a property of a type. Is that what you a looking for? Also, I fumbled the JIRA reference earlier. The JIRA to add a flexible type system is TUSCANY-546 Regards, Geoff. On 23/08/06, Pete Robbins [EMAIL PROTECTED] wrote: On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Exactly! However my brain let me down as when I went to check the code I had already coded it this way ;-) What we do need is a way of setting the default value for a type. Maybe you can enlighten me on what I have to do. Is there code to handle default values in SDO? Cheers, -- Pete
Re: [SDO for C++} Review of JIRA status
Pete, Thanks for that, all the ones with applied patches have been closed. That leaves four with patches waiting to be applied 490: patch submitted but not yet applied 496: patch submitted but not yet applied 539: patch submitted but not yet applied 553: patch submitted but not yet applied Could you look at those too? Thanks in advance. Geoff. On 04/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, I'll go through, verify, then close the Jiras that are fixed. I'll take a look at the patches that have not been applied as well. Cheers,
[SDO for C++} Review of JIRA status
We currently have 48 JIRAs for SDO for C++ marked as unresolved. I've looked through the list and in fact 14 of them have been resolved in one way or another, as follows. 255: obsolete following M1 documentation improvements 273: patch has been applied 404: patch has been applied 443: patch has been applied 456: patch has been applied 459: patch has been applied 476: patch has been applied 490: patch submitted but not yet applied 496: patch submitted but not yet applied 522: resolved during M1 development 523: resolved during M1 development 529: patch has been applied 539: patch submitted but not yet applied 553: patch submitted but not yet applied Of these, 10 just need to be marked as resolved and the other 4 need patches to be applied. Can anyone help out here, since for relatively little effort we can get the JIRA backlog down to 34? Thanks in advance. Geoff.
Re: Rationale for SDO DataType Conversions
Thanks. I take the point about convenience. I think what was puzzling me was that in a number of cases there isn't any convenience. No one in the real world is ever going to do getByte on a value that was stored as a Double. But having conversions like that in the spec just clutters both the spec and the implementation. I'm not objecting to all conversions. As I said in the base note, some make perfect sense. I was just puzzled by the fact that some of the ones that SDO offers don't really deliver any value (that I can see) to the user and yet they add burden for the developers. I'll ask this in the spec mailing list as Frank suggests. Geoff. On 20/07/06, Yang ZHONG [EMAIL PROTECTED] wrote: Geoff, while providing convenience as Frank explains, the spec doesn't prevent users from converting themselves. e.g. a user can always converts from double to byte then calls setByte. Are you proposing to always force users to convert and setXxx fails with mismatched Type? On 7/20/06, Frank Budinsky [EMAIL PROTECTED] wrote: Geoff, I don't really know the answer, but my guess is that it's simply a matter of trying to provide as much convenience as possible. I think you should ask this question on the SDO spec collaboration mailing list. Frank. Geoffrey Winn [EMAIL PROTECTED] wrote on 07/20/2006 08:36:09 AM: This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff. -- Yang ZHONG
Rationale for SDO DataType Conversions
This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff.
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
I've downloaded the RC-3b Windows SDO source distribution. The SDO runtime and test projects build and run just fine, and as others have said, the documentation is much clearer now. Thanks. I give this candidate a +1 as well. I went on to try the samples project and in that case there are a couple of places where the documentation is a bit misleading. I'll post a separate note with some suggestions for how I think it could be improved but I don't think that has any bearing on this release. Geoff. On 19/07/06, Edward Slattery [EMAIL PROTECTED] wrote: Ive tested the vc7 and vc6 builds in debug and release modes. All works fine except three minor points which have been raised as JIRAs: 1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe 2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be Client.pdb 3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need a dot moved in the line: if .Debug == %1. to if Debug. == %1. Otherwise the deploy always copies the Release Dll, not the Debug dll. I think these are all trivial problems with easy solutions and the JIRAs describe the solutions, so I give this candidate a +1 On 19/07/06, Andrew Borley [EMAIL PROTECTED] wrote: Just tested the binaries on WinXP and Fedora Core1. All happy. +1 for release Andy On 7/18/06, David Wheeler [EMAIL PROTECTED] wrote: I just installed the linux binary version onto ubuntu 6. Calculator sample works fine. -David Wheeler On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have refreshed the distros. Please vote on the release candidate available here: http://people.apache.org/~robbinspg/RC-3b Apologies for any inconvenience. Cheers, -- Pete
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Looking at the GettingStarted page for the Tuscany SDO C++ Samples, I'd like to suggest the following In the section Building the Samples on Windows The TUSCANY_SDOCPP environment variable should be set to path to installed Tuscany SDO\deploy Bullet point 3 should start with Build the source, either via the Visual Studio 6 project at tuscany_sdo_install_dir\samples\ides\devstudio6\projects\misc\misc.dsw ... In the section Running the Samples on Windows The first sentence might be better as Ensure that tuscany_sdo_install_dir\bin is included in the PATH environment variable before launching the IDE. Geoff.
Re: [jira] Created: (TUSCANY-529) Access violation in XMLHelperImpl::save
I'll look at this tomorrow, since it is obviously in my code.
Regards,
Geoff.
On 10/07/06, Caroline Maynard (JIRA) tuscany-dev@ws.apache.org wrote:
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]
Re: C++ M1 Release Candidate
Hi Pete, I found one issue. I used VC6 to attempt to build SDO and I get some problems during the copyout. I'll raise a JIRA for this. Linking... Creating library ..\..\..\runtime\core\Release/tuscany_sdo.lib and object ..\..\..\runtime\core\Release/tuscany_sdo.exp copyout 1 file(s) copied. 1 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. The system cannot find the path specified. 0 file(s) copied. Error executing c:\windows\system32\cmd.exe. tuscany_sdo.dll - 1 error(s), 0 warning(s) Regards, Geoff.
Re: C++ M1 Release Candidate
Not yet, but I will do. I managed to build successfully in VC6 by leaving sdo_test and Win32 Debug as the active configuration and doing rebuild all. After that I tried to run the tests by just pressing the F5 button and although the tests do run successfully I had to step through a mass of break points that, I assume, were checked in with the project file. I'll raise a JIRA for that too. Regards, Geoff. On 07/07/06, Pete Robbins [EMAIL PROTECTED] wrote: That looks like output from the visual studio build. Did you try the command line? Cheers, -- Pete
Re: Email versus IRC
For what it's worth, I like that approach too. I'm with Pete on this, in general I dislike IRC, although I can see there are times when it is useful. I particularly like the idea that the subjects for the regular IRC chat should be announced in advance as far as possible. I think that will help a lot. Regards, Geoff. On 06/07/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I'd like to see if I can recap where this thread went. There seem to be two sets of opinion: 1) that regular scheduled chats are helpful 2) that impromptu, unscheduled chats are helpful In light of this, I'd like to propose the following IRC policy for the project: == We will hold a regular scheduled chat at the current time (15:30GMT every Monday) to discuss non-urgent things that people may be interested in. Subjects should be posted to the list in advance so that people can make a decision on whether to attend; attendance is encouraged but optional. The folk that show up get to choose what is discussed. We will also hold pre-announced chats at other times so try and bring closure to issues that seem to be dragging on in email threads. The point of these is to come to a decision and such outcomes must be posted to the list for all to review. It is the discussion on the list that is binding. In general we will encourage community members to hang out on the IRC channel so that anyone can hold an impromptu discussion with folk that happen to be around. We especially encourage committers to be available so that new users have a way to reach someone. Any decisions should be summarized to the list. == I hope that captures everyone's thoughts and if so I'd suggest we put it on the website. If not, how about meeting on IRC to close this out? -- Jeremy On Jul 5, 2006, at 3:04 AM, ant elder wrote: There's a thread going on over on incubator-general about the use of IRC: http://marc.theaimsgroup.com/?t=11511128601r=1w=2 Are people happy with having our current weekly hour long IRC chat? I find the chat a useful way to find whats going on and gauge peoples opinions. A 1 hour chat isn't so long that its hard to read the chat log, we could probably do better at providing a summary of what was said, and maybe post the log and summary on the wiki so its easier to find. So I think the current chat is useful and works ok but we can change this if others don't like it. Currently the chat focus has been primarily Java SCA, should we try and include C++ or SDO or DAS more? Or have separate extra chats for those? Often the chat is one long rambling conversation, should we try to be more structured and have a set 10 minutes for this, 10 minutes for that type of thing to just get a regular status and have any followup discussion on the mailing list? Is the 15:30GMT on Monday time slot ok? What do you think? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Publish Tuscany C++ M1 release
I'll be around on the mailing list but not IRC. Me too. Geoff.
Re: C++ M1 Release Candidate
I built the SDO release from the command line using build.cmd as it says in the INSTALL file and that worked without apparent error. At this point I would like to run the same set of tests that I would normally run from the Visual Studio build ie the sdo_test project, but I can't see how to do that. Does the test program get built from the command line? Thanks, Geoff.
Re: Whats required to become a Tuscany Committer?
I assume that a committer, once elected, is active in the entire code base. This bothers me a little. I currently work entirely in the C++ implementation and do almost nothing with the Java code. I think I could easily reach a situation where I have done all the things required of a committer (whatever they turn out to be) in C++ land and nevertheless be largely ignorant of the Java code base. In fairness, I can also see the mirror image happening to someone else. Does that matter? Geoff. On 04/07/06, Jim Marino [EMAIL PROTECTED] wrote: Also forgot to mention the wiki is a god place to add scenarios you are interested in either from an end-user perspective or as potential implementor: http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios Jim On Jul 4, 2006, at 3:44 AM, Jim Marino wrote: JIRA also can handle documentation, website, etc. bugs and enhancements if you want the proverbial notches on the bedpost ;-) On Jul 4, 2006, at 3:38 AM, kelvin goodson wrote: +1 from me on taking into account diverse activities, but I must declare a vested interest. I'm encouraged by this discussion, since I'd like to become a committer, and have had that niggling feeling that if it's notches on the jira bedpost that are the primary measure, then it's going to take a while longer than I had hoped. I have been doing a number of things which are material contributions which haven't resulted in direct code updates. Regards, Kelvin. On 7/3/06, Jim Marino [EMAIL PROTECTED] wrote: On Jul 3, 2006, at 1:35 AM, ant elder wrote: There's a number of people who've been contributing patches to Tuscany for some time now so we should start thinking about what it takes to be made a committer. An old Incubator webpage had this to say (the page isn't available right now): If a developer has contributed a significant number of high- quality patches, is interested in continuing the contribution, has demonstrated the ability to work well with others under the Apache guidelines, it may be proposed to grant that developer commit access. I think it should take a bit more than code to be made a committer - participation in mailing list discussions, the weekly IRC chats, votes, and things like that. Agree with being more than just code. One thing though I would say is people shouldn't be required to do all things, i.e. some may not be able to make IRC or just not feel comfortable speaking up. I do think, though, it's really important to participate in things other than code such as the mailing lists. I do however, think we should weight things towards material contributions (not just code, it could be documentation, the web site, etc.) when deciding on commitership. And its not just code, high-quality patches could include things for documentation or web site. Right now i think it shouldn't be to hard to become a committer, if someone has been demonstrating an interest in the project for a while we should encourage that. It seems to me there are two types of commiters. Those that make substantial contributions over a shorter period of time and those that make smaller, incremental contributions over a longer-time frame. I think we should accommodate both and perhaps outline it in documentation that could be put on the web site. For newbies coming to the project, it would be nice to be able to read what was expected to become a commiter. Ant, are you willing to take a stab at doing this since you've been making some good points w.r.t the community aspects of commitership? Jim What do others think? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ runtime - build error on Linux
Jean-Sebastian, Hi. I don't have access to an RHEL 4 system. Could you try one thing for me? The error you report is coming from calls like dor-setLong(long, 0x); and the signature for the setLong method specifies int64 for the second argument. I'm wondering if the problem is that the 0x value is being treated as a 32 bit constant rather than 64. Could you try appending LL to the constant value eg dor-setLong(long, 0xLL); If I read the docs correctly that will specify that the constant is 64 bit. Thanks in advance, Geoff.
Re: SDO C++ runtime - build error on Linux
On 06/06/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here's the error I'm getting: sdotest.cpp: In static member function `static int sdotest::conversiontest()': sdotest.cpp:1135: error: integer constant is too large for long type sdotest.cpp: In static member function `static int sdotest::maintest()': sdotest.cpp:2569: error: integer constant is too large for long type sdotest.cpp:2575: error: integer constant is too large for long type make[5]: *** [sdotest.o] Error 1 On line 1135, in the following statement: dor-setLong(long, 0x); the constant is too big for a long. Same problem on lines 2569 and 2575. I suggest adding an import limits.h and using LONG_MAX to be more portable. I think there may be more to it. Looking at the block of code that contains 1135 we can see dor-setByte(byte,20); dor-setCharacter(character, 1000); dor-setShort(short, (short)12345678); dor-setInteger(integer, 87654321); dor-setLong(long, 0x); dor-setFloat(float, (float)12345.678); dor-setDouble(double, 1234567.891); Most of these are not boundary cases, so I wonder if the setting of long was expected to fit in 64 bits or maybe it is supposed to trigger a runtime overflow error as part of the test. Anyway, I'll look into it. As a minimum I'll raise a JIRA and make the change you suggest to fix the build error. Regards, Geoff.
Re: [SDO C++] Representing strings as objects rather than C style character pointers
On 06/06/06, Geoffrey Winn [EMAIL PROTECTED] wrote: The more difficult case arises when a method returns a string value. For example, const char* getName() We can't overload this, so we have two alternatives. I should have known better. There is of course at least one other way. We could introduce a new overloaded method where the return value is one of the parameters, for example, void
Re: [SDO C++] Representing strings as objects rather than C style character pointers
On 06/06/06, Geoffrey Winn [EMAIL PROTECTED] wrote: The more difficult case arises when a method returns a string value. For example, const char* getName() We can't overload this, so we have two alternatives. What I was trying to write in my previous note was ... I should have known better. There is of course at least one other way. We could introduce a new overloaded method where the return value is one of the parameters, for example, void getName(SDOString name) This avoids introducing new method names and leaves existing users unaffected, but the eventual change to using this type of method will require a larger code change and it also makes the old and new methods rather inconsistent. Regards, Geoff.
Re: Cross language interop testing
Simon, On 26/05/06, Simon Laws [EMAIL PROTECTED] wrote: A long time ago I posted about doing some interoperability testing. I've got back to this now and I've put some ideas about how we do this on the wiki, here (http://wiki.apache.org/ws/Tuscany/Interop). ... So if we lay these tests out in order I would expect to do the following in Java, C++ and PHP where the feature is supported 1.1. Read an XML file and write it out again 1.2. Read an XML file and write out an XSD file 2.1 Read and write Records from a database 3.1 Read XML and write Axiom 3.2 Read Axiom and write XML I see the sense in 1.1 However, I'm not so sure about 1.2. Presumably that is saying that we read an XML instance and in the process of creating an SDO for it we have also defined a variety of types, properties and so on to describe it. Then we use that information to generate an XSD. This is pretty much the same as inspecting an XML instance document and then writing an XSD for it. It isn't obvious to me that different implementations would necessarily generate the same XSD in these cases. I'm willing to be convinced; I'm just not sure that it's fair to expect that different implementations will generate the same XSD when what they were doing was populating a model with whatever they needed to read an XML instance. Regards Geoff.
Re: C++ Release
Pete, another +1 for the release and IRC chat
Introduction
Hello, my name is Geoff Winn. I've recently started looking at the SDO for C++ code having previously worked on a variety of message passing and broking systems. Regards Geoff.
[C++] Options for string handling in SDO
Much of the string data in SDO for C++ is handled as C style, null-terminated arrays of characters. I'm trying to move that to a style where most string data is represented as true string objects. The painless (less painful) way to do that is to leave the externals alone and to introduce string objects internally, converting between string objects and C-style strings at the earliest convenient point when called and the last convenient point on return. The alternative is to extend the public interface with extra methods that take string objects as arguments rather than C-style strings. In this case we would have to publicise a new string class as well. Does anyone have any opinions on which of these is preferable (or any other alternatives)? We could of course make the internal only changes first and add an extended public interface later. Regards, Geoff.
What is the correct copyright statement?
Looking at the existing source file (C++ in my case) they all seem to contain a copyright statement as follows. Copyright 2005 The Apache Software Foundation or its licensors, as applicable. If I want to create a new file do I include that exact statement or the 2006 variant of it? Similarly, if I modify an existing file, do I need to modify the copyright line. Apologies for making an issue of this, but in a previous life I spent several days dealing with lawyers over what constituted a correct copyright statement. Regards, Geoff.
Re: [C++] Options for string handling in SDO
To pick up on both these responses. On 12/05/06, Simon Laws [EMAIL PROTECTED] wrote: Hi Geoff When you talk about string objects do you mean instances of the ANSI string class (basic_string) or is this a special SDO designed string class? I didn't include enough detail. I meant a class that we will define that will be a wrapper (prety much) for the basic_string class. 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. You are right. It wasn't my intention to remove the existing interface. My question was whether to make the changes purely to the internals (so no user visible use of string objects at all) or to add (as you describe) additional methods that take string objects as arguments. On 12/05/06, Edward Slattery [EMAIL PROTECTED] wrote: FWIW I would think of creating an SDO string class which can be constructed from a char* or a std::string, and make the methods use the SDO string, such that either char* or std::string can be input. Makes sense to me. I'll go that route. Geoff.
