You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2006/08/28 04:28:49 UTC
RMI binding questions
I came across a couple of things related to the RMI binding today.
Venkat, when you get a chance, could you take a look at these?
- Shouldn't RMIHost be in a separate extension package other than
SPI? This question relates to bindings in general. I would like to
avoid changing SPI for every new type of host provider we have.
- The RMI exception hierarchy should extend from
TuscanyRuntimeException, TuscanyException, or an SCA exception if
application code is involved (e..g RemoteServiceException). Examples
can be found at:
http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
20Handling
- There are a couple of PMD violations in the binding package. When
you get a chance, can you take care of them? (mvn -Psourcecheck)
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: RMI binding questions
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 27, 2006, at 10:34 PM, Venkata Krishnan wrote:
> Hi Jim,
> I shall look into these rightaway. I shall move the RMIHost
> interface
> into the extension package itself.
I think that is problematic as it is likely to make host
implementations dependent on the extension project.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: RMI binding questions
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Jim,
I shall look into these rightaway. I shall move the RMIHost interface
into the extension package itself.
I shall look into the exceptions and formatting as well.
- Venkat
On 8/28/06, Jim Marino <jm...@myromatours.com> wrote:
>
> I think we still have the same problem of piling everything into one
> project. We may wind up with a project having only one class (the
> interface) but this may be the best solution since it avoids having
> people update the Tuscany namespace with their extensions.
>
> Jim
>
> On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
>
> > Would host-api be the right place for RMIHost?
> >
> > --
> > Jeremy
> >
> > On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
> >
> >> I came across a couple of things related to the RMI binding today.
> >> Venkat, when you get a chance, could you take a look at these?
> >>
> >> - Shouldn't RMIHost be in a separate extension package other than
> >> SPI? This question relates to bindings in general. I would like to
> >> avoid changing SPI for every new type of host provider we have.
> >>
> >> - The RMI exception hierarchy should extend from
> >> TuscanyRuntimeException, TuscanyException, or an SCA exception if
> >> application code is involved (e..g RemoteServiceException).
> >> Examples can be found at:
> >>
> >> http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
> >> 20Handling
> >>
> >> - There are a couple of PMD violations in the binding package.
> >> When you get a chance, can you take care of them? (mvn -Psourcecheck)
> >>
> >> Thanks,
> >> Jim
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Re: RMI binding questions
Posted by Jeremy Boynes <jb...@apache.org>.
I think it fits the rules we agreed ("standard" etc.) so I would say
yes, please do.
--
Jeremy
On 8/28/06, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi Jim / Jeremy,
>
> I put the RMIHost in the spi precisely for reasons that Jeremy pointed out.
> Aslo with ServletHost already there I assumed that this would be the way we
> would go and hence put it there.
>
> So now shall I move it over to the host-api?
>
> Thanks
>
> - Venkat
>
>
> On 8/28/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Aug 27, 2006, at 11:26 PM, Jeremy Boynes wrote:
> >
> > > Not every type - just those that we have tried to define a host
> > > interface for. They will be in the Tuscany namespace anyway, it's
> > > just a question of whether they are together in the host-api jar,
> > > or spread amongst a load of other very small jars.
> > >
> > > How about we say that it's OK to add them to host-api provided they
> > > only depend on "standard" interfaces (such as javax.rmi, javax.jms,
> > > org.osgi) rather than on any implementation of those interfaces?
> > > "Non-standard" ones (that introduced a dependency on something such
> > > as JINI or say a specific JMS implementation) would go into
> > > separate modules.
> > >
> > > We can then mark the dependencies as "provided" as they are likely
> > > to be present in the host environment anyway (e.g. any J2EE server
> > > will automatically provide most of javax...).
> > >
> > That works for me.
> >
> > Jim
> >
> > > --
> > > Jeremy
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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: RMI binding questions
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Jim / Jeremy,
I put the RMIHost in the spi precisely for reasons that Jeremy pointed out.
Aslo with ServletHost already there I assumed that this would be the way we
would go and hence put it there.
So now shall I move it over to the host-api?
Thanks
- Venkat
On 8/28/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Aug 27, 2006, at 11:26 PM, Jeremy Boynes wrote:
>
> > Not every type - just those that we have tried to define a host
> > interface for. They will be in the Tuscany namespace anyway, it's
> > just a question of whether they are together in the host-api jar,
> > or spread amongst a load of other very small jars.
> >
> > How about we say that it's OK to add them to host-api provided they
> > only depend on "standard" interfaces (such as javax.rmi, javax.jms,
> > org.osgi) rather than on any implementation of those interfaces?
> > "Non-standard" ones (that introduced a dependency on something such
> > as JINI or say a specific JMS implementation) would go into
> > separate modules.
> >
> > We can then mark the dependencies as "provided" as they are likely
> > to be present in the host environment anyway (e.g. any J2EE server
> > will automatically provide most of javax...).
> >
> That works for me.
>
> Jim
>
> > --
> > Jeremy
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: RMI binding questions
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 27, 2006, at 11:26 PM, Jeremy Boynes wrote:
> Not every type - just those that we have tried to define a host
> interface for. They will be in the Tuscany namespace anyway, it's
> just a question of whether they are together in the host-api jar,
> or spread amongst a load of other very small jars.
>
> How about we say that it's OK to add them to host-api provided they
> only depend on "standard" interfaces (such as javax.rmi, javax.jms,
> org.osgi) rather than on any implementation of those interfaces?
> "Non-standard" ones (that introduced a dependency on something such
> as JINI or say a specific JMS implementation) would go into
> separate modules.
>
> We can then mark the dependencies as "provided" as they are likely
> to be present in the host environment anyway (e.g. any J2EE server
> will automatically provide most of javax...).
>
That works for me.
Jim
> --
> Jeremy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: RMI binding questions
Posted by Jeremy Boynes <jb...@apache.org>.
Not every type - just those that we have tried to define a host
interface for. They will be in the Tuscany namespace anyway, it's
just a question of whether they are together in the host-api jar, or
spread amongst a load of other very small jars.
How about we say that it's OK to add them to host-api provided they
only depend on "standard" interfaces (such as javax.rmi, javax.jms,
org.osgi) rather than on any implementation of those interfaces? "Non-
standard" ones (that introduced a dependency on something such as
JINI or say a specific JMS implementation) would go into separate
modules.
We can then mark the dependencies as "provided" as they are likely to
be present in the host environment anyway (e.g. any J2EE server will
automatically provide most of javax...).
--
Jeremy
On Aug 27, 2006, at 10:50 PM, Jim Marino wrote:
> Hmm, the converse to that is we have to put an XHost in the Tuscany
> namespace for every type. I don't think this is that unmanageable
> as OSGi does this. The actual service implementation would be in
> the project for the host, while the interface would be in a
> separate project which a binding would depend on.
>
> Jim
>
> On Aug 27, 2006, at 10:44 PM, Jeremy Boynes wrote:
>
>> This sounds extremely fine grained, almost to the point of taking
>> modularity to the point of two, possibly three, projects per
>> service which I think is unmanageable.
>>
>> We should keep the RMI binding as an extension for sure. But that
>> binding has an need for a physical service (RMIHost) whose
>> implementation should be provided by the host environment as only
>> the host knows how to create and schedule work from physical
>> endpoints (sockets).
>>
>> We have a M-1-N situation here, multiplied by the potential number
>> of host services. I think we should keep all host interface
>> classes (like RMIHost and ServletHost) in host-api so that host
>> providers are at least aware of the host services extensions may
>> require (they always have the option of not implementing them).
>>
>> --
>> Jeremy
>>
>> On Aug 27, 2006, at 10:14 PM, Jim Marino wrote:
>>
>>> I think we still have the same problem of piling everything into
>>> one project. We may wind up with a project having only one class
>>> (the interface) but this may be the best solution since it avoids
>>> having people update the Tuscany namespace with their extensions.
>>>
>>> Jim
>>>
>>> On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
>>>
>>>> Would host-api be the right place for RMIHost?
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>> On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
>>>>
>>>>> I came across a couple of things related to the RMI binding
>>>>> today. Venkat, when you get a chance, could you take a look at
>>>>> these?
>>>>>
>>>>> - Shouldn't RMIHost be in a separate extension package other
>>>>> than SPI? This question relates to bindings in general. I would
>>>>> like to avoid changing SPI for every new type of host provider
>>>>> we have.
>>>>>
>>>>> - The RMI exception hierarchy should extend from
>>>>> TuscanyRuntimeException, TuscanyException, or an SCA exception
>>>>> if application code is involved (e..g RemoteServiceException).
>>>>> Examples can be found at:
>>>>>
>>>>> http://incubator.apache.org/tuscany/
>>>>> codeguidelines.html#Exception%20Handling
>>>>>
>>>>> - There are a couple of PMD violations in the binding package.
>>>>> When you get a chance, can you take care of them? (mvn -
>>>>> Psourcecheck)
>>>>>
>>>>> Thanks,
>>>>> Jim
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> 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: RMI binding questions
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 27, 2006, at 10:50 PM, Jim Marino wrote:
> Hmm, the converse to that is we have to put an XHost in the Tuscany
> namespace for every type. I don't think this is that unmanageable
> as OSGi does this.
I should clarify: I don't think having a separate project just for
the "host" interface is problematic.
> The actual service implementation would be in the project for the
> host, while the interface would be in a separate project which a
> binding would depend on.
>
> Jim
>
> On Aug 27, 2006, at 10:44 PM, Jeremy Boynes wrote:
>
>> This sounds extremely fine grained, almost to the point of taking
>> modularity to the point of two, possibly three, projects per
>> service which I think is unmanageable.
>>
>> We should keep the RMI binding as an extension for sure. But that
>> binding has an need for a physical service (RMIHost) whose
>> implementation should be provided by the host environment as only
>> the host knows how to create and schedule work from physical
>> endpoints (sockets).
>>
>> We have a M-1-N situation here, multiplied by the potential number
>> of host services. I think we should keep all host interface
>> classes (like RMIHost and ServletHost) in host-api so that host
>> providers are at least aware of the host services extensions may
>> require (they always have the option of not implementing them).
>>
>> --
>> Jeremy
>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: RMI binding questions
Posted by Jim Marino <jm...@myromatours.com>.
Hmm, the converse to that is we have to put an XHost in the Tuscany
namespace for every type. I don't think this is that unmanageable as
OSGi does this. The actual service implementation would be in the
project for the host, while the interface would be in a separate
project which a binding would depend on.
Jim
On Aug 27, 2006, at 10:44 PM, Jeremy Boynes wrote:
> This sounds extremely fine grained, almost to the point of taking
> modularity to the point of two, possibly three, projects per
> service which I think is unmanageable.
>
> We should keep the RMI binding as an extension for sure. But that
> binding has an need for a physical service (RMIHost) whose
> implementation should be provided by the host environment as only
> the host knows how to create and schedule work from physical
> endpoints (sockets).
>
> We have a M-1-N situation here, multiplied by the potential number
> of host services. I think we should keep all host interface classes
> (like RMIHost and ServletHost) in host-api so that host providers
> are at least aware of the host services extensions may require
> (they always have the option of not implementing them).
>
> --
> Jeremy
>
> On Aug 27, 2006, at 10:14 PM, Jim Marino wrote:
>
>> I think we still have the same problem of piling everything into
>> one project. We may wind up with a project having only one class
>> (the interface) but this may be the best solution since it avoids
>> having people update the Tuscany namespace with their extensions.
>>
>> Jim
>>
>> On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
>>
>>> Would host-api be the right place for RMIHost?
>>>
>>> --
>>> Jeremy
>>>
>>> On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
>>>
>>>> I came across a couple of things related to the RMI binding
>>>> today. Venkat, when you get a chance, could you take a look at
>>>> these?
>>>>
>>>> - Shouldn't RMIHost be in a separate extension package other
>>>> than SPI? This question relates to bindings in general. I would
>>>> like to avoid changing SPI for every new type of host provider
>>>> we have.
>>>>
>>>> - The RMI exception hierarchy should extend from
>>>> TuscanyRuntimeException, TuscanyException, or an SCA exception
>>>> if application code is involved (e..g RemoteServiceException).
>>>> Examples can be found at:
>>>>
>>>> http://incubator.apache.org/tuscany/codeguidelines.html#Exception
>>>> %20Handling
>>>>
>>>> - There are a couple of PMD violations in the binding package.
>>>> When you get a chance, can you take care of them? (mvn -
>>>> Psourcecheck)
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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: RMI binding questions
Posted by Jeremy Boynes <jb...@apache.org>.
This sounds extremely fine grained, almost to the point of taking
modularity to the point of two, possibly three, projects per service
which I think is unmanageable.
We should keep the RMI binding as an extension for sure. But that
binding has an need for a physical service (RMIHost) whose
implementation should be provided by the host environment as only the
host knows how to create and schedule work from physical endpoints
(sockets).
We have a M-1-N situation here, multiplied by the potential number of
host services. I think we should keep all host interface classes
(like RMIHost and ServletHost) in host-api so that host providers are
at least aware of the host services extensions may require (they
always have the option of not implementing them).
--
Jeremy
On Aug 27, 2006, at 10:14 PM, Jim Marino wrote:
> I think we still have the same problem of piling everything into
> one project. We may wind up with a project having only one class
> (the interface) but this may be the best solution since it avoids
> having people update the Tuscany namespace with their extensions.
>
> Jim
>
> On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
>
>> Would host-api be the right place for RMIHost?
>>
>> --
>> Jeremy
>>
>> On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
>>
>>> I came across a couple of things related to the RMI binding
>>> today. Venkat, when you get a chance, could you take a look at
>>> these?
>>>
>>> - Shouldn't RMIHost be in a separate extension package other than
>>> SPI? This question relates to bindings in general. I would like
>>> to avoid changing SPI for every new type of host provider we have.
>>>
>>> - The RMI exception hierarchy should extend from
>>> TuscanyRuntimeException, TuscanyException, or an SCA exception
>>> if application code is involved (e..g RemoteServiceException).
>>> Examples can be found at:
>>>
>>> http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
>>> 20Handling
>>>
>>> - There are a couple of PMD violations in the binding package.
>>> When you get a chance, can you take care of them? (mvn -
>>> Psourcecheck)
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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: RMI binding questions
Posted by Jim Marino <jm...@myromatours.com>.
I think we still have the same problem of piling everything into one
project. We may wind up with a project having only one class (the
interface) but this may be the best solution since it avoids having
people update the Tuscany namespace with their extensions.
Jim
On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
> Would host-api be the right place for RMIHost?
>
> --
> Jeremy
>
> On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
>
>> I came across a couple of things related to the RMI binding today.
>> Venkat, when you get a chance, could you take a look at these?
>>
>> - Shouldn't RMIHost be in a separate extension package other than
>> SPI? This question relates to bindings in general. I would like to
>> avoid changing SPI for every new type of host provider we have.
>>
>> - The RMI exception hierarchy should extend from
>> TuscanyRuntimeException, TuscanyException, or an SCA exception if
>> application code is involved (e..g RemoteServiceException).
>> Examples can be found at:
>>
>> http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
>> 20Handling
>>
>> - There are a couple of PMD violations in the binding package.
>> When you get a chance, can you take care of them? (mvn -Psourcecheck)
>>
>> Thanks,
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> 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: RMI binding questions
Posted by Jeremy Boynes <jb...@apache.org>.
Would host-api be the right place for RMIHost?
--
Jeremy
On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
> I came across a couple of things related to the RMI binding today.
> Venkat, when you get a chance, could you take a look at these?
>
> - Shouldn't RMIHost be in a separate extension package other than
> SPI? This question relates to bindings in general. I would like to
> avoid changing SPI for every new type of host provider we have.
>
> - The RMI exception hierarchy should extend from
> TuscanyRuntimeException, TuscanyException, or an SCA exception if
> application code is involved (e..g RemoteServiceException).
> Examples can be found at:
>
> http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
> 20Handling
>
> - There are a couple of PMD violations in the binding package. When
> you get a chance, can you take care of them? (mvn -Psourcecheck)
>
> Thanks,
> Jim
>
>
> ---------------------------------------------------------------------
> 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