Peter,
I don't think it's something I can put on my radar at the moment, sorry.
You may like to raise this as an issue on the tuscany-dev mailing list, and
perhaps open a JIRA for it. I guess from your request that it's not
something you might consider contributing yourself is it? If you could that
would be really helpful.
Regards, Kelvin.
On 19/03/2008, Peter Klotz <[EMAIL PROTECTED]> wrote:
>
> Hi Kevin,
>
> thanks that was very very helpfull indeed! It's working, thanks.
>
> One more question in
>
> XMLHelperImpl.save()
>
> public void save(XMLDocument xmlDocument, Result outputResult, Object
> options)
> throws IOException {
> options = checkSetOptions(options);
> if (outputResult instanceof DOMResult) {
>
> ((XMLDocumentImpl)xmlDocument).save(((DOMResult)outputResult).getNode(),
> options);
> } else if (outputResult instanceof SAXResult) {
>
>
> throw new UnsupportedOperationException();
> ---
>
> when will this be "supported", because I need to read the result of the
> save
> into a JDOMResult, which is a sub-class of SAXResult :-( ?
> I can certainly workaround this but that is not efficient to use DOM!
>
> ---
> } else if (outputResult instanceof StreamResult) {
> save(xmlDocument,
> ((StreamResult)outputResult).getOutputStream(),
> options);
> } else {
> throw new UnsupportedOperationException();
> }
> }
>
>
> Thanks, Peter
>
>
> kelvin goodson wrote:
> > I think what you are missing is a declaration of a global element in
> your
> > schema, so if you had something like
> >
> > <xsd:element name="datasource" type="tns:datasource"/>
> >
> > then you will be able to get a non-null response from
> > Property prop = scope.getXSDHelper
> ().getGlobalProperty(NS_CODA,"datasource",
> > true);
> >
> > You can then call content.setList(prop, list); // using Property based
> > setter, not string based
> >
> > That should get you going.
> >
> > Alternatively you could do
> >
> > List list = content.getList(prop)
> > then just add DataObjects to list and they will automatically be
> contained
> > in content.
> >
> > or repeated call
> > content.createDataObject(prop);
> > followed by content.getList(prop)
> >
> >
> > The problem with the way you are doing it is this -- when you are doing
> the
> > content.setList("datasource", thelist)
> >
> > the namespace of the property "datasource" is not known. If the Type of
> the
> > content DataObject had a defined property called "datasource" then you
> could
> > just look up the Type of the "datasource" property, but it doesn't, we
> are
> > dealing with open content here.
> >
> > There may be many "datasource" open content properties registered in
> > different namespaces or there may be none, but the runtime can't make
> > assumptions about which one to use, and, because the Type of content is
> > open, the runtime therefore creates an "on the fly" property
> "datasource"
> > in the no-namespace, and tries to infer it's type from the value passed
> > in. I think what is then happening is that the list object that you
> passed
> > in, when serialized, has a sequence of data objects that are not part
> of
> > the containment hierarchy of the data graph, which is not permissable,
> > hence the serialization failure.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
