On 04/12/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 12/4/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> Simon, your patch fails to apply with some wierd error at line 416! I
have
> backed out the change for 963. Could you try making your patch again?
>
> Cheers,
>
>
> On 04/12/06, Pete Robbins <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > >
> > > On 12/3/06, Simon Laws <[EMAIL PROTECTED]> 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,
> >
> > --
> > Pete
> >
>
>
>
> --
> Pete
>
> Oh dear. I actutally tested applying this patch as well this time:-( It
applies OK in Eclipse against a clean version of SDO. Can you shed any
light
on what the error is. As it was suggested last time that I should manually
edit the patch to make it relative I did this to the satisfaction of the
Eclipse application process but obviously messed it up us as far as what
ever tool you use is concerned. If you give me a bit of info on the error
I'll try and make a better patch.
Simon
Simon's patches for TUSCANY-950 and TUSCANY-908 are now applied. I've also
checked in a fix for TUSCANY-960.
Cheers,
--
Pete
