You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/03/13 00:37:50 UTC
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
Hi, Frank.
I now see the requirements to recognize the SDO generated classes/interfaces
before the SDO TypeHelper is populated. As a result, I would prefer not to
rely on TypeHelper.getType(). In my case, we want to introspect java types
to find the usages of SDO generated classes/interfaces in the SCA composite
and populate the corresponding HelperContext instead of requiring a
<import.sdo> upfront. Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Frank Budinsky" <fr...@ca.ibm.com>
To: <tu...@ws.apache.org>
Sent: Friday, February 23, 2007 3:56 PM
Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
TypeHelperImpl.getType(Class)
> Raymond,
>
> Yes, "null" is returned if it's not an SDO type. I'll try to get a more
> efficient implementation (even if not the final solution) in place soon.
>
> Frank.
>
>
> "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 05:05:37 PM:
>
>> Hi,
>>
>> The SCA databinding code introspects java class to recognize a
> SDO-generated
>> interface/class and get the associated type in a performed way. Yes, I
> can
>> leave it to the SDO impl and I'll use TypeHelper.getType(Class). I
> assume
>> "null" will be returned if the class/interface is not SDO.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Frank Budinsky" <fr...@ca.ibm.com>
>> To: <tu...@ws.apache.org>
>> Sent: Friday, February 23, 2007 1:57 PM
>> Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
>
>> TypeHelperImpl.getType(Class)
>>
>>
>> > Hi Raymond,
>> >
>> > Can you please explain the requirement? Why do you need the type name
> and
>> > why do you instrospect the class? If you want the Type, can't you just
>> > call TypeHelper.getType(Class) and leave it up to the SDO impl to do
> it?
>> >
>> > Thanks,
>> > Frank.
>> >
>> > "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 03:55:00 PM:
>> >
>> >> Hi, Frank.
>> >>
>> >> We have checked in the code for SCA databinding to introspect a
>> > generated
>> >> SDO java class. It will be nice to get a fix from SDO. I guess adding
> a
>> >> public static field to the generated classes/interfaces will help us
>> >> recognize it and get the type name. For example,
>> >>
>> >> public static final javax.xml.namespace.QName _SDO_TYPE = new
>> >> javax.xml.namespace.QName("http://customer", "Customer");
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> ----- Original Message -----
>> >> From: "Frank Budinsky (JIRA)" <tu...@ws.apache.org>
>> >> To: <en...@gmail.com>
>> >> Sent: Tuesday, February 13, 2007 4:29 PM
>> >> Subject: [jira] Commented: (TUSCANY-1110) Improve the performance of
>> >> TypeHelperImpl.getType(Class)
>> >>
>> >>
>> >> >
>> >> > [
>> >> > https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.
>> >>
>> > atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel#action_12472943]
>> >> >
>> >> > Frank Budinsky commented on TUSCANY-1110:
>> >> > -----------------------------------------
>> >> >
>> >> > Yang, can you explain more about your idea?
>> >> >
>> >> > I also have a couple of ideas for how to speed up
>> >> > TypeHelper.getType(Class):
>> >> >
>> >> > 1) when we move a Java5 dependency, we should generate an
> annotation
>> > in
>> >> > the interface, which we could use at runtime to find the Type. The
>> > exact
>> >> > format of the annotation depends on an SDO 3 feature to support
> Java
>> >> > metadata annotations, which the SDO collaboration is currently
>> >> > considering.
>> >> > 2) before Java5, we could possibly do something like this:
>> >> > step 1) determine the class name from the provided Class.
>> >> > step 2) mangle the name to determine the impl class name
> (e.g.,
>> >> > org.example.Foo -> org.example.impl.FooImpl)
>> >> > step 3) create an instance and then call getType() - or better
>> > yet,
>> >> > we could change the generator pattern to generate a static method
> that
>> >
>> >> > returns the type - and then call it.
>> >> >
>> >> > I'm sure there are also other possible ways to do this, but the
>> > question
>> >> > is what's the priority for this? Does anyone know if the current
>> >> > performance of this method is a concern that needs immediate
>> > attention?
>> >> >
>> >> >> Improve the performance of TypeHelperImpl.getType(Class)
>> >> >> --------------------------------------------------------
>> >> >>
>> >> >> Key: TUSCANY-1110
>> >> >> URL:
>> > https://issues.apache.org/jira/browse/TUSCANY-1110
>> >> >> Project: Tuscany
>> >> >> Issue Type: Improvement
>> >> >> Components: Java SDO Implementation
>> >> >> Affects Versions: Java-SDO-Mx
>> >> >> Reporter: Raymond Feng
>> >> >> Fix For: Java-SDO-Mx
>> >> >>
>> >> >>
>> >> >> In the SDO databinding for SCA, we need to introspect a java
>> >> >> class/interface to figure out the corresponding SDO type. Looking
>> > into
>> >> >> the code, there is a TODO comment:
>> >> >> //TODO more efficient implementation ... this is a really bad one!
>> >> >> Do you plan to provide a more efficient impl :-)?
>> >> >> Thanks,
>> >> >> Raymond
>> >> >
>> >> > --
>> >> > This message is automatically generated by JIRA.
>> >> > -
>> >> > You can reply to this email to add a comment to the issue online.
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
Posted by Raymond Feng <en...@gmail.com>.
Hi, Frank.
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Frank Budinsky" <fr...@ca.ibm.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, March 13, 2007 7:08 AM
Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
TypeHelperImpl.getType(Class)
> Hi Raymond,
>
> I have a couple of questions.
>
> 1) Are you really just looking for a method something like this: boolean
> SDOUtil.isSDO(Class interface)?
Yes. But we might need more information such as the QName of the type and
the class name of the Factory without looking up the TypeHelper. This way,
we can perform the auto-registration of static types without requiring
<import.sdo> or an explicit XXXFactory.INSTANCE.register(HelperContext).
> 2) If the answer is yes, where do you get the Class's that you pass to
> this method, when do you call it, and what do you do if it returns true?
We introspect java methods to try to figure out if a parameter or return
type is SDO. If yes, we'll mark it as SDO databinding.
> 3) Whenever it returns true, doesn't that mean that the client will be
> working with an SDO and will use SDO APIs? If so, then doesn't the client
> already know the answer that isSDO() would return.
>
The client is not the application in this case. It is the Tuscany
databinding framework which tries to figure the addtional metadata behind
the java class/interface so that we can perform data transformation across
different databindings on the wire.
> Thanks,
> Frank
>
> "Raymond Feng" <en...@gmail.com> wrote on 03/12/2007 07:37:50 PM:
>
>> Hi, Frank.
>>
>> I now see the requirements to recognize the SDO generated
> classes/interfaces
>> before the SDO TypeHelper is populated. As a result, I would prefer not
> to
>> rely on TypeHelper.getType(). In my case, we want to introspect java
> types
>> to find the usages of SDO generated classes/interfaces in the SCA
> composite
>> and populate the corresponding HelperContext instead of requiring a
>> <import.sdo> upfront. Does it make sense?
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Frank Budinsky" <fr...@ca.ibm.com>
>> To: <tu...@ws.apache.org>
>> Sent: Friday, February 23, 2007 3:56 PM
>> Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
>
>> TypeHelperImpl.getType(Class)
>>
>>
>> > Raymond,
>> >
>> > Yes, "null" is returned if it's not an SDO type. I'll try to get a
> more
>> > efficient implementation (even if not the final solution) in place
> soon.
>> >
>> > Frank.
>> >
>> >
>> > "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 05:05:37 PM:
>> >
>> >> Hi,
>> >>
>> >> The SCA databinding code introspects java class to recognize a
>> > SDO-generated
>> >> interface/class and get the associated type in a performed way. Yes,
> I
>> > can
>> >> leave it to the SDO impl and I'll use TypeHelper.getType(Class). I
>> > assume
>> >> "null" will be returned if the class/interface is not SDO.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> ----- Original Message -----
>> >> From: "Frank Budinsky" <fr...@ca.ibm.com>
>> >> To: <tu...@ws.apache.org>
>> >> Sent: Friday, February 23, 2007 1:57 PM
>> >> Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance
> of
>> >
>> >> TypeHelperImpl.getType(Class)
>> >>
>> >>
>> >> > Hi Raymond,
>> >> >
>> >> > Can you please explain the requirement? Why do you need the type
> name
>> > and
>> >> > why do you instrospect the class? If you want the Type, can't you
> just
>> >> > call TypeHelper.getType(Class) and leave it up to the SDO impl to
> do
>> > it?
>> >> >
>> >> > Thanks,
>> >> > Frank.
>> >> >
>> >> > "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 03:55:00
> PM:
>> >> >
>> >> >> Hi, Frank.
>> >> >>
>> >> >> We have checked in the code for SCA databinding to introspect a
>> >> > generated
>> >> >> SDO java class. It will be nice to get a fix from SDO. I guess
> adding
>> > a
>> >> >> public static field to the generated classes/interfaces will help
> us
>> >> >> recognize it and get the type name. For example,
>> >> >>
>> >> >> public static final javax.xml.namespace.QName _SDO_TYPE = new
>> >> >> javax.xml.namespace.QName("http://customer", "Customer");
>> >> >>
>> >> >> Thanks,
>> >> >> Raymond
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Frank Budinsky (JIRA)" <tu...@ws.apache.org>
>> >> >> To: <en...@gmail.com>
>> >> >> Sent: Tuesday, February 13, 2007 4:29 PM
>> >> >> Subject: [jira] Commented: (TUSCANY-1110) Improve the performance
> of
>> >> >> TypeHelperImpl.getType(Class)
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > [
>> >> >> > https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.
>> >> >>
>> >> > atlassian.jira.plugin.system.issuetabpanels:comment-
>> >> tabpanel#action_12472943]
>> >> >> >
>> >> >> > Frank Budinsky commented on TUSCANY-1110:
>> >> >> > -----------------------------------------
>> >> >> >
>> >> >> > Yang, can you explain more about your idea?
>> >> >> >
>> >> >> > I also have a couple of ideas for how to speed up
>> >> >> > TypeHelper.getType(Class):
>> >> >> >
>> >> >> > 1) when we move a Java5 dependency, we should generate an
>> > annotation
>> >> > in
>> >> >> > the interface, which we could use at runtime to find the Type.
> The
>> >> > exact
>> >> >> > format of the annotation depends on an SDO 3 feature to support
>> > Java
>> >> >> > metadata annotations, which the SDO collaboration is currently
>> >> >> > considering.
>> >> >> > 2) before Java5, we could possibly do something like this:
>> >> >> > step 1) determine the class name from the provided Class.
>> >> >> > step 2) mangle the name to determine the impl class name
>> > (e.g.,
>> >> >> > org.example.Foo -> org.example.impl.FooImpl)
>> >> >> > step 3) create an instance and then call getType() - or
> better
>> >> > yet,
>> >> >> > we could change the generator pattern to generate a static
> method
>> > that
>> >> >
>> >> >> > returns the type - and then call it.
>> >> >> >
>> >> >> > I'm sure there are also other possible ways to do this, but the
>> >> > question
>> >> >> > is what's the priority for this? Does anyone know if the current
>> >> >> > performance of this method is a concern that needs immediate
>> >> > attention?
>> >> >> >
>> >> >> >> Improve the performance of TypeHelperImpl.getType(Class)
>> >> >> >> --------------------------------------------------------
>> >> >> >>
>> >> >> >> Key: TUSCANY-1110
>> >> >> >> URL:
>> >> > https://issues.apache.org/jira/browse/TUSCANY-1110
>> >> >> >> Project: Tuscany
>> >> >> >> Issue Type: Improvement
>> >> >> >> Components: Java SDO Implementation
>> >> >> >> Affects Versions: Java-SDO-Mx
>> >> >> >> Reporter: Raymond Feng
>> >> >> >> Fix For: Java-SDO-Mx
>> >> >> >>
>> >> >> >>
>> >> >> >> In the SDO databinding for SCA, we need to introspect a java
>> >> >> >> class/interface to figure out the corresponding SDO type.
> Looking
>> >> > into
>> >> >> >> the code, there is a TODO comment:
>> >> >> >> //TODO more efficient implementation ... this is a really bad
> one!
>> >> >> >> Do you plan to provide a more efficient impl :-)?
>> >> >> >> Thanks,
>> >> >> >> Raymond
>> >> >> >
>> >> >> > --
>> >> >> > This message is automatically generated by JIRA.
>> >> >> > -
>> >> >> > You can reply to this email to add a comment to the issue
> online.
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
TypeHelperImpl.getType(Class)
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Raymond,
I have a couple of questions.
1) Are you really just looking for a method something like this: boolean
SDOUtil.isSDO(Class interface)?
2) If the answer is yes, where do you get the Class's that you pass to
this method, when do you call it, and what do you do if it returns true?
3) Whenever it returns true, doesn't that mean that the client will be
working with an SDO and will use SDO APIs? If so, then doesn't the client
already know the answer that isSDO() would return.
Thanks,
Frank
"Raymond Feng" <en...@gmail.com> wrote on 03/12/2007 07:37:50 PM:
> Hi, Frank.
>
> I now see the requirements to recognize the SDO generated
classes/interfaces
> before the SDO TypeHelper is populated. As a result, I would prefer not
to
> rely on TypeHelper.getType(). In my case, we want to introspect java
types
> to find the usages of SDO generated classes/interfaces in the SCA
composite
> and populate the corresponding HelperContext instead of requiring a
> <import.sdo> upfront. Does it make sense?
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Frank Budinsky" <fr...@ca.ibm.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, February 23, 2007 3:56 PM
> Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
> TypeHelperImpl.getType(Class)
>
>
> > Raymond,
> >
> > Yes, "null" is returned if it's not an SDO type. I'll try to get a
more
> > efficient implementation (even if not the final solution) in place
soon.
> >
> > Frank.
> >
> >
> > "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 05:05:37 PM:
> >
> >> Hi,
> >>
> >> The SCA databinding code introspects java class to recognize a
> > SDO-generated
> >> interface/class and get the associated type in a performed way. Yes,
I
> > can
> >> leave it to the SDO impl and I'll use TypeHelper.getType(Class). I
> > assume
> >> "null" will be returned if the class/interface is not SDO.
> >>
> >> Thanks,
> >> Raymond
> >>
> >> ----- Original Message -----
> >> From: "Frank Budinsky" <fr...@ca.ibm.com>
> >> To: <tu...@ws.apache.org>
> >> Sent: Friday, February 23, 2007 1:57 PM
> >> Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance
of
> >
> >> TypeHelperImpl.getType(Class)
> >>
> >>
> >> > Hi Raymond,
> >> >
> >> > Can you please explain the requirement? Why do you need the type
name
> > and
> >> > why do you instrospect the class? If you want the Type, can't you
just
> >> > call TypeHelper.getType(Class) and leave it up to the SDO impl to
do
> > it?
> >> >
> >> > Thanks,
> >> > Frank.
> >> >
> >> > "Raymond Feng" <en...@gmail.com> wrote on 02/23/2007 03:55:00
PM:
> >> >
> >> >> Hi, Frank.
> >> >>
> >> >> We have checked in the code for SCA databinding to introspect a
> >> > generated
> >> >> SDO java class. It will be nice to get a fix from SDO. I guess
adding
> > a
> >> >> public static field to the generated classes/interfaces will help
us
> >> >> recognize it and get the type name. For example,
> >> >>
> >> >> public static final javax.xml.namespace.QName _SDO_TYPE = new
> >> >> javax.xml.namespace.QName("http://customer", "Customer");
> >> >>
> >> >> Thanks,
> >> >> Raymond
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Frank Budinsky (JIRA)" <tu...@ws.apache.org>
> >> >> To: <en...@gmail.com>
> >> >> Sent: Tuesday, February 13, 2007 4:29 PM
> >> >> Subject: [jira] Commented: (TUSCANY-1110) Improve the performance
of
> >> >> TypeHelperImpl.getType(Class)
> >> >>
> >> >>
> >> >> >
> >> >> > [
> >> >> > https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.
> >> >>
> >> > atlassian.jira.plugin.system.issuetabpanels:comment-
> >> tabpanel#action_12472943]
> >> >> >
> >> >> > Frank Budinsky commented on TUSCANY-1110:
> >> >> > -----------------------------------------
> >> >> >
> >> >> > Yang, can you explain more about your idea?
> >> >> >
> >> >> > I also have a couple of ideas for how to speed up
> >> >> > TypeHelper.getType(Class):
> >> >> >
> >> >> > 1) when we move a Java5 dependency, we should generate an
> > annotation
> >> > in
> >> >> > the interface, which we could use at runtime to find the Type.
The
> >> > exact
> >> >> > format of the annotation depends on an SDO 3 feature to support
> > Java
> >> >> > metadata annotations, which the SDO collaboration is currently
> >> >> > considering.
> >> >> > 2) before Java5, we could possibly do something like this:
> >> >> > step 1) determine the class name from the provided Class.
> >> >> > step 2) mangle the name to determine the impl class name
> > (e.g.,
> >> >> > org.example.Foo -> org.example.impl.FooImpl)
> >> >> > step 3) create an instance and then call getType() - or
better
> >> > yet,
> >> >> > we could change the generator pattern to generate a static
method
> > that
> >> >
> >> >> > returns the type - and then call it.
> >> >> >
> >> >> > I'm sure there are also other possible ways to do this, but the
> >> > question
> >> >> > is what's the priority for this? Does anyone know if the current
> >> >> > performance of this method is a concern that needs immediate
> >> > attention?
> >> >> >
> >> >> >> Improve the performance of TypeHelperImpl.getType(Class)
> >> >> >> --------------------------------------------------------
> >> >> >>
> >> >> >> Key: TUSCANY-1110
> >> >> >> URL:
> >> > https://issues.apache.org/jira/browse/TUSCANY-1110
> >> >> >> Project: Tuscany
> >> >> >> Issue Type: Improvement
> >> >> >> Components: Java SDO Implementation
> >> >> >> Affects Versions: Java-SDO-Mx
> >> >> >> Reporter: Raymond Feng
> >> >> >> Fix For: Java-SDO-Mx
> >> >> >>
> >> >> >>
> >> >> >> In the SDO databinding for SCA, we need to introspect a java
> >> >> >> class/interface to figure out the corresponding SDO type.
Looking
> >> > into
> >> >> >> the code, there is a TODO comment:
> >> >> >> //TODO more efficient implementation ... this is a really bad
one!
> >> >> >> Do you plan to provide a more efficient impl :-)?
> >> >> >> Thanks,
> >> >> >> Raymond
> >> >> >
> >> >> > --
> >> >> > This message is automatically generated by JIRA.
> >> >> > -
> >> >> > You can reply to this email to add a comment to the issue
online.
> >> >> >
> >> >>
> >> >>
> >> >>
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >
> >> >
> >> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org