Re: [C++] XMLDocument has no root object

I'll take a look at this. On 16/05/07, Andy Grove <[EMAIL PROTECTED]> wrote: I'm now trying to parse a document that does have a schema and I'm still running into the same problem - my document has no root object and no root element name. Any help figuring out why this isn't working would be

Re: [C++] XMLDocument has no root object

t match! I guess the question is should trailing (or leading) spaces be ignored? Cheers, On 16/05/07, Pete Robbins <[EMAIL PROTECTED]> wrote: I'll take a look at this. On 16/05/07, Andy Grove <[EMAIL PROTECTED]> wrote: > > > I'm now trying to parse a document that

Re: [C++] XMLDocument has no root object

On 17/05/07, Pete Robbins <[EMAIL PROTECTED]> wrote: OK... sorted. The problem is that your schema targetNamespace is "http://www.roguewave.com/uri/catalog/ " but the document namspace uri is "http://www.roguewave.com/uri/catalog/"; Spot the difference? There is

Re: [SDO C++] DataFactory::generateInterface() function problem

Adriano, this isn't so much a bug as unsupported function. DataFactory::generateInterface() is not part of the spec (I believe) and was an old experiment in supporting static SDOs. As far as I am aware the code has never been tested. I'm pretty sure I'd removed it before but it looks like it's st

Re: Tuscany C# service implementation.

James, there is currently no work going on with C# in Tuscany. Are you thinking of a C# language binding on the Tuscany "Native" runtime core? Cheers, On 11/06/07, James Hart <[EMAIL PROTECTED]> wrote: Hi, Has there been any work on developing a C# service implementation for Tuscany's C++ C&

Re: Does Tuscany SDO C++ support open content properties?

Open content properties are supported in the SDO C++ implementation. I'm not sure if support is quite up to "spec" level but it's fairly close. Deserializing an xml document to SDO without schema is probably "not quite there" and the XMLHelper and parser code would need looking at to make this wo

Re: Does Tuscany SDO C++ support open content properties?

g at is the ability to parse an XML document where types have not been defined. From memory, whenever I have attempted this the XMLDocument.getRootDataObject() method returns NULL. Thanks, Andy. -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wed 13/06/2007 12:57

Re: Finding the .componentType file

In Tuscany C++ the language implementation (C++, Python, etc) defines the location of the .componentType file. For C++ we use the header=".." and path=" .." attributes of implementation.cpp: in fred.composite: The implementation library is abc/xyz/Calcualtor.dll (or abc/xyz/libCalculator.so fo

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

Brady, Welcome aboard! The best way to proceed is to open a Jira ( https://issues.apache.org/jira/browse/TUSCANY) describing what you are trying to achieve then attach a patch to the Jira. It's usually a good idea to post on tuscany_dev when you submit a patch as some of us filter off Jira messag

Re: [C++] SDO - preventing SDO from loading schema across the network

Tricky one. My understanding is that s should be for unique namespaces. adds types to the same namespace. So I think if you restrict this logic to the elements you should be ok. Cheers, On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote: Posting to tuscany and php lists I raised a bug (

Re: [C++] SDO - preventing SDO from loading schema across the network

I just added a comment to the Jira on how I think it should be fixed. Cheers, On 20/06/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Tricky one. My understanding is that s should be for unique namespaces. adds types to the same namespace. So I think if you restrict this logic to the el

Re: [C++] SDO - preventing SDO from loading schema across the network

Having just browsed the code in parseIfNot I would be inclined to rewrite it! It looks like it is over complex and news up a SDOSchemaSax2Parser that is never freed. I'll maybe take a look at getting that into shape in the next week. Cheers, On 20/06/07, Simon Laws <[EMAIL PROTECTED]> wrote:

Re: [C++] SDO - preventing SDO from loading schema across the network

oh.. they are freed later on in the ParsedLocations destructor ??? OK. I clearly need to look at this when more awake :-( On 20/06/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Having just browsed the code in parseIfNot I would be inclined to rewrite it! It looks like it is over complex an

Re: C++ SDO spec compliance/portability: SDORuntimeException

Michael, An interesting set of questions! I'm not convinced that adding methods to the spec api classes is a compliance issue (in fact it may be impossible to implement without modifying the spec apis ... constructors etc.) but it could be a portability issue if it is not clear that the methods a

Re: SDO spec compliance/portability: Type

I guess this one could be moved as it is only there as a convenience. Cheers, On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: Hi, The Tuscany SDO C++ class Type has this public member which does not appear in the C++ 2.1 specification: static SDO_API const SDOString SDOTypeNamespaceUR

Re: SDO spec compliance/portability: Type enums

the num_type is just a convenient way to know the extent of an enum and is common practice. I guess the OpenDataObjectType must be a Tuscany specific extension to handle open types. I'd need to do some research to determine if this is missing from the spec or can be removed. Please raise a Jira f

Re: C++ SDO spec portability: RefCountingPointer

Michael, I strongly suspect that the operator T*() ws put in for a good reason. It may be a good idea to remove this but it may be non-trivial. The ostream operator << is very useful and there is a default implementation in RefCountingObject so that objects inheriting from RefCounting object do n

SDO C++ compliance with 2.1 spec - help needed

As is shown by the analysis that Michael Yoder is doing, comparing SDO 2.1spec API vs Tuscany SDO C++ API, it is clear that there will be a fair amount of work involved in getting the Tuscany code in to shape. Some changes are fairly simple but others may need wide ranging changes in the way Tusca

Re: C++ SDO spec compliance/portability: SDORuntimeException

t is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. P

Re: SDO C++ compliance with 2.1 spec - help needed

I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Cheers, On 22/06/07, Pete Robbins <[EMAIL PROTECTED]> wrote: As is shown by the analysis that Michael Yoder is doing, comparing SDO 2

Re: SDO C++ compliance with 2.1 spec - help needed

On 23/06/07, Simon Laws <[EMAIL PROTECTED]> wrote: On 6/23/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > I have created a maintenance branch */incubator/tuscany/branches/sdo- > cpp-pre2.1/* > Work towards SDO 2.1 specification compliance will continue in HEAD. > &g

Re: SDO C++ compliance with 2.1 spec - help needed

On 25/06/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: Simon Laws wrote: > On 6/23/07, Pete Robbins > <[EMAIL PROTECTED]> wrote: >> >> I have created a maintenance branch */incubator/tuscany/branches/sdo- >> cpp-pre2.1/* >> Work towards SDO 2.1 spec

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

mpl.cpp:61: error: `Utils' has not been declared TestImpl.cpp:61: error: `printDO' was not declared in this scope TestImpl.cpp:63: error: `Utils' has not been declared make[2]: *** [TestImpl.lo] Error 1 Thanks Brady Johnson Rogue Wave Software - [EMAIL PROTECT

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

e, and they also worked as expected. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 11:08 AM To: tuscany-dev@ws.apache.org

Re: [VOTE] Fuhwei Lwo for Tuscany Committer

+1 On 27/06/07, ant elder <[EMAIL PROTECTED]> wrote: +1 ...ant On 6/26/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > I'd like to propose Fuhwei Lwo as a Tuscany Committer. > > According to my gmail archive he has, since mid of 2006, posted 114 times > to > tusany-dev, 79 of those times r

Re: TuscanySCA C++: The usage of the std::map::operator[] in Composite::findWSDLDefinition() could cause problems

Good catch... now for bonus points find the many other places I've coded the same error ;-) I'll apply this. Cheers, On 27/06/07, Brady Johnson <[EMAIL PROTECTED]> wrote: The std::map operator[] will insert a blank object of type V if the key is not found in the map. The method Composite::fin

Re: TuscanySCA C++ : The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set.

On 27/06/07, Brady Johnson <[EMAIL PROTECTED]> wrote: I submit a TuscanySCA C++ JIRA for this. https://issues.apache.org/jira/browse/TUSCANY-1392 The problem is that the WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint s

Re: TuscanySCA C++ SubVersion head does not compile with TuscanySDO C++ SubVersion head nor with TuscanySDO M3

Apologies for that. I have now reverted to use IntegerType. The SCA head will now build against SDO M3. The SDO code will be undergoing some incompatible API changes to get to 2.1 spec level. We will make the changes in the SCA code to match this when the SDO code is stable. Cheers, On 02/07/07,

Re: Attaching patch for: The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set

I've applied the patch. Rather than supplying a patch for each individual file I find it easier to produce a single patch for the source tree. It's easier to apply too! Cheers, On 02/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: I attached a patch for https://issues.apache.org/jira/browse/TU

Re: TuscanySCA CPP: Enhancements to the WSDLOperation class

Brady, These changes look fine to me. Cheers, On 03/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: Currently there is no way to obtain WSDL Operation Message information as defined in a WSDL. The WSDLOperation class does have 2 attributes that seem to help serve this purpose, but they are nev

Re: Specific versions of Redhat

RHEL3 is what my linux claims to be! I assume RHEL4 is a later version? Early milestone releases of Tuscany C++ provided a binary release which was probably built on one of these platforms. From M3 we only provide a source release for linux/Mac OSX. Cheers, On 03/07/07, Brady Johnson <[EMAIL PRO

Re: Specific versions of Redhat

of course Java is write-once-run-anywhere so should be independent of platforrm ;-) On 03/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: RHEL3 is what my linux claims to be! I assume RHEL4 is a later version? Early milestone releases of Tuscany C++ provided a binary release which was pr

Re: Specific versions of Redhat

e 2 and update 4. Brady -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 4:13 PM To: tuscany-dev@ws.apache.org Subject: Re: Specific versions of Redhat of course Java is write-once-run-anywhere so should be independent of platforrm ;-) O

Re: [TuscanySCA CPP] problems trying to load services from multiple directories at once

I think that them intent is for any composites under the TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error to specify a _PATH that includes or is a subdirectory of the SYSTEM_ROOT. Maybe we could police this or change the loader to ignore duplicates from the same location.?? O

Re: SCA Toys?

Nice! please attach a patch to a Jira and I'll test/commit it. Cheers, On 11/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: I havent seen much posted about this lately. I have a "toy" for TuscanySCA C++ that will use the SCARuntime to load a service and dump out pertinent information. Also,

Re: [TuscanySCA Cpp] patch uploaded for 1422

applied Cheers, On 11/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: Hello all, I just uploaded a patch for: https://issues.apache.org/jira/browse/TUSCANY-1422 Which involves being able to better navegate an SCA model by adding std::list Composite::getComponents() I would appreciate it i

Re: SCA Toys?

ed with: https://issues.apache.org/jira/browse/TUSCANY-1422 Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message----- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 11, 2007 2:00 PM To: tuscany-dev@ws.a

[SCA Native] next release content [was: Tuscany roadmap]

We should definitely start planning some content for the next SCA Native release. On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: Is there some sort of TuscanySCA roadmap? I've looked around a bit and haven't found one. I was curious what the future plans for TuscanySCA CPP were in partic

Re: [SCA Native] next release content [was: Tuscany roadmap]

then I'll happily go along with that. Perhaps you could start this off by showing us what the build would look like for, say, cpp/sca/runtime/core ?? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message- Fr

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

The SDO HEAD will contain the ongoing development for the 2.1 spec changes. The branch was created to maintain a stable version as some of the spec changes will cause instability. I think ongoing development should continue in HEAD so we do not need an SCA branch. We just need to ensure that SCA

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

The alternative is for us to develop SCA Head against a stable (M3) version of SDO? On 13/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: The SDO HEAD will contain the ongoing development for the 2.1 spec changes. The branch was created to maintain a stable version as some of the spec c

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

at can take advantage of those changes, or is it intended just for stand-alone SDO work? I guess part of my question is whether the M4 release of either SDO or SCA will be based on the PRE-SDO21 branch, or whether both will be coming from HEAD. Thanks. David. > -Original Message- > F

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

The current state is that SCA HEAD will only build against the sdo branch or M3. The minor change was renaming IntegerType to IntType which I put in the SCA HEAD but then backed out. If everyone agrees that HEAD SCA should build against HEAD SDO I will re-apply the change. Cheers, -- Pete -

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

or option 1. +1 Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 10:42 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] Can we

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

I have applied a change (revision 556081). Now SCA HEAD requires SDO HEAD. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: SCA Toys?

I've added the patch for TUSCANY-1423 into tuscany/cpp/sca/tools now that I have moved the scagen tool to the cpp extension. I have not added this source into the build. We can use this tree to see how the ant build works??? Cheers, On 12/07/07, Pete Robbins <[EMAIL PROTECTED]>

Re: Status of C++ code generation

Andy, the static code generation was an old experiment and is not used.I have been meaning to remove it for some time as it is confusing being there. The get/setUserData was actually put in there at the request of the PHP-SDO team. I'm not sure of the details but I think they use this to maintain

Re: [SCA Native] preliminary ant build

Thanks Brady. I'll take a look at this. We will need doc as to what the dependencies are (cpptasks etc) and any configuration that is needed. Cheers, On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: For anyone interested, I uploaded another patch for this JIRA that makes it work better fo

Re: Status of C++ code generation

by SDO PHP to manage the relationship between the PHP SDO Objects and C++ SDO Objects. Earlier versions of the PHP Extension tried to manage this separately, but this solution was complex and prone to problems. I hope this helps. Regards, Graham. On 17/07/07, Pete Robbins <[EMAIL PROTECTE

Re: Status of C++ code generation

Andy, I guess you are clear to go ahead and make those changes. Cheers, On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote: Hi Pete, sounds good to me. On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > Graham, > > so if we move these methods to DataObjectImpl you

Re: [SCA Native] preliminary ant build

al ant tasks, such as antcontrib and cpptasks, should be installed > in %ANT_HOME%\lib > So place the antcontrib and cpptasks jars there. > > If you dont have write access to %ANT_HOME%\lib, do the following: > - create ${user.home}\.ant\lib > - place the jars here > > Avoid

Re: [jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types

Tuscany cpp was being developed iat the same time as the specification so it does not quite match the 0.96 spec... or the 1.0 spec. We need to work now to move everything to 1.0 level of spec. ... and yes the schema and instance docs are not valid. Thanks for raising this issue. I'll fix up the

Re: [SCA Native] preliminary ant build

e antcontrib and cpptasks jars there. If you dont have write access to %ANT_HOME%\lib, do the following: - create ${user.home}\.ant\lib - place the jars here Avoid adding optional ant tasks to your classpath, this is problematic. -----Original Message- From: Pete Robbins [mailto:[EMAIL PROTE

Re: [SCA Native] preliminary ant build

c.dir in one of the files. Rather than specifying the paths to the source code etc in the platform.properties I would prefer to set these automatically so in the top level build.xml I added: and then based other properties from this. It seemed to work! Do these changes make sense? Cheers,

Re: [SCA Native] preliminary ant build

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: I ran into a couple of issues tryingt o run this ant build. Firstly I got an error with a path x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to the fact that the property core.dir is set in the top level build.

Re: [SCA Native] preliminary ant build

lot of external dependencies need to be setup in order to proper run the build ? Once this is complete, we could try to integrate the ant build with Continuun (looks like it supports ant builds) and try to get a nightly build published for Native project as well ? On 7/18/07, Pete Robbins <[EMAIL

Re: [SCA Native] preliminary ant build

--- Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 7:08 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build I ran into

Re: [SCA Native] preliminary ant build

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > Pete, > > Thanks for trying out the ant build scripts. > > Regarding core.dir, you're right, the name will need to change. I can d

Re: [SCA Native] preliminary ant build

al Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 9:00 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote

Re: [SCA Native] preliminary ant build

; Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > > -Original Message- > From: Pete Robbins [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 9:00 AM > To: tuscany-dev@ws.apache.org > Subject: Re: [SCA Native]

Re: [SCA Native] preliminary ant build

re-reqs defined (SDO loccation, + other pre-reqs) but we should try to make this as simple as possible. Cheers, Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED

Re: [SCA Native] preliminary ant build

.h file for then, yes this just got a whole lot easier. We can do the following on the Tuscany-BaseCompiler Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message----- From: Pete R

Re: [SCA Native] preliminary ant build

gt; patch_file" from the tuscany root dir. You can disregard the tools changes. I'll look into it. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] S

Re: [SCA Native] preliminary ant build

ARNAME --- > #define PACKAGE_TARNAME "tuscany_sca_native" 102c103 < #undef PACKAGE_VERSION --- > #define PACKAGE_VERSION "1.0-incubator-M3" 105c106 < #undef STDC_HEADERS --- > #define STDC_HEADERS 1 108c109 < #undef VERSION --- > #define VERSION "1.0-incubator

Re: [SCA Native] preliminary ant build

I've taken out the references to tuscany_sca_config.h and patched the automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac as I need to kick the kids off my machine! On 19/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: Automake generates a config file with lots

Re: [SCA Native] preliminary ant build

- HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message----- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 2:44 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build I've taken out the references to tuscany_sca_config.

Re: [SCA Native] preliminary ant build

a clean extract as a base for future patches? Cheers, On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: I'll give this a go. I should be able to run it on Mac as well. Cheers, On 23/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I updated the jira1438

Re: [SCA Native] preliminary ant build

definition of the Tuscany-BaseCompiler Cheers, On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: I've applied the patch. How are you creating the patches? I had trouble applying it on Windows using ToirtoiseSVN. I've included the changes in the patch to the tools/Tuscan

Re: [SCA Native] preliminary ant build

s}"/> > > > > > > Tomorrow I'll have the python, ruby, rest, and maybe php extensions > complete. > > > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTE

Re: [SCA Native] preliminary ant build

require any of the ant infrastructure used by the individual projects. It would be very similar to the root build.xml for TuscanySCA. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto

Re: [SCA Native] SDO Build error on Linux

Works fine on all our linuxes including my RHEL... I've removed the unnecessary qualifier so you should be fine now. Cheers, On 25/07/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: if /bin/sh ../../../../../libtool --tag

Re: [SCA Native] SDO Build error on Linux

The fix is in the branch as well. Sorry I did not see that Jira. On 25/07/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: Jean-Sebastien Delfino wrote: > Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: > > if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++ > -DHA

Re: FW: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid

I'm looking at it right now! On 25/07/07, Michael Yoder <[EMAIL PROTECTED]> wrote: Hi, I uploaded a patch for C++ SDO which fixes its XML serialization to produce XML valid against schemas with elementFormDefault=true. If someone could verify and apply it that would be great. This gets the SCA

Re: [SCA Native] Test suite

I'm sure this has come up before. I will try and find out what the resolution was. On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: As I understand it, the only issue would be if we distribute LPGL software under the ASF licensing. What if we don't distribute CxxTest with Tuscany, but rath

Re: [SCA Native] next release content [was: Tuscany roadmap]

L PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 11:00 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > &

Re: [SCA Native] preliminary ant build

More good stuff. I've applied the latest patch but there are some issues. From a clean build if you just type "ant" in the top level cpp/sca directory then the build will fail on tuscany_sca_cpp because it needs to link against /lib/tuscany_sca.dll which has not yet been installed as all the "b

Re: [SCA Native] preliminary ant build

y Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > > > -Original Message- > From: Pete Robbins [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 26, 2007 12:44 AM > To: tuscany-dev@ws.apache.org > Subject: Re: [SCA Native] preli

Re: [SCA Native] preliminary ant build

l have to change the path properties > and the basedir of the root element. > > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > > -Original Message- > From: Pete Robbins [mailto:[EMAIL PROTECTED]

Re: [SCA Native] preliminary ant build

and now I've moved the core schema to cpp/sca/runtime/core/xsd On 27/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > OK.. done! runtime/core/build.xml replaces runtime/core/src/build.xml > > I'll move the xsd dir later. > > Cheers, > > On 27/07/07, Br

SDO sequenced DataObject vs XSD

A Jira (https://issues.apache.org/jira/browse/TUSCANY-1504) has been raised against the SDO C++ implementation which is saying that for a schema: http://www.w3.org/2001/XMLSchema"; xmlns:letter="http://letterSchema"; targetNamespace="http://letterSchema";>

Re: [SCA Native] preliminary ant build

hnson/tuscany_cpp/httpd-2.0.59/deploy/include > [echo] rest.apr.include.dir= /usr/include/apr-0 > [echo] > [echo] TuscanySCA ruby extension enabled > [echo] ruby.lib.dir= > /nfs/homes/bjohnson/tuscany_cpp/ruby-1.8.6/deploy/lib > [echo] ruby.include.dir= > /nfs/homes/bjohn

Re: [SCA Native] java implementation and interface schema files loaded but not used

It was simply that we were loading all the initial sca schema. So the core code loads sca.xsd but I think we should change that to specifically load the ones we need. Maybe the best thing is to load any schema in /xsd and we can just delete the java stuff. If the Native runtime wants to support Ja

Re: [SDO Native] ant build system for SDO Native

Thanks. I'll get on the case soon. I really appreciate the effort you have put in to this. Cheers, On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > Hello all, > > I just uploaded a patch for JIRA: > >https://issues.apache.org/jira/browse/TUSCANY-1509 >

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

asses (for the common use > of smart pointers). This member function is used by SCA, and raises > undesirable object lifetime and allowed operation issues. The member > function should be replaced with a safe (referenced in the below -email > thread) conversion to bool member function. &g

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

::RefCountingPointer::RefCountingPointer(void)' existing declarations 'commonj::sdo::RefCountingPointer::RefCountingPointer(const commonj::sdo::RefCountingPointer &)' 'commonj::sdo::RefCountingPointer::RefCountingPointer(T *)' Any ideas? On 07/

Re: [SDO Native] ant build system for SDO Native

table. It will probably be best to remove the existing automake and vcexpress builds at that point. Cheers, On 07/08/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > Thanks. I'll get on the case soon. > > I really appreciate the effort you have put in to this. > > Cheers,

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

b pointer for SDO classes (for the common use > of smart pointers). This member function is used by SCA, and raises > undesirable object lifetime and allowed operation issues. The member > function should be replaced with a safe (referenced in the below -email > thread) conversion t

Re: [SCA Native] preliminary ant build

I noticed that the core header files were getting installed in the wrong place: ...deploy/include/src/tuscany... rather than ...deploy/include/tuscany... etc so I fixed this. Cheers, On 07/08/2007, Pete Robbins <[EMAIL PROTECTED]> wrote: > I applied 7 today and will look at 8 now. &

Re: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API

Another great patch! Thanks! Should SDO.h only include headers for the public (i.e. spec) APIs? I think it should so things like DASValue.h should be removed. Anyone who wants to utilize the internal APIs should have to know they are doing it! What do you think? Cheers, On 10/08/07, Michael Yod

Re: [SCA Native] Tuscany SCA Native for Windows is not msvc backwards compatible

I've applied 1529 and 1530. Cheers, On 10/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > Hello all, > > I created a JIRA for this compilation issue and have already uploaded a > patch. Can someone submit it please. > > https://issues.apache.org/jira/browse/TUSCANY-1530 > > Thanks > > ---

Re: [SCA Native] java implementation and interface schema files loaded but not used

On 14/08/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > The SCA Java runtime doesn't use the XSD for the assembly or extensions at > runtime to parse the composite file. A StAX-based artifact processor is > plugged into the runtime to handle the extensions such as > implementation.java, impl

Re: [SCA Native] java implementation and interface schema files loaded but not used

On 13/08/07, David Haney <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 10, 2007 8:33 AM > > To: tuscany-dev@ws.apache.org > > Subject: Re: [SCA Native] java implementation and interface schema > file

Re: [SCA Native] Test suite is stale and hasn't been maintained for ages

I've deleted this. It has been proposed several times to remove this and I've never seen any objections. It's gone! Cheers, On 13/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I wrote a JIRA about this: >https://issues.apache.org/jira/browse/TUSCANY-1533 > > Why don't we just delete it

Re: [SCA Native] Next Release Design

Brady, sorry I haven't had too much time to comment on this but it all looks sensible and in the right direction to me. Regarding the schema loading, where you say "sca-implementation-java.xsd (loaded but ignored) " I think this means we will load this schema but as no extension is registered to

Re: FW: [jira] Updated: (TUSCANY-1366) C++ SDO spec portability: SDORuntimeException off-spec member functions

ting together and posting came > > up when doing a portability study using HydraSDO to build Tuscany SCA. > Since the SDO spec is separate from SCA, we were thinking this would be > a good goal. That seems to mean making them internal to Tuscany SDO or > taking them to the committee. > &g

[NOTICE] Brady Johnson voted as Tuscany committer

The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe,

Re: FW: [jira] Updated: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string& prop)

Applied now. Another great patch. Thanks! On 22/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > > Hi, > > I uploaded a patch for TUSCANY-1371. If someone could review and apply > it that would be great. > > Thanks, > > Michael > > -Original Message- > From: Michael Yoder (JIRA) [mailto:[

Re: FW: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class interface Type off-spec enum values

> > > > Attachments: TUSCANY-1368.txt > > > > > > C++ SDO specification class interface Type has enum values > ("OpenDataObjectType", "num_type")which are not in the specification, > and are being used externally by SCA. It would seem t

Re: FW: [jira] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject

Hi, I have applied 1368 and 1374. This patch gets conflicts with the patches I've applied. They looked reasonably straight forward to resolve but I must have done something wrong as the sdo tests crash :-( Could you do an extract from HEAD and create a new patch for this Jira? Cheers, On 25/08/

Re: [jira] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject

I applied v2 and then v2_b Cheers, On 28/08/2007, Michael Yoder (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Michael Yoder updated TUSCANY-1370: > --- > >

  1   2   3   4   5   6   7   8   9   10   >