I'll just go back to sleep now... looks like a fix has been applied for this.
On 27/09/06, Pete Robbins [EMAIL PROTECTED] wrote:
Is Jira 209 fixed? Tuscany folk would really like this one!
Cheers,
On 27/09/06, Samisa Abeysinghe [EMAIL PROTECTED]
wrote:
+1.Samisa...Dinesh Premalal wrote: Since
On 26/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Now that our SCA build is modular, how about doing something similar to
our SDO build?
What do you guys think about the following options?
--enable-axiom to make the dependency on Axis2 optional
--enable-stdcxx
any other one?
[ http://issues.apache.org/jira/browse/TUSCANY-705?page=all ]
Pete Robbins resolved TUSCANY-705.
--
Fix Version/s: Cpp-current
Resolution: Fixed
Applied Geoff's final patch.
XMLHelperImpl::createDocument() gives invalid XML when the element has
The logic for when to write xsi:type was incorrect. I have now fixed this
and re-gen'd the sdo test output files.
Cheers,
On 23/09/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jsdelfino
Date: Sat Sep 23 15:51:30 2006
New Revision: 449323
URL:
well there isn't one!
I propose that we delete the existing test in runtime/core/test (which is
basically a sample with a few bells) and replace it with a suite of unit
tests.
These should be runnable form 'make check'. I think we should have tests
organised alongside the src so we will have
thanks for that... we need Jira 29 fixed. I've posted to their list.
Cheers,
On 27/09/06, Oisin Hurley [EMAIL PROTECTED] wrote:
FYI - in case there is anything we need from them..
--oh
http://wiki.apache.org/ws/FrontPage/Axis2C/releases/0.94
or even 209 ... duh!
On 27/09/06, Pete Robbins [EMAIL PROTECTED] wrote:
thanks for that... we need Jira 29 fixed. I've posted to their list.
Cheers,
On 27/09/06, Oisin Hurley [EMAIL PROTECTED] wrote:
FYI - in case there is anything we need from them..
--oh
http://wiki.apache.org/ws
Sounds good.
On 25/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
I've checked in a change to the linux automake for C++ SCA to allow
building
of the extensions to be optional.
I've added --enable-XXX to configure where XXX is php, python, ruby.
The ./build.sh
There have been significant changes since our last C++ release so I think we
should plan for an M2 release in the next couple of weeks. We have updated
to the latest assembly model, built a basic extension mechanism and now have
extensions for Ruby, Python, PHP. Functionally this seems like good
- if we want to include this we need to add reference
property support to components and a client API (a locateService
method)
- Samples
- do we include BigBank? SupplyChain?
- Tests
- Do we want an equivalent of the sdotest app for SCA?
Andy
On 9/25/06, Pete Robbins [EMAIL PROTECTED] wrote
That sounds the right way to go. Maybe we need to rethink the extension
mechanism a bit e.g. have a generic WS binding extension with specific
implementations (Axis2C). The sca binding can have dependencies on ws
binding but it would be nice if it didn't have dependencies on a particular
That's exactly what I intended when moving the SCARuntimeException to the
CPP extension. I think we need a really good trawl of exception throwing
handling so this is a great time to do it.
I'll take a look at the core runtime and cpp extension.
Cheers,
On 20/09/06, Jean-Sebastien Delfino
of course I meant:
On 18/09/06, Pete Robbins [EMAIL PROTECTED] wrote:
That code is not the only place that writeDO is called from. I believe
that the idea is to always write the xsi type info for the root element.
There is clearly some logic that tries to determine whether this is
necessary so
I'm going to restructure the source tree and deployment for the ws binding.
I think it will be better as:
extensions/
ws/
reference/
service/
xsd
as the scema is common to both reference and service
and deployed as
root/extensions/
ws/
reference/
lib ... etc
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
I've now finished this refactor. All checked in. Seems to work fine so I'm
going to go on holiday for a couple of weeks ;-)
Have fun folks!
On 30/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
I'm going to restructure the source tree and deployment for the ws
binding. I think
ah.. you got me! I will have to merge this with my changes that I am making.
I'd hoped to get these in before you started coding again... but you never
sleep!
I've moved all the osoa/sca code into the cpp extension and just about have
it working. I'll re-factor your binding extension changes in
In your latest drop you have moved the sca-binding-webservice.xsd from the
core xsd folder to 2 separate places! I believe this schema is defined by
the Assembly spec so should it not be in the core?
Cheers,
On 29/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
ah.. you got me! I will have
. It fails
building the scatest stuff. I think this test is in the wrong place now and
I will disable building it for now.
Cheers,
On 29/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
[snip]
Could the ws binding extension be packaged as:
extensions/
ws
Interesting! Are you looking at the C++ code? Assuming you are, some
comments inline.
On 24/08/06, Mark Trumbo [EMAIL PROTECTED] wrote:
Given some function
int SomePropertyPlusTwoFunction(DataObjectPtr dc) { return
dc-getInteger(SomeProperty) + 2; }
I would like to write
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
[ http://issues.apache.org/jira/browse/TUSCANY-490?page=all ]
Pete Robbins resolved TUSCANY-490.
--
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
DataObjectPtr::getByte returns incorrect data
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ]
Pete Robbins resolved TUSCANY-553.
--
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
Add a static null SDOString to the SDOString class
I'm sure the cpp tree could also benefit from this treatment. I will own up
to having Rev, Date in my subversions properties... as that is what Jeremy
told me to do (he's not around so I can blame him ;-) )
Is there a definitive list of property settings to use? This is the list
Jeremy gave me
I prefer the SCA style rather than the ones in SDO. The full path is better
as well so
#ifndef commonj_sdo_changeddataobjectlist_h
is what I would use.
However, I don't think this affects the readabillity of the code so I don't
propose we change them all. We need to update the licence header in
Excellent stuff... another thing that we haven't got around to yet.
I'm still playing around with different ways of making pluggable
extensions so I'll just merge what you check in with what I'm looking
at.
Cheers,
On 24/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Hi,
I'm going to
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
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
Yay!
On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins 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
Good stuff here. A couple of comments inline:
On 22/08/06, Oisin Hurley [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
Hi Oisin,
Here's the dumb question: What do you mean by Plugin? Is it a
composite or
group of composites?
Or just a set of extensions packaged in a library that you plug
aren't they just copied there when the build runs? If not, htey should be.
Cheers,
On 22/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I noticed that some files present under the main source tree are
duplicated under projects and projectsvc7.
Under projects:
./tuscany_sca
... and I notice someone has even checked in the dlls! This needs to be
changed. The project directories should only contain the vc projects. The
test subsystem should be created by the build.
Cheers,
On 22/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
aren't they just copied there when
On 22/08/06, Oisin Hurley [EMAIL PROTECTED] wrote:
.
I've seen lots of +1s on this thread, which is nice, and I've just found
out that I can edit the Tuscany wiki, so I'll summarize to there -- the
page will be http://wiki.apache.org/ws/Tuscany/TuscanyCpp/
PluggableCppRuntime
it'll be later
I thought this worked already in a very basic way!
The code in the runtime/core/test did pretty much what you want I think.
ComponentContext myContext = ComponentContext::getCurrent();
DataObjectInstance properties = myContext.getProperties();
if (properties)
{
const char*
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
Chris,
The first occurrence of sca.module in section 1.5.3.1 is simply a type. It
should read xxx.composite.
The Packaging and Deployment section has not yet been updated for
the recursive model so should be ignored.
I'm assuming that the default.scdl file is part of the Tuscany Java
Hi Oisin,
Here's the dumb question: What do you mean by Plugin? Is it a composite or
group of composites?
Cheers,
On 17/08/06, Oisin Hurley [EMAIL PROTECTED] wrote:
Hi guys,
I thought I might kick off a thread on pluggability in the C++
implementation to get some ideas rolling around, so
bindings, etc, etc to
look at!
Cheers
Andy
On 8/17/06, Pete Robbins [EMAIL PROTECTED] wrote:
I've started playing around with loading extension libraries to
support
other language extensions and so a wee bit of re-architecture has
cpp
being an extension language. In other words I'm
On 18/08/06, Simon Laws [EMAIL PROTECTED] wrote:
Mmm, not sure. I was thinking that in the case of an extension that I
would
want the C++ SCA model to reflect all of the components and associated
services and references that appear in the SCA configuration (whether that
be through SCDL or
[ http://issues.apache.org/jira/browse/TUSCANY-625?page=all ]
Pete Robbins reopened TUSCANY-625:
--
There is a problem with this fix as it stands. We need to make the behaviour
controllable so we don't always go off to the net looking
[ http://issues.apache.org/jira/browse/TUSCANY-644?page=all ]
Pete Robbins reassigned TUSCANY-644:
Assignee: Pete Robbins
Choice group with duplicate element names in XSD schema leads to duplication
of output from SDO
[ http://issues.apache.org/jira/browse/TUSCANY-644?page=all ]
Pete Robbins resolved TUSCANY-644.
--
Fix Version/s: Cpp-current
Resolution: Fixed
Duplicate properties were bing added to the Type
Choice group with duplicate element names in XSD
I've started playing around with loading extension libraries to support
other language extensions and so a wee bit of re-architecture has cpp
being an extension language. In other words I'm trying to make a core that
is not tied to cpp implementation. This core will roughly be a model loader
in
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension, name
the library and associate it with an implementation type? As a first
step at least, I think it would be great to have a very simple scheme
where you just drop a
On 16/08/06, Simon Laws [EMAIL PROTECTED] wrote:
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension,
name
the library and associate it with an implementation
[ http://issues.apache.org/jira/browse/TUSCANY-625?page=all ]
Pete Robbins resolved TUSCANY-625.
--
Fix Version/s: Cpp-current
Resolution: Fixed
Assignee: Pete Robbins
include/import logic updated to tr to load the namespace when
Robbie, I applied this at Kelvin's request. If you check
http://issues.apache.org/jira/browse/TUSCANY-583 and click the subversion
commits tab you will see the change has been made.
Cheers,
On 16/08/06, Robbie Minshall [EMAIL PROTECTED] wrote:
Any chance of a commiter taking a look at
No... thank you for the patch! ;-)
On 16/08/06, Robbie Minshall [EMAIL PROTECTED] wrote:
Ok great !
thanks Kelvin.
On 8/16/06, kelvin goodson [EMAIL PROTECTED] wrote:
Robbie,
its done, just the jira status hasnt been updated.
Cheers, Kelvin.
On 16/08/06, Robbie Minshall [EMAIL
[ http://issues.apache.org/jira/browse/TUSCANY-583?page=all ]
Pete Robbins resolved TUSCANY-583.
--
Fix Version/s: Java-Mx
Resolution: Fixed
Add a method to SDOUtil to return all Types associated with a specific URI
This looks a reasonable approach. The runtime will need to call the
extension to load it's part of the model. So ModelLoader will need to know
which library to call for a particular implementation type. The mechanism
should be the same for all implementation types so the existing
[ http://issues.apache.org/jira/browse/TUSCANY-577?page=all ]
Pete Robbins closed TUSCANY-577.
Closed at request of Kelvin
XSDHelperImpl.java compilation with JDK 1.4.2 - fails
-
Key
so do you think that wsdl and shema should be loaded on a per system
basis, i.e. we load all .wsdl and .xsd in either the root directory or any
we find from the root down?
On 15/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
Actually the wsdl/xsd are loaded
On 15/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
Im not saying that inheritance wouldnt work in SCA - it probably would.
I'm saying it wouldn't work ;-)
As the spec stands you get an INSTANCE of ComponentContext returned from
getCurrent(). So we either us no inheritance and just code
is to have
one DF for the system. (I'm just a tad worried about DO's getting freed
up... maybe I shouldn't worry ;-) )
Cheers,
On 15/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
so do you think that wsdl and shema should be loaded on a per system
basis, i.e. we load
On 15/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
This leads to a question which should be asked.
If the MyDataObject contains a DataObject, and all typesafe calls such as
getName() are in fact delegated via containedobject-getString(name)...
what has type safety actually gained us? We
On 15/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
OK, so if we dont deal with exception hiding, the two are:
Employee employee = someSDOmethod_returningMyTypesafeDO();
cout employee-getName() endl;
DataObjectPtr employee = someSDOmethod_returningAnSDO();
if (employee)
{
cout
That's about it. The SCA spec says that you actually get instances of e.g.
ComponentContext so we need to delegate to the ComponentContextImpl. As SDO
was returning pointers inheritence works fine.
Cheers,
On 14/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
In the case of SDO, it was just
A related question. What do you think about reorganizing the folder
structure a little to clearly separate the spec includes from the
implementation specific ones?
yes that would make sense. The osoa/sca tree should only contain what is
defined in the spec.
Cheers,
patch applied
On 14/08/06, Andrew Borley [EMAIL PROTECTED] wrote:
No problem, I've put a new patch up at TUSCANY-613 from the latest code
revision. This includes the 606 update, so no need to update that one.
Cheers
Andy
On 8/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Andrew
I do not like the central composite file.
As I mentioned earlier I'd really like our loader to be able to load all
composites under a dir structure and just figure out all the
relationships. I do not like enforcing a user to put some files under
packages and some under configuration. This may be
I may get some time tomorrow to look at it. Feel free to make the changes
and I can pick it up from there.
Cheers,
On 12/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Pete Robbins wrote:
I do not like the central composite file.
As I mentioned earlier I'd really like our loader
This is similar to what Java had. I think htis is replaced by include.wsdl
and include.xsd or soemthing. Not sure if this got into the spec.
Cheers,
On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
It looks like Tuscany-model.config just lists the WSDLs and XSDs used in
an
A lot of things referenced from a .composite are a path relative to the
.composite file (the compsite root). This is defined in the spec. For
example,
component name=MyValueServiceComponent
implementation.cpp library=MyValuelibrary path=MyValue
header=MyValue/MyValueImpl.h/implementation.cpp
so
Actually the wsdl/xsd are loaded for a particular composite so if there were
more say 2 .composites in a folder and 3 xsds we would load all 3 xsds
twice, once for each composite.
On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
so we load any wsdl/xsd in the same folder as the .composite
of course this supposes that all the schema and wsdl is local. We probably
need to support the case where the wsdl is remote e.g.
http://mySite/flobber.wsdl
Cheers,
On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
Actually the wsdl/xsd are loaded for a particular composite so if there
were
On 11/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
Yes, the SDO Xpath support was always one of those 'must rewrite when
theres
time' items.
It doesnt support dots in property names, as it uses the . or a [ to
indicate that the property being referenced is a many-valued property and
must be
It's not currently built. I was actually experimenting with it as a
development - deployment sample so that I could write a how to article.
Time got in the way though! I may resurrect it using the recursive model at
some point.
Cheers,
On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED]
I'll add some C++ content. Will you add the nominations of new committers
etc.?
Cheers,
On 11/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
This means us.
I can pull together the Java/SCA side - can someone please add
information on the C++ side.
The report covers the last 3 months.
--
On 10/08/06, Simon Laws [EMAIL PROTECTED] wrote:
You can use cygwin to do gcc compiles for windows. It comes with automake
(don't know what version) and can be integrated with Eclipse CDT.
S
That's the one! Does it produce dll's that run native on windows or does the
output depend on other
with
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=CalculatorComposite
Either the file naming convention or the name= is redundant?
On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
I'll take a look at the windows side of things.
Cheers,
On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED
... also are we enforcing the directory containing the composite to also be
named after the composite?
On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
Deployment question: Does the name of the .composite file HAVE to match
the name of the composite? Previously we just loaded any
.
Andy
On 8/10/06, Andrew Borley [EMAIL PROTECTED] wrote:
Similar question from me - do similar things apply for the subsystem
.composite file that replace sca.subsystem?
Andy
On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote:
... also are we enforcing the directory containing the composite
haven't actually got the samples going yet - BigBank falls
over for some reason, currently getting Calculator going.
When I've got stuff going I'll raise a Jira and put up a patch.
Cheers
On 8/10/06, Pete Robbins [EMAIL PROTECTED] wrote:
I haven't seen the NPE. I'm currently trying to get
-current
Reporter: Pete Robbins
Assigned To: Pete Robbins
To cover work for composites etc.
--
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
are still using MSVC 6 to compile
Tuscany. I'm curious whether there are any plans to upgrade to a
more recent and more conforming compiler. Stdcxx is being tested
with 7.1, and 8.0 (i86, IA64, and EM64T) but the 6.0 port would
likely need some work.
Regards
Martin
Pete Robbins wrote:
Hi Martin
. The filename comparison doesn't work on windows,
probably to do with \ vs /.
Cheers,
On 10/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
OK. I have the sca runtime building on vc6 fine. Calculator project builds
fine too. Having some teething problems getting it running.
On 10/08/06, Andrew Borley [EMAIL
: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
Assigned To: Pete Robbins
There is an SDOUTils function to print out the contents of a DataObject.
This proposal is to add ostream operator to RefCountingPointer that will call
a virtual function printSelf
I'm getting the same NPE, didn't notice it before. If I comment out
AccountDataService in the .composite file I'm not getting the NPE so it
must be specific to this particular service or AccountDataService.h
maybe? I have no idea why Options.set(...) would throw an NPE on ly with
I have to say I have never looked at the Java code but I have editted the
stylesheets to fix problems.
Cheers,
--
Pete
Passed with 7+1s from:
Pete Robbins
Jean-Sebastien Delfino
Ant Elder
Kevin Williams
Daniel Kulp
Kelvin Goodson
Jim Marino
Welcome to Tuscany Andy! I will start the process of getting your account
created.
Cheers,
--
Pete
Preferred userid: ajborley
Full name: Andrew Borley
Forwarding email address: [EMAIL PROTECTED]
Requested Karma for: ws ws-tuscany
ICLA has been submitted and appears on
http://people.apache.org/~jim/committers.html
Vote result 7+1 votes and no -1s:
Preferred userid: ajborley
Full name: Andrew Borley
Forwarding email address: [EMAIL PROTECTED]
Requested Karma for: ws ws-tuscany
ICLA has been submitted and appears on
http://people.apache.org/~jim/committers.html
Vote result 7+1 votes and no -1s:
is a valid property name. If yes,
getString() would return the value of myElem.1 otherwise it treats
myElem.1 as an XPath string.
Fuhwei
Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote:
I think the problem is that you can define an elements in a type such
as:
This would lead
Thanks for bringing this up Andy. I think there are a few separate topics in
this note and they probably need their own thread for discussion but this is
a good starting point.
I certainly would like to restructure the code and src tree structure a
little and this is a great time to do it having
I'll take a look at the windows side of things.
Cheers,
On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
So are you changing the loader to load the schema from xsd/new
instead of
xsd? Personally I would just go
Good! because the SDO XPath code looks a bit messy :-(
Cheers,
On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
I'll take a look at the XPath stuff in SDO and see if we can avoid the
annotations for the new assembly model
I believe automake can run on Windows using some linux portability layer (I
forget what it's called). I'll need to look into it some more. We should
also see what other Apache c/C++ projects use.
On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I'm still in the process of
I wouldn't underestimate the work involved to move it ;-) It would be
possible to do this but I'm not convinced it is worth it.
Maybe we should step back and consider the layout of the whole project tree.
In particular I'd like to see us add more unit test and I'm not sure if the
layout we have
I think the problem is that you can define an elements in a type such as:
element name=myElem type=xs:string maxOccurs=unbounded
element name=myElem.1 type=xs:string
This would lead to properties on the SDO type named myElem (which is
many-valued) and myElem.1.
So, when I code
On 08/08/06, Simon Laws [EMAIL PROTECTED] wrote:
Well you can construct expressions in gdb and have them execute but its
not
as convenient as having the code do it for you. Taking both points of view
on board how about a function that you can call on the data object that
prints its contents out
[ http://issues.apache.org/jira/browse/TUSCANY-587?page=all ]
Pete Robbins resolved TUSCANY-587.
--
Fix Version/s: Cpp-current
Resolution: Fixed
WSDL XSD is read incorrectly.
-
Key: TUSCANY-587
[ http://issues.apache.org/jira/browse/TUSCANY-602?page=all ]
Pete Robbins resolved TUSCANY-602.
--
Fix Version/s: Cpp-current
Resolution: Fixed
choice maxOccurs=unbounded does not create correct many-valued properties
[ http://issues.apache.org/jira/browse/TUSCANY-604?page=all ]
Pete Robbins resolved TUSCANY-604.
--
Fix Version/s: Cpp-current
Resolution: Fixed
Exception thrown when sequenced type inherits from non-sequenced type
[ http://issues.apache.org/jira/browse/TUSCANY-273?page=all ]
Pete Robbins closed TUSCANY-273.
Fix Version/s: Cpp-M1
(was: Cpp-current)
Resolution: Fixed
Error in build_instructions.txt
[ http://issues.apache.org/jira/browse/TUSCANY-100?page=all ]
Pete Robbins closed TUSCANY-100.
Fix Version/s: Cpp-M1
(was: Cpp-current)
Resolution: Fixed
This has been fixed for a while now
Group/AttributeGroup support
[ http://issues.apache.org/jira/browse/TUSCANY-404?page=all ]
Pete Robbins closed TUSCANY-404.
Resolution: Fixed
patches applied
STL string support: Add SDOString class and extend DataFactory interface
[ http://issues.apache.org/jira/browse/TUSCANY-443?page=all ]
Pete Robbins closed TUSCANY-443.
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
Add further code to support use of string objects
[ http://issues.apache.org/jira/browse/TUSCANY-456?page=all ]
Pete Robbins closed TUSCANY-456.
Fix Version/s: Cpp-M1
Resolution: Fixed
patch applied
[SDO for C++] Recursive function definition can cause overflow
[ http://issues.apache.org/jira/browse/TUSCANY-459?page=all ]
Pete Robbins closed TUSCANY-459.
Fix Version/s: Cpp-M1
Resolution: Fixed
patch applied
[SDP for C++] Compile error in sdotest.cpp. integer constant is too large for
long type
[ http://issues.apache.org/jira/browse/TUSCANY-476?page=all ]
Pete Robbins closed TUSCANY-476.
Fix Version/s: Cpp-M1
Resolution: Fixed
patch applied
[SDO for C++] Many warnings generated for signed/unsigned mismatch
701 - 800 of 1039 matches
Mail list logo
