You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by ke...@mailhaven.com on 2010/01/02 03:27:03 UTC
Re: How to install on Customer side
Hi!
Have you considered using a <property> element that uses the file
attribute to inject the contents from a file?
This way, you could have a settings file external to JAR-files that the
user can edit.
Note that according to the SCA 1.1 specification, only component
properties support the option to inject the contents of a file.
See section 4.4 of the Service Component Architecture Assembly Model
Specification Version 1.1.
Best wishes!
Ivan
--
http://www.fastmail.fm - Access your email from home and the web
Re: Why the static sdo is processed like a xsd defined global element? but not Type?
Posted by ext2 <xu...@tongtech.com>.
A trivial suggestion, maybe when save anonymous sdo to a different name, it
should report a exception instead of save to different xml silently.
_____
Sender:ext2 [mailto:xuhb@tongtech.com]
Date: 2010年1月8日 11:27
Receiver:user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?
Thanks Frank Budinsky:
If focus on xml specification, you are right.
But the real world is sophisticate, some other Java-XML process technical
will presume a name for the anonymous type(according to name of element).
But anyway this is just the application ‘s response to resolve this by
change xsd manually , it shouldn’t be the tuscany’s response and Tuscany
shouldn’t simulate it;
Thanks a lot
_____
Sender: Frank Budinsky [mailto:frankb@ca.ibm.com]
Date: 2010-1-7 23:26
Receiver:user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?
This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you have
this schema:
<element name="A" type="ns:AT">
<complexType name="AT">
...
</complexType>
and you serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")
save((DataObject)a, "http://test/choice", "B")
then the generated XML will look like this:
<B xsi:type="AT"> ... </B>
If, on the other hand, you use element "A" to serialize:
save((DataObject)a, "http://test/choice", "A")
then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".
<A> ... </A>
Now, in the case of an anonymous type:
<element name="A">
<complexType>
.....
</complexType>
</element>
In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:
<B xsi:type="????"> ... </B>
So the instance would be invalid XML and the value type would be lost.
Frank.
"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:
> [image removed]
>
> Why the static sdo is processed like a xsd defined global element?
> but not Type?
>
> ext2
>
> to:
>
> user
>
> 01/07/2010 03:28 AM
>
> Please respond to user
>
>
> Hi:
>
> According to my- understand , the sdo specification ask for static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
>
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated static java is process like a global element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect.
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if saving the static sdo to xml , the
argument
> provided specifiy element name will affect;
>
> For example , if xsd like this:
> <element name="A">
> <complexType>
> .....
> </complexType>
> </element>
>
> A static sdo interface as A.java will generate, but if I save the instance
> to xml like follow : save((DataObject)a, "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
>
> But if xsd like this:
>
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
>
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name.
>
> So why does Tuscany keep this as un-consistency? A bug ? Or there are some
> way I can control?
>
> Thanks for any suggest
>
>
Re: Why the static sdo is processed like a xsd defined global element? but not Type?
Posted by ext2 <xu...@tongtech.com>.
Thanks Frank Budinsky:
If focus on xml specification, you are right.
But the real world is sophisticate, some other Java-XML process technical
will presume a name for the anonymous type(according to name of element).
But anyway this is just the application 's response to resolve this by
change xsd manually , it shouldn't be the tuscany's response and Tuscany
shouldn't simulate it;
Thanks a lot
_____
Sender: Frank Budinsky [mailto:frankb@ca.ibm.com]
Date: 2010-1-7 23:26
Receiver: user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?
This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you have
this schema:
<element name="A" type="ns:AT">
<complexType name="AT">
...
</complexType>
and you serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")
save((DataObject)a, "http://test/choice", "B")
then the generated XML will look like this:
<B xsi:type="AT"> ... </B>
If, on the other hand, you use element "A" to serialize:
save((DataObject)a, "http://test/choice", "A")
then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".
<A> ... </A>
Now, in the case of an anonymous type:
<element name="A">
<complexType>
.....
</complexType>
</element>
In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:
<B xsi:type="????"> ... </B>
So the instance would be invalid XML and the value type would be lost.
Frank.
"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:
> [image removed]
>
> Why the static sdo is processed like a xsd defined global element?
> but not Type?
>
> ext2
>
> to:
>
> user
>
> 01/07/2010 03:28 AM
>
> Please respond to user
>
>
> Hi:
>
> According to my- understand , the sdo specification ask for static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
>
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated static java is process like a global element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect.
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if saving the static sdo to xml , the
argument
> provided specifiy element name will affect;
>
> For example , if xsd like this:
> <element name="A">
> <complexType>
> .....
> </complexType>
> </element>
>
> A static sdo interface as A.java will generate, but if I save the instance
> to xml like follow : save((DataObject)a, "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
>
> But if xsd like this:
>
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
>
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name.
>
> So why does Tuscany keep this as un-consistency? A bug ? Or there are some
> way I can control?
>
> Thanks for any suggest
>
>
Re: Why the static sdo is processed like a xsd defined global element? but
not Type?
Posted by Frank Budinsky <fr...@ca.ibm.com>.
This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you
have this schema:
<element name="A" type="ns:AT">
<complexType name="AT">
...
</complexType>
and you serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")
save((DataObject)a, "http://test/choice", "B")
then the generated XML will look like this:
<B xsi:type="AT"> ... </B>
If, on the other hand, you use element "A" to serialize:
save((DataObject)a, "http://test/choice", "A")
then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".
<A> ... </A>
Now, in the case of an anonymous type:
<element name="A">
<complexType>
.....
</complexType>
</element>
In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:
<B xsi:type="????"> ... </B>
So the instance would be invalid XML and the value type would be lost.
Frank.
"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:
> [image removed]
>
> Why the static sdo is processed like a xsd defined global element?
> but not Type?
>
> ext2
>
> to:
>
> user
>
> 01/07/2010 03:28 AM
>
> Please respond to user
>
>
> Hi:
>
> According to my- understand , the sdo specification ask for static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
>
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated static java is process like a global
element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect.
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if saving the static sdo to xml , the
argument
> provided specifiy element name will affect;
>
> For example , if xsd like this:
> <element name="A">
> <complexType>
> .....
> </complexType>
> </element>
>
> A static sdo interface as A.java will generate, but if I save the
instance
> to xml like follow : save((DataObject)a, "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
>
> But if xsd like this:
>
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
>
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name.
>
> So why does Tuscany keep this as un-consistency? A bug ? Or there are
some
> way I can control?
>
> Thanks for any suggest
>
>
Why the static sdo is processed like a xsd defined global element? but not Type?
Posted by ext2 <xu...@tongtech.com>.
Hi:
According to my- understand , the sdo specification ask for static java
type should only be generate for global types in xsd, and should not
generate for element, is it true?
But using Tuscany, I found a surprising thing. If I using a anonymous
complex type, the generated static java is process like a global element
of xsd. That's if I save the static sdo to xml, the argument provided
specify element name doesn't affect.
But if I using a named complex type, only static sdo is generated for the
global complex type of xsd , and there are no static sdo is generate for
global element of xsd. And if saving the static sdo to xml , the argument
provided specifiy element name will affect;
For example , if xsd like this:
<element name="A">
<complexType>
.....
</complexType>
</element>
A static sdo interface as A.java will generate, but if I save the instance
to xml like follow : save((DataObject)a, "http://test/choice", "B"). The
element's name B will never take affect, and saved xml 's element name is
always be A;
But if xsd like this:
<element name="A" type="ns:AT">
<complexType name="AT">
...
</complexType>
Only global type "AT" is generate to a AT.java , and save the AT 's sdo
instance will take affect if we provide element name.
So why does Tuscany keep this as un-consistency? A bug ? Or there are some
way I can control?
Thanks for any suggest
Re: How to load a xml to a static sdo instance?
Posted by ext2 <xu...@tongtech.com>.
Ok, I knows, this is because I haven't register the static do's type in the
context; After register it , we could load xml as static sdo instance using
XmlHelper;
Thanks to Raymond Feng, he tell me how to register the static sdo's type to
the context , using generate static sdo's factory's register method;
-----------------------------
Hi:
Does any one knows how to load a xml to a static type sdo?
Though I can save the static sdo to a xml, but can only load the xml as
dynamic sdo, and cannot load it as original static type sdo 's instance.
Thanks any suggest
How to load a xml to a static sdo instance?
Posted by ext2 <xu...@tongtech.com>.
Hi:
Does any one knows how to load a xml to a static type sdo?
Though I can save the static sdo to a xml, but can only load the xml as
dynamic sdo, and cannot load it as original static type sdo 's instance.
Thanks any suggest