Re: Exception in SDO runtime on Windows, was: [C++] windows build system

[Geoffrey Winn]

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]

Re: [jira] Commented: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005

[Geoffrey Winn]

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) 
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::list
>  >::_Const_iterator<1>::_Compat(const
> std::list
>  >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
> 309 + 0x17 bytesC++
>
tuscany_sdo.dll!std::list
>  >::_Const_iterator<1>::operator==(const
> std::list
>  >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
> 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

[Geoffrey Winn]

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

[Geoffrey Winn]

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::list
> >  >::_Const_iterator<1>::_Compat(const
> > std::list
> >  >::_Const_iterator<1> & _Right={first=3452816845 second={...}
> })  Line
> > 309 + 0x17 bytesC++
> >
> tuscany_sdo.dll!std::list
> >  >::_Const_iterator<1>::operator==(const
> > std::list
> >  >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
>
> > 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: [jira] Commented: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005

[Geoffrey Winn]

Sebastian,

Yes, we are linked with odbc32.lib and I don't know why. Clearly, you took
it out and that did no harm. I did the same and it removed the odbc32 link
error but just exposed another. Did you have the Platform SDK installed as
well?

I've noticed some other oddities as well, such as some build configurations
specify pre-compiled headers and some don't.

I think we should clean this up so that the settings we have are ones we
need and understand. I'm making some progress with this as part of
introducing stdcxx. I suspect a lot of the settings are just defaults that
were never changed.

Geoff.

On 13/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Geoffrey Winn wrote:
> 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::list
>>
>> > >  >::_Const_iterator<1>::_Compat(const
>> > > std::list
>> > >  >::_Const_iterator<1> & _Right={first=3452816845 second={...}
>> > })  Line
>> > > 309 + 0x17 bytesC++
>> > >
>> >
>>
tuscany_sdo.dll!std::list
>>
>> > >  >::_Const_iterator<1>::operator==(const
>> > > std::list
>> > >  >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
>>
>> >
>> > > 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
>> > > 

Re: [C++] Configure options for our Linux automake build?

[Geoffrey Winn]

I'm not familiar with Automake but I need a mechanism along these lines to
integrate the stdcxx option into the Linux built. Can anyone tell me whether
features in Automake is the right way to do this? I'm really looking for an
either/or mechanism that either builds as it does now or builds using stdcxx
in place of the usual Linux C++ library. That's similar to but not the same
as "Python yes or no" type questions.

Geoff.

On 13/09/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


A couple of questions:

What do you see going into --enable-most-extensions?
My own view would be CPP, Axis2 and one of the scripting languages to give
a
good view of what SCACPP can do. Alternatively, it could check for certain
environment variables on the system (e.g. AXIS2C_HOME, PYTHON_HOME) and
only
compile those extensions that have the required variable defined.

Should we follow the Java side of things and release binaries containing
different groups of extensions?
As Simon says, the runtime only loads and uses dlls it finds and needs to
use, so releasing a single binary with all the libraries in it should be
OK.
Currently we have no libraries that clash (like Java does with the Axis
and
Celtix binding.ws implementations), but when we do I guess we'll either
have
to release different binaries, or have some installation process where the
user chooses which particular extension is to be used.

Cheers

Andy


On 9/13/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> Yep, +1 from me too.
>
> If we have a command line build again for Windows (the one that was
> released with M1 has lapsed), we could implement something like this in
a
> .bat file pretty easily.
>
> Andy
>
>
>
> On 9/13/06, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 9/13/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > As we add more extensions to our runtime, I think it would be a good
> > > idea to add feature configuration options to our Linux build, to
allow
> >
> > > people to build just a subset when they are not interested in a
> > specific
> > > feature and/or do not have the pre-req software for it on their
> > machine.
> > >
> > > If you define features to Automake you can then use the following
> > > configure options:
> > > configure --enable-FEATURE
> > > configure --disable-FEATURE
> > >
> > > We could have
> > > configure --enable-all-extensions
> > > configure --enable-most-extensions
> > > configure --enable-cpp
> > > configure --enable-axis2
> > > configure --enable-php
> > > configure --enable-python
> > > configure --enable-ruby
> > > etc. as more extensions get added...
> > >
> > > What do you think?
> > >
> > > Any similar thoughts for the Windows build?
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > Good idea. +1 for me on this. The windows (MSVC) build is separated
> > already
> > so there is a project per extension. I believe the runtime only loads
> > dll it
> > finds so if you haven't built a particular extension it won't try and
> > load
> > it.
> >
> > S
> >
> >
>

Re: [SDO for C++] How to integrate stdcxx as a build option?

[Geoffrey Winn]

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

[Geoffrey Winn]

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: [C++] SDO can't load an XML doc with no namespace

[Geoffrey Winn]

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:
>>
JaneDoe
>>
>> 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:
>> 
>>
>> 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

[Geoffrey Winn]

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: Request for Project Ideas for M.Sc Students

[Geoffrey Winn]

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" 
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

[Geoffrey Winn]

I've created JIRA 747 to record this.

On 21/09/06, Simon Laws <[EMAIL PROTECTED]> wrote:


On 9/21/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
>
> 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:
> > >>
> >
JaneDoe
> > >>
> > >> 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:
> > >> 
> > >>
> > >> 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]
> >
> >
>
> I forgot to come back on this one. Sorry about that. What I found was
confirmed by Geoff so I cheated to get round it. For a sample I needed to
do
(Implementing a simple JSON DAS) I defined a single type in the model that
had open content and then read in each element in the JSON tree in turn
giving it this type in order to create an SDO. I didn't try reading in an
XML file using this approach but it would be interesting to see if you can
make it work somehow. Of course you end up with an SDO with no useful type
information but for my purposes that was OK. I have to get on a train in a
bit so I'll give it a go

S

Re: Request for Project Ideas for M.Sc Students

[Geoffrey Winn]

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]
>
>

[SDO for C++] Problem with modifying build configuration files for MS VC 7.1

[Geoffrey Winn]

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.

Re: [SDO for C++] Problem with modifying build configuration files for MS VC 7.1

[Geoffrey Winn]

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

[Geoffrey Winn]

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: [C++][SDO] Use of std::string

[Geoffrey Winn]

On 29/09/06, Pete Robbins <[EMAIL PROTECTED]> wrote:



I'd like to propose we get rid of SDOString and just use std::string.
SDOString inherits from std::string but does not add any additional
function. The initial idea of having SDOString was to add an additional
operator const char*() so that when we changed public API return values
from
const char* to SDOString a user would not have to ammend their code.
However, this didn't quite work so I believe SDOString is redundant.



There were other reasons too, although the only one that remains is my own
concern that we might eventually discover some extra functionality that we
needed. However, it hasn't happened so far so as you say SDOString probably
is redundant.

Next, we have many duplicate methods that take parameters as string or

char*. I would like to remove all the methods that take char* as const
string& will work just as well without causing users problems. I realise
that this is currently being discussed by the spec group and the current
spec has the interfaces using char*, however for input paramters this
proposal will still support the methods as if they were passing char* so I
think we should go for it. I'm sure the spec group will get round to
agreeing woth this ;-)



As far as I can tell they will. I had deliberately not made the switch to
the string class only methods yet because it seemed premature in advance of
the spec being changed.

Finally, and a bit later, we need to look at changing the public APIs that

return char* to return std::string but this can wait for the spec group to
decide if this is what they want. This will affect users as they will need
to use .c_str() on their return values if they require th char* string.



This is another reason why I left it in its current state. I thought it
would look a bit odd to have methods with a signature like

const char * getSomeValue(const SDOString& key)

or whatever, and, as you say we can't change the return parameters in
advance of the spec.

I agree with everything you are doing or proposing. I was just a bit wary of
implementing it in advance of changes in the spec.

Geoff.

Re: [C++][SDO] Use of std::string

[Geoffrey Winn]

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

[Geoffrey Winn]

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: [C++] SDO can't load an XML doc with no namespace

[Geoffrey Winn]

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

http://www.w3.org/2001/XMLSchema";>
 
 
   
 
   
 


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:
JaneDoe

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:


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

[Geoffrey Winn]

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
>
> http://www.w3.org/2001/XMLSchema";>
> 
> 
>
>  
>
> 
> 
>
> 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:
> >
JaneDoe
> >
> > 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:
> > 
> >
> > 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

[Geoffrey Winn]

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
> > >
> > > http://www.w3.org/2001/XMLSchema";>
> > > 
> > > 
> > >
> > >  
> > >
> > > 
> > > 
> > >
> > > 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:
> > > >
> >
JaneDoe
> > > >
> > > > 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:
> > > > 
> > > >
> > > > 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

[Geoffrey Winn]

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.

[C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples

[Geoffrey Winn]

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++] SCA build on Ubuntu Linux V6.06 LTS fails in samples

[Geoffrey Winn]

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


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?

I will run it again and review the log more carefully to see if I can see
anything odd

Regards,

Geoff.

Re: [C++] SCA build on Ubuntu Linux V6.06 LTS fails in samples

[Geoffrey Winn]

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

Re: SDO Java: Getting Involved -- Tests/Samples

[Geoffrey Winn]

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

[Geoffrey Winn]

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 
  -

  [image: [WWW]] The installation instructions for SCA and SDO in
C++
  -

  [image: [WWW]] The C++ user guide for SCA and SDO in
C++
  -

  [image: [WWW]] The SCA for C++
Documentation
  -

  [image: [WWW]] The SDO for C++
Documentation

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++ Wiki] Links on the Tuscany for C++ page broken

[Geoffrey Winn]

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.

[SDO for C++] How to raise JIRAs for 2.1 spec compliance

[Geoffrey Winn]

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

[Geoffrey Winn]

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

[Geoffrey Winn]

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: [SDO for C++] How to raise JIRAs for 2.1 spec compliance

[Geoffrey Winn]

On 17/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:




Or open the Component list and select the "C++ Specification" category
that I created last week to help track the C++ spec related issues  :)

--
Jean-Sebastien



OK. That' s a decision. I will mark JIRAs raised because of the 2.1 spec as
being both the "C++ SDO" and "C++ Specification" components.

Regards,

Geoff.

Re: Reminder. Request for Project Ideas for University Students

[Geoffrey Winn]

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.

Re: [VOTE] Release Tuscany C++ Milestone 2

[Geoffrey Winn]

On 18/10/06, ant elder <[EMAIL PROTECTED]> wrote:


The download versions of iconv, zlib, and libxml
that i could find didn't match the doc so when it didn't work the 1st time
I
didn't know if it was as due to a version mismatch but it was just a
config
problem. Actually I'd really much prefer the Tuscany binary download
include
axis2 and its 3 dependencies as it just makes it so much easier for people
who don't understand this all properly yet. (yes I know, what about python
and ruby and windows/linux and... But WS seems like a basic part of this
to
me so should just work right out of the box)

   ...ant



I know what you mean. I had exactly this problem when I first started
working with SDO. I did end up installing a version of zlib that didn't work
even though it was more recent. I'm not sure that we should pin this issue
on this particular release but you are right that we need a better way to
handle external dependencies. Ideally we would just say "the latest release
of X available from web site Y" but that commits us to regular upgrades and
associated testing. As you say, bundln the stuff might be a good compromise.

Geoff.

Re: Reminder. Request for Project Ideas for University Students

[Geoffrey Winn]

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

[Geoffrey Winn]

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: [VOTE] Release Tuscany C++ Milestone 2 (candidate 3)

[Geoffrey Winn]

I've tried the SDO release and it looks good to me too.

+1

Geoff.

On 19/10/06, ant elder <[EMAIL PROTECTED]> wrote:


Looks good to me, +1

   ...ant

On 10/19/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> Tested on Fedora Core5 and WinXP
> +1 from me
>
> Andy
>
> On 10/19/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 19/10/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi everyone,
> > >
> > > I have posted an updated 3rd candidate for the milestone 2 C++
release
> > > here:
> > > http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC3a/
> > >
> > > This release candidate adds a missing build file in the Windows
> > > distros, fixes up the disabled Python and Ruby extension libraries
on
> > > Linux so there are no "stat" messages and adds a few minor doc
> > > changes.
> > >
> > > Please vote to publish the Milestone 2 release distributions. Please
> > > take some time to download the distributions, review them and test
> them
> > > in your environment before voting.
> > >
> > > The vote is open for at least the next 72 hours.
> > > At least three +1 votes are required, and only the votes from
> > > Tuscany committers are binding. If the majority of all votes is
> > > positive, I will send a summary of that vote to the Incubator's
> general
> > > list to formally request the Incubator PMC to approve the Tuscany
C++
> > > Milestone 2 release. For your reference the Incubator release policy
> > > guidelines are available at
> > >
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.
> > >
> > >
> > > About Tuscany SCA C++
> > > =
> > >
> > > Tuscany SCA C++ provides a runtime implementation for the for the
> Service
> > > Component Architecture 0.96 Assembly specification and the 0.95 C++
> Client
> > > & Implementation Model specification, written in C++ and will
> currently
> > > support C++, Python and Ruby component implementation types.
> > >
> > > The specifications can be found at
> > >
> > >
>
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
> > >
> > > It is possible to interoperate with Tuscany SCA Java via the Web
> > > Service bindings
> > > for services and references but restrictions apply. This is not yet
a
> > > complete
> > > implementation and known restrictions are described below.
> > >
> > > Supported SCA Assembly Model features
> > > *  All features are supported unless listed under the known
> restrictions
> > >below. See SCA Assembly Model specification.
> > >
> > > Supported language bindings
> > > * Component implementations written in C++. See the SCA C++ Client
and
> > >   Implementation Model specification.
> > > * Component implementations written in Python. See the
> > > doc/PythonExtension.html
> > >   documentation.
> > > * Component implementations written in Python. See the
> > > doc/RubyExtension.html
> > >   documentation.
> > > * Component interfaces described by C++ classes. See SCA Client and
> > >   Implementation Model specification.
> > >
> > > Supported service and reference bindings
> > > * The web service binding is supported. This implementation will
> support
> > >   web services which using document literal SOAP bindings conforming
> to
> > > the
> > >   WS-I basic profile (rpc/encoded is not yet supported).
> > >
> > > Known restrictions
> > > * Local service interfaces cannot use overloaded operations (the SCA
> > >   specification limits remote service interfaces to not using
> overloaded
> > >   operations).
> > > * Each WSDL definition for a web service binding must be in a single
> WSDL
> > >   document.
> > > * No load time validation of the deployed SCA application (run time
> > >   validation only).
> > > * No metadata API.
> > >
> > >
> > >
> > > About Tuscany SDO for C++
> > > =
> > >
> > > Tuscany SDO is an implementation of the Service Data Objects for C++
> 2.01
> > > specification found at
> > >
>
http://www.osoa.org/display/Main/SDO+-+Previously+Published+Specifications
> > >
> > > Supported SDO features
> > > * All features are supported unless listed under the known
> restrictions.
> > >   See the Service Data Objects for C++ 2.01 specification.
> > >
> > > New features in this release
> > > * Optional build on Windows with Apache STDCXX
> > > * Improved memory management
> > > * Multiple bug fixes and internal enhancements
> > >
> > > Many thanks
> > >
> > > Andrew
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > My issues with the previous candidate are resolved.
> >
> > Here's my +1
> > Cheers,
> > --
> > Pete
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[SDO for C++] Making the definition of types more user friendly

[Geoffrey Winn]

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

[Geoffrey Winn]

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: SDO C++: Getting Involved -- Tests/Samples

[Geoffrey Winn]

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

[Geoffrey Winn]

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.

Re: SDO - dealing with CDATA

[Geoffrey Winn]

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++] Thread safety ?

[Geoffrey Winn]

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: [C++] Pending SDO patches available

[Geoffrey Winn]

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 ?

[Geoffrey Winn]

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?

[Geoffrey Winn]

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

[Geoffrey Winn]

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.

[SDO for C++] Does SDO depend on zlib?

[Geoffrey Winn]

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.

New committer unable to commit changes

[Geoffrey Winn]

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.

Re: [SDO C++] Is Type::OpenDataObjectType part of the API?

[Geoffrey Winn]

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:


http://www.w3.org/2001/XMLSchema";
targetNamespace="http://www.example.org/test";
xmlns:tns="http://www.example.org/test";>











and a document like:

http://www.example.org/test";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://www.example.org/test cdata2.xsd ">
  jim_value
  entry_value


will provoke this problem when I try to get the type of .

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.

Re: [C++] Who is working on which SDO problems

[Geoffrey Winn]

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 for C++] Issues from reviewing SequenceImpl.cpp

[Geoffrey Winn]

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,
> RefCountingPointer v)
> bool SequenceImpl::addDataObject(unsigned int propertyIndex,
> RefCountingPointer v)
> bool SequenceImpl::addDataObject(const Property& p,
> RefCountingPointer 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: [SDO for C++] Issues from reviewing SequenceImpl.cpp

[Geoffrey Winn]

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,
> > RefCountingPointer v)
> > bool SequenceImpl::addDataObject(unsigned int propertyIndex,
> > RefCountingPointer v)
> > bool SequenceImpl::addDataObject(const Property& p,
> > RefCountingPointer 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] Thread safety ?

[Geoffrey Winn]

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: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading

[Geoffrey Winn]

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: [jira] Resolved: (TUSCANY-990) Avoid duplicated/infinite loading

[Geoffrey Winn]

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: DAS C++ needing volunteers and advises

[Geoffrey Winn]

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 ?

[Geoffrey Winn]

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: DAS C++ needing volunteers and advises

[Geoffrey Winn]

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

[Geoffrey Winn]

On 09/01/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:



- To define which function will be set as "virtual" or not.



In Java, all instance methods are virtual unless they are marked final;
whereas in C++ by default, they are not. One way that you could deal with
this is just to ignore it. If you already have derived classes that override
a method in a parent class then the compiler will complain and that tells
you that you need to make the parent's method virtual. On the other hand,
any time that you find that you want to override a method from a parent then
again, you can change the parent. If you find you are making this change a
lot, then that will probably show/tell you where you need to change a block
of methods.

Regards,

Geoff.

Re: SDO Java/C++

[Geoffrey Winn]

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

[Geoffrey Winn]

On 09/01/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:



- 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.



I think Luciano has checked-in the DAS code. Can you  point to some examples
in the code of the pointer of reference issues that you think need to be
fixed?

Regards,

Geoff.

Re: SDO Java/C++

[Geoffrey Winn]

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: [VOTE] Simon Laws for Tuscany committer

[Geoffrey Winn]

+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
>
>

How to update the Tuscany website?

[Geoffrey Winn]

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?

[Geoffrey Winn]

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: [C++] SDO Memory management

[Geoffrey Winn]

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

Re: [SDO CTS] Anyone avail to commit TUSCANY-1048 & TUSCANY-1081 ?

[Geoffrey Winn]

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: SDO C++ getUserData method

[Geoffrey Winn]

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: Content for next milestone

[Geoffrey Winn]

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: Tuscany Native M3 release

[Geoffrey Winn]

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: Tuscany Native M3 release

[Geoffrey Winn]

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

[Geoffrey Winn]

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: SDO CTS: TUSCANY-1117

[Geoffrey Winn]

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

[Geoffrey Winn]

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
>

[SDO for C++] Design notes added to repository

[Geoffrey Winn]

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.

[SDO for C++] SDO builds with MSVC++ 8 Professional

[Geoffrey Winn]

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.

Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++

[Geoffrey Winn]

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
>

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

[Geoffrey Winn]

Could you explain a little more about what you are trying to do?

Regards,

Geoff.

On 01/06/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:


Is there any other way to use static object on sdo c++?

Adriano Crestani

On 5/31/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
>
> Thanks for clarification ; )
>
> Adriano Crestani
>
> On 5/31/07, Pete Robbins <[EMAIL PROTECTED] > wrote:
> >
> > 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 still in there!
> >
> > Cheers,
> >
> > On 31/05/07, Adriano Crestani < [EMAIL PROTECTED]> wrote:
> > >
> > > I used the DataFactory::generateInterface() and I got the following
> > code:
> > >
> > > ...
> > > DataObjectList& Config::getRelationship //missing parameters
> > definition
> > > {
> > >return the_object->getList("Relationship");
> > > }
> > > ...
> > >
> > > It is not generating the parameters definition of any function that
> > > returns
> > > a DataObjectList&. Bellow is the code I use to generate the code
> > above:
> > >
> > >
> > > commonj::sdo::DataFactoryPtr dataFactory =
> > > commonj::sdo::DataFactory::getDataFactory();
> > > commonj::sdo::XSDHelperPtr xsdh =
> > > commonj::sdo::HelperProvider::getXSDHelper(dataFactory);
> > > xsdh->defineFile("config.xsd");
> > > dataFactory->generateInterface("DataFactoryImpl",
"DataFactoryImpl");
> > >
> > > And here is the config.xsd:
> > >
> > >  > >   xmlns:config="apache.das.rdb"
> > >   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > >   targetNamespace="apache.das.rdb.config"
> > >   elementFormDefault="qualified">
> > >
> > >   
> > >
> > >   
> > >  
> > > > > type="Table"/>
> > > > > name="Relationship"
> > > type="Relationship"/>
> > >  
> > >  
> > >   
> > >
> > >   
> > >  
> > >  > name="KeyPair"
> > > type="KeyPair"/>
> > >  
> > >  
> > >   > > use="required"/>
> > >   > > use="required"/>
> > >  
> > >   
> > >
> > >   
> > >  
> > >  >
> > > type="Column"/>
> > >  
> > >   > use="required"/>
> > >  
> > >   
> > >
> > >   
> > >   > > use="required"/>
> > >   > > use="required"/>
> > >   
> > >
> > >   
> > >   > use="required"/>
> > >
> > >  
> > >   > default="false"/>
> > >   
> > >
> > > 
> > >
> > > Am I committing some mistake or it's really a bug?
> > >
> > > Adriano Crestani
> > >
> >
> >
> >
> > --
> > Pete
> >
>
>

Problems retrieving source for SDO for C++

[Geoffrey Winn]

I've tried to retrieve the source for SDO for C++ from the repository using
the following command.

E:> svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/cpp

When I do this fo rthe first time, I get what looks like a failure

svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: REPORT of '/repos/asf/!svn/vcc/default': 200 OK (http://svn.apache.org)

However, if I then issue the same command again, the extract works without a
problem (ie lots of files get fetched).

I'm using svn V1.3.0 and I've also tried TortoiseSVN 1.3.3 - which gives
essentially the same behaviour, failing on this first attempt but then
succeeding. Is this normal? It feels to me that I'm failing to do some setup
step before attempting the checkout but I can't see what that is.

Thanks and regards,

Geoff.

Re: Problems retrieving source for SDO for C++

[Geoffrey Winn]

On 27/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


Geoff, I've seen this behaviour too using both TortoiseSVN and subclipse
from eclipse. It's not just on the cpp tree of Tuscany. It seems to happen
fairly randomly.

On 26/04/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
>
> I've tried to retrieve the source for SDO for C++ from the repository
> using
> the following command.
>
> E:> svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/cpp
>
> When I do this fo rthe first time, I get what looks like a failure
>
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn: REPORT of '/repos/asf/!svn/vcc/default': 200 OK (
> http://svn.apache.org)
>
> However, if I then issue the same command again, the extract works
without
> a
> problem (ie lots of files get fetched).
>
> I'm using svn V1.3.0 and I've also tried TortoiseSVN 1.3.3 - which gives
> essentially the same behaviour, failing on this first attempt but then
> succeeding. Is this normal? It feels to me that I'm failing to do some
> setup
> step before attempting the checkout but I can't see what that is.
>
> Thanks and regards,
>
> Geoff.
>
>


--
Pete




While fixing a completely different problem, I discovered that svn checkout
works fine when I have my Zone Labs firewall switched off. I'll investigate
this a bit further and see if I can find a way to make the two co-exist.

Geoff.

Introduction

[Geoffrey Winn]

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

[Geoffrey Winn]

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?

[Geoffrey Winn]

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

[Geoffrey Winn]

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.

Re: C++ Release

[Geoffrey Winn]

Pete,

another +1 for the release and IRC chat

Re: Cross language interop testing

[Geoffrey Winn]

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.

[SDO C++] Representing strings as objects rather than C style character pointers

[Geoffrey Winn]

I've been investigating how to modify the C++ variant of SDO to use string
objects (ie something like std::string) rather than C style strings as it
mostly does currently. Internally we can do what we want, but the user
visible
interface needs more care and has implications for the specification. I'd
like
to start a discussion about the options and try to get some agreement over
the
changes that we would like to make to the specification.

Currently I am adding an SDOString class that inherits from std::string.
This
gives us the option to add or modify behaviour and also minimises the
overhead
when we just want the behaviour of standard string.

The easy bit involves parameters to methods. If we have a method that takes
a
C style string as an argument,

void setName(const char* name_in)

then we can add another version of the same method,

void setName(const SDOString& name_in)

The old interface is preserved and existing users of it are unaffected, but
anyone who wants to, can use the new one. These extra methods would probably
need to be mentioned in the specification, but we haven't removed or
compromised
anything that is already there.

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.

1. Add another method with a different name. For example,

const SDOString& getNameAsSDOString()

and the new name (whatever it might be) would have to become part of the
specification.

2. Change the return type to a string object. For example,

  const SDOString& getName()

This is neater, but breaks existing users who, as a minimum, will need to
extract the C style string from the string object, for example.

  const char* local_name = someObject.getName().c_str();

We could remove this requirement by providing a user defined conversion
operator to automatically convert from the object to a string pointer, for
example, within SDOString

 operator const char*() const { return c_str(); }

However, there are two potential problems with this.

1. The general objection, as stated in Stroustrup 11.4

"In general, it is wise to be sparing in the introduction of conversion
operators. When used in excess, they lead to ambiguities."

2. The specific problem that methods that mix C style parameters with object
  style parameters can confuse the compiler.

Suppose we have two (overloaded) methods

  1. void fn(const char* first, const char* second)
  2. void fn(const SDOString& first, const SDOString& second)

and we make a call passing a C style string as the first parameter and an
SDOString as the second parameter. Without the conversion operator, the
first
parameter is converted to an SDOString and the second method is called. But,
if the conversion is provided, then the compiler also has the option to
convert the second parameter to a C style string and call the first method -
and it is ambiguous which of these to choose, leading to a compile time
error.

Since there are relatively few users of SDO for C++ at the moment, I think
we
still have the option to change the return type to SDOString and avoid the
need for a conversion operator.

In summary, we need to decide how to handle string valued method returns
and then make the appropriate changes to the specification.

Regards,

Geoff.

Re: SDO C++ runtime - build error on Linux

[Geoffrey Winn]

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  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

[Geoffrey Winn]

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

[Geoffrey Winn]

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: SDO C++ runtime - build error on Linux

[Geoffrey Winn]

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: Tuscany blog

[Geoffrey Winn]

Are you sure about "tuscanysca"? Wouldn't "tuscanysoa" be more inclusive?

Geoff.

On 12/06/06, kelvin goodson <[EMAIL PROTECTED]> wrote:


OK, so after a minor off-line chat with ant I think the nice URL from
blogger makes me think +1 for blogger over airset.  If everyone else is
happy the last thing we need to do is express preferences over the URL for
the blog.  As ant mentioned, its in the form of

http://.blogspot.com/

so long as whatever-you-choose is not already in use of course.  BTW
"tuscany" is not available.  We have a placeholder on "tuscanysca", but
can
change this.  Any comments?  In the absence of any strong feelings being
expressed in the near term we'll go with "tuscanysca".  Once this is
decided
we can send out invitations to join blogger so that you can post.

Kelvin.

Re: Whats required to become a Tuscany Committer?

[Geoffrey Winn]

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: C++ M1 Release Candidate

[Geoffrey Winn]

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

[Geoffrey Winn]

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

[Geoffrey Winn]

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=11511128601&r=1&w=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

[Geoffrey Winn]

I'll be around on the mailing list but not IRC.


Me too.

Geoff.

Re: C++ M1 Release Candidate

[Geoffrey Winn]

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.