You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/12/04 09:34:25 UTC
[C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
Pete Robbins wrote:
> Simon, I have also ben looking at a fix for 950 and although it is fairly
> straightforward to fix the case in the Jira it gets rather complicated
> when
> you consider properties that are not intended to be part of the
> sequence (
> e.g. attributes but could be element properties that have been set
> without
> using the sequence API).
>
> On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
>>
>> On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
>> >
>> > I've been working on a fix for 950 which I managed to complete so that
>> you
>> > could successfully copy a DO tree containing both mixed and open
>> types.
>> I
>> > then applied your fix for 963 and the resulting SDO fails. It happily
>> does
>> > the copy still but won't print out elements in sequences or open typed
>> > elements from the new DO that results from the copy.
>> >
>
>
> ... and this is exactly one of the issues I ran up against!!
>
>> Looking at the svn commit for 963 the main change seems to be to the
>> > SDOXMLWriter.
>> >
>> > // Do not write attributes as members of the
>> > sequence
>> > XSDPropertyInfo* pi =
>> getPropertyInfo(seqPropType,
>> > seqProp);
>> > PropertyDefinitionImpl propdef;
>> > if (!pi ||
>> > (pi->getPropertyDefinition().isElement))
>> > {
>> > continue;
>> > }
>> >
>> > I'm not au fait with how property info works but taking a tour
>> round the
>> > code it seems to be where the DAS keeps extra info derived from the
>> schema
>> > that is only used when writing back out to XML. The change finds, from
>> the
>> > property info, those elements that are really attributes and hence
>> only
>> > writes them as attributes.
>> >
>> > 1/ The first thing that looks a little fishy is "if (!pi ||
>> > (pi->getPropertyDefinition().isElement))" which looks like it
>> breaks out
>> of
>> > the loop if the property represents an element rather than when
>> it's not
>> an
>> > element. Is this right?
>> >
>
>
> A better test here would be "have we already written this property as an
> attribute". The intent here is to only write properties that are
> explicitly
> defined as elements.
>
>> Regardless of the correctness of this my copy doesn't work because "!pi"
>> > is always true after I have copied the sequence. Can you explain to me
>> how
>> > property information is intended to work. I need to know if I should
>> copy
>> > anything more than just the instance information. I had thought
>> everything
>> > else was in the model and hence I don't need to copy it.
>> >
>
>
> The PropertyInformation is basically a collection of information we
> remember
> from the schema to enable us to serialize it as a schema intended. I
> believe
> we were going to add the ability to add this information programmatically
> and this may even have made it into the spec... I need to check.
>
>
>> With the schema:
>> >
>> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> > xmlns:tns="http://www.example.org/test "
>> > targetNamespace="http://www.example.org/test">
>> >
>> > <complexType name="CloneType" mixed="true">
>> > <sequence>
>> > <element name="test" type="string"/>
>> > <any namespace="##any"/>
>> > </sequence>
>> > </complexType>
>> >
>> > <element name="Clone" type="tns:CloneType"/>
>> >
>> > </schema>
>> >
>> > And the XML document:
>> >
>> > <Clone xmlns="http://www.example.org/test"
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
>> > xsi:schemaLocation="http://www.example.org/test
>> clone.xsd ">
>> > abc
>> > <test>test</test>
>> > def
>> > <tests>test</tests>
>> > ghi
>> > </Clone>
>> >
>> > CloneType does have property info associated with it. But neither
>> > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
>> (the
>> > type of tests) have property info associated with them once the schema
>> has
>> > been read. Hence it is not present in the model after the copy and the
>> new
>> > writer doesn't write out "test" or "tests".
>
>
> Types never have PropertyInformation on them... nor will ANY open
> property
> as these, by definition, are not defined by a schema. So this is where my
> "fix" for 963 fails as your test and tests properties will never have
> any pi
> associated with them.
>
> My changes (so far) are attached to
>> http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
>> also as a backup.
>
>
>
> I'll take a look and see how close these are to my intended fix ;-)
>
> I'll also go back and revisit the 963 fix to cope with open types.
>
>
>
> Cheers,
>
I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
scenario. After some debugging it looks like elements under an open type
are not written anymore. What's strange is that they seem to be written
in some cases and not in some other cases. I am not completely sure
since the HttpdBigBank scenario is a little complex and only some of the
exchanges fail but it looks like simple elements are written and complex
type elements are not... again I'm not sure... Anyway, if I revert back
to revision r980964 of SDOWriter.cpp it works, with the head revision it
doesn't.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 04/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > Simon, I have also ben looking at a fix for 950 and although it is
> fairly
> > straightforward to fix the case in the Jira it gets rather complicated
> > when
> > you consider properties that are not intended to be part of the
> > sequence (
> > e.g. attributes but could be element properties that have been set
> > without
> > using the sequence API).
> >
> > On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
> >>
> >> On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> >> >
> >> > I've been working on a fix for 950 which I managed to complete so
> that
> >> you
> >> > could successfully copy a DO tree containing both mixed and open
> >> types.
> >> I
> >> > then applied your fix for 963 and the resulting SDO fails. It happily
> >> does
> >> > the copy still but won't print out elements in sequences or open
> typed
> >> > elements from the new DO that results from the copy.
> >> >
> >
> >
> > ... and this is exactly one of the issues I ran up against!!
> >
> >> Looking at the svn commit for 963 the main change seems to be to the
> >> > SDOXMLWriter.
> >> >
> >> > // Do not write attributes as members of the
> >> > sequence
> >> > XSDPropertyInfo* pi =
> >> getPropertyInfo(seqPropType,
> >> > seqProp);
> >> > PropertyDefinitionImpl propdef;
> >> > if (!pi ||
> >> > (pi->getPropertyDefinition().isElement))
> >> > {
> >> > continue;
> >> > }
> >> >
> >> > I'm not au fait with how property info works but taking a tour
> >> round the
> >> > code it seems to be where the DAS keeps extra info derived from the
> >> schema
> >> > that is only used when writing back out to XML. The change finds,
> from
> >> the
> >> > property info, those elements that are really attributes and hence
> >> only
> >> > writes them as attributes.
> >> >
> >> > 1/ The first thing that looks a little fishy is "if (!pi ||
> >> > (pi->getPropertyDefinition().isElement))" which looks like it
> >> breaks out
> >> of
> >> > the loop if the property represents an element rather than when
> >> it's not
> >> an
> >> > element. Is this right?
> >> >
> >
> >
> > A better test here would be "have we already written this property as an
> > attribute". The intent here is to only write properties that are
> > explicitly
> > defined as elements.
> >
> >> Regardless of the correctness of this my copy doesn't work because
> "!pi"
> >> > is always true after I have copied the sequence. Can you explain to
> me
> >> how
> >> > property information is intended to work. I need to know if I should
> >> copy
> >> > anything more than just the instance information. I had thought
> >> everything
> >> > else was in the model and hence I don't need to copy it.
> >> >
> >
> >
> > The PropertyInformation is basically a collection of information we
> > remember
> > from the schema to enable us to serialize it as a schema intended. I
> > believe
> > we were going to add the ability to add this information
> programmatically
> > and this may even have made it into the spec... I need to check.
> >
> >
> >> With the schema:
> >> >
> >> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >> > xmlns:tns="http://www.example.org/test "
> >> > targetNamespace="http://www.example.org/test">
> >> >
> >> > <complexType name="CloneType" mixed="true">
> >> > <sequence>
> >> > <element name="test" type="string"/>
> >> > <any namespace="##any"/>
> >> > </sequence>
> >> > </complexType>
> >> >
> >> > <element name="Clone" type="tns:CloneType"/>
> >> >
> >> > </schema>
> >> >
> >> > And the XML document:
> >> >
> >> > <Clone xmlns="http://www.example.org/test"
> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> >> > xsi:schemaLocation="http://www.example.org/test
> >> clone.xsd ">
> >> > abc
> >> > <test>test</test>
> >> > def
> >> > <tests>test</tests>
> >> > ghi
> >> > </Clone>
> >> >
> >> > CloneType does have property info associated with it. But neither
> >> > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
> >> (the
> >> > type of tests) have property info associated with them once the
> schema
> >> has
> >> > been read. Hence it is not present in the model after the copy and
> the
> >> new
> >> > writer doesn't write out "test" or "tests".
> >
> >
> > Types never have PropertyInformation on them... nor will ANY open
> > property
> > as these, by definition, are not defined by a schema. So this is where
> my
> > "fix" for 963 fails as your test and tests properties will never have
> > any pi
> > associated with them.
> >
> > My changes (so far) are attached to
> >> http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
> but
> >> also as a backup.
> >
> >
> >
> > I'll take a look and see how close these are to my intended fix ;-)
> >
> > I'll also go back and revisit the 963 fix to cope with open types.
> >
> >
> >
> > Cheers,
> >
>
> I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
> scenario. After some debugging it looks like elements under an open type
> are not written anymore. What's strange is that they seem to be written
> in some cases and not in some other cases. I am not completely sure
> since the HttpdBigBank scenario is a little complex and only some of the
> exchanges fail but it looks like simple elements are written and complex
> type elements are not... again I'm not sure... Anyway, if I revert back
> to revision r980964 of SDOWriter.cpp it works, with the head revision it
> doesn't.
Correct. Fix is a bad un as it doen't handle open content. Hope to fix that
today
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete