You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Andreas Dejung <an...@velsys.com> on 2009/12/30 22:39:51 UTC
How to install on Customer side
Hi
I have read the documentation on how the deployment works. What I did
not quite understand is how you would go about an application you
deliver to a Customer. As I don't want to give the Customer all the
components and let him do the composition I need something pre-defined
where he only needs to start up. He should be able to change some
properties such as ports or so but other then that he should not need to
do anything else.
Did I miss something in the docu?
Thanks for any pointer
Kind Regards
Andy
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
Re: How to install on Customer side
Posted by ke...@mailhaven.com.
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