You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2006/07/19 03:52:16 UTC
CurrentCompositeContext.getContext() in chianti?
Does Tuscany, now with Chianti, take responsibility for setting up the
CurrentCompositeContext?
When I last understood the relevant code, at M1, Tuscany was more or less
requiring the host environment to set this up (then CurrentModuleContext).
This was done with Tomcat via the TuscanyValve, for example, (which I'm not
counting as part of Tuscany proper).
I see in chianti that
org.apache.tuscany.core.launcher.CompositeContextImplis setting up
CurrentCompositeContext but I'm not sure what to make of
this. Is Tuscany already setting up CurrentCompositeContext or might this
be an area in which to propose an improvement?
Thanks
Scott Kurz
Re: Imbedded model
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote:
> I'm about to check-in some code to support embedding Tuscany in any
> servlet container -- mostly a servlet listener that launches the
> runtime. It's not a lot of code (if it were, I'd be worried :), but I
> could still see moving it out into a separate place in the svn tree &
> build, once we figure out the layout/strategy for that.
>
> There's currently a "runtime" dir under "sca" where the equinox OSGi
> and "standalone" runtimes live.. but the standalone being just a
> packaging thing, and the equinox code isn't active in the build
> currently.
>
In another post I had proposed moving "standalone" into "distribution/
sca/standalone" to make it closer to what we had in M1. I was
thinking that all assembly/packaging stuff would be there.
If we do that, then perhaps your webapp support code and the equinox
(OSGi support) code become modules under runtime and we put all host-
integration type stuff there.
> I'm building off the core.launcher pkg, which seems flexible enough
> with some tweaks. I haven't thought too hard yet about further
> modularization -- I don't grok the code well enough yet to have a
> strong opinion..
Looking forward to the tweaks ;-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Imbedded model
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote:
> I'm about to check-in some code to support embedding Tuscany in any
> servlet container -- mostly a servlet listener that launches the
> runtime. It's not a lot of code (if it were, I'd be worried :), but I
> could still see moving it out into a separate place in the svn tree &
> build, once we figure out the layout/strategy for that.
>
That may be good so we're consistent across environments.
> There's currently a "runtime" dir under "sca" where the equinox OSGi
> and "standalone" runtimes live.. but the standalone being just a
> packaging thing, and the equinox code isn't active in the build
> currently.
>
> I'm building off the core.launcher pkg, which seems flexible enough
> with some tweaks. I haven't thought too hard yet about further
> modularization -- I don't grok the code well enough yet to have a
> strong opinion..
>
>> 4) What's the right way to think about Tuscany in relation to a
>> hosting environment? Is it always imbedded or are there use
>> cases where server function in imbedded in Tuscany?
>
> This is a key question IMO. I've been thinking mostly in terms of
> Tuscany embedding in existing server environments, mostly because
> those strike me as the most compelling use cases at this point (given
> SCA as a technology that purports to ease integration). But there's
> no reason why it can't go the other way around -- e.g. embedding
> server functionality into Tuscany via something like jetty. Indeed,
> the current standalone is a very basic "server" that embeds Tuscany.
>
Yea I'm working on the Jetty service now. I got sidetracked because
I ran across a configuration issue doing this related to annotation
processing (the ability to have constructor injection work with
multiple annotation extensions) so I've been spending time on getting
that working.
> On 7/19/06, scabooz <sc...@gmail.com> wrote:
>> Jeremy (and others of course),
>> There have been a few recent threads that have touched on the
>> various aspects of how Tuscany might be imbedded in a larger
>> runtime environment. At least Jeremy is already starting to form
>> a mental model of what that should look like, so I'm wondering
>> if someone could elaborate more in general about what you're
>> thinking. Questions like the following come to mind:
>> 1) Is there a distribution for imbedders?
>> 2) Is the runtime config mechanism extensible enough?
>> 3) Is the build modular enough to only build the pieces you
>> want to imbed? I saw some posts on modularizing the build
>> that seemed useful.
>>
>> ...there's many more questions...
>>
>> Hopefully that's enough to provoke a discussion.
>>
>>
>> Dave Booz
>>
>> ---------------------------------------------------------------------
>> 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: Imbedded model
Posted by Ken Tam <ke...@gmail.com>.
I'm about to check-in some code to support embedding Tuscany in any
servlet container -- mostly a servlet listener that launches the
runtime. It's not a lot of code (if it were, I'd be worried :), but I
could still see moving it out into a separate place in the svn tree &
build, once we figure out the layout/strategy for that.
There's currently a "runtime" dir under "sca" where the equinox OSGi
and "standalone" runtimes live.. but the standalone being just a
packaging thing, and the equinox code isn't active in the build
currently.
I'm building off the core.launcher pkg, which seems flexible enough
with some tweaks. I haven't thought too hard yet about further
modularization -- I don't grok the code well enough yet to have a
strong opinion..
> 4) What's the right way to think about Tuscany in relation to a
> hosting environment? Is it always imbedded or are there use
> cases where server function in imbedded in Tuscany?
This is a key question IMO. I've been thinking mostly in terms of
Tuscany embedding in existing server environments, mostly because
those strike me as the most compelling use cases at this point (given
SCA as a technology that purports to ease integration). But there's
no reason why it can't go the other way around -- e.g. embedding
server functionality into Tuscany via something like jetty. Indeed,
the current standalone is a very basic "server" that embeds Tuscany.
On 7/19/06, scabooz <sc...@gmail.com> wrote:
> Jeremy (and others of course),
> There have been a few recent threads that have touched on the
> various aspects of how Tuscany might be imbedded in a larger
> runtime environment. At least Jeremy is already starting to form
> a mental model of what that should look like, so I'm wondering
> if someone could elaborate more in general about what you're
> thinking. Questions like the following come to mind:
> 1) Is there a distribution for imbedders?
> 2) Is the runtime config mechanism extensible enough?
> 3) Is the build modular enough to only build the pieces you
> want to imbed? I saw some posts on modularizing the build
> that seemed useful.
>
> ...there's many more questions...
>
> Hopefully that's enough to provoke a discussion.
>
>
> Dave Booz
>
> ---------------------------------------------------------------------
> 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: Imbedded model
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 25, 2006, at 10:50 AM, Scott Kurz wrote:
> I have a couple thoughts on the subject of Host APIs:
>
> First, I think it would be valuable for the host environment to be
> able to
> access any CompositeContext via some sort of namespace of Composites
> registered with a given runtime instance... or to at least access any
> top-level Composite.
> (Maybe it would best left up to the host environment to manage the
> naming
> convention and not Tuscany. )
Composite's in the runtime are organized into a navigable hierarchy
that the host (or anything with access to the runtime) can access.
This specifically excludes normal application code as that has no
real business digging around in the runtime. However, it should be
available though alternative APIs such as those used for management
(which suitably privileged user code could use).
> For example, IIRC, back in the March tagged version (and probably
> still in
> M1) a given module was registered under the runtime context along
> with a key
> corresponding to the name of the WAR (or maybe it was the WAR's
> context
> root) that the module was packaged in.
When you deploy a ComponentDefinition, its name is used as the name
of the node in the tree of runtime Components. This gives the host
(specifically whatever code is invoking the deployer) complete
control over the name of the node.
>
> Some sort of global Tuscany naming scheme seems like it useful.
> For one, it
> would give the host more flexibility in setting up
> CurrentCompositeContext
> (assuming the spec leaves something to the implementation here). I
> also
> have it in my mind that this would help in implementing a binding,
> allowing
> the binding to grab the right CompositeContext and the
> EntryPointContext out
> of it. However, in reading other emails I can see that what other
> people
> have in mind is to use a separate host API to register a specific
> reference
> with a binding-level object.
As above, the host has complete control over naming already.
The builder for the binding type has complete control over what
information is made available to the binding. A runtime artifact like
a binding should not be "grabbing" anything from the system - a major
feature of the SCA wiring model is that it allows these references to
be resolved by the runtime in advance.
The host SPI is a way of abstracting the host environment from
Tuscany runtime components so that the builders do not get tied to a
specific environment. For example, a web-service Service binding may
want to receive requests on a specific URL. It needs a way to
communicate to the host that requests over the HTTP protocol for a
certain URL (or URL pattern) should be directed to it. It may not
actually care if the host implements this as a servlet, a Tomcat
handler, an async channel, a HTTPD module, or whatever.
A key thing here is that the contact between the host and the runtime
is bidirectional - the host uses APIs implemented by the runtime to
perform operations on the Tuscany environment, and Tuscany service
components use SPIs implemented by the host to perform operations on
the host environment.
>
> Second, I wonder if a single system-level WorkManager is too coarse-
> grained,
> and if instead it would be nicer to provide a WorkManager setter at
> other
> levels, (say, for specific bindings). I understand Jeremy's point
> that a
> single WorkManager allows for a single point of configuration for the
> underlying thread pool. However, if the host environment has
> disparate
> thread pools and/or WorkManagers to begin with then it would have
> to provide
> a single WorkManager facade just for Tuscany just to defer the
> complexity to
> another level.
I think that it is better for the host to provide such a facade over
its complexity rather than expose that to Tuscany services.
What we do need to do is provide metadata with submitted work so that
the work manager implementation has the information to make the
decisions on how to route the work request. For example, we should
add information about how long work is expected to run, whether it is
likely to block on I/O, what priority it has relative to other work,
and so forth.
And as Jim said, there is nothing to prevent you from deploying
multiple work managers and explicitly wiring things to them. If a
component has a need for a dedicated thread pool it can set one up.
Before doing that though it would be worth considering the implications.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Imbedded model
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 25, 2006, at 7:24 PM, Scott Kurz wrote:
>
> So the method I was referring to had signature:
>
> ModuleComponent loadModuleComponent(String name, String uri)
The replacement is
Component<?> deploy(CompositeComponent<?> parent,
ComponentDefinition<I> componentDefinition)
where the parent determines which composite the new component will be
added to and the definition contains things like the name of the
component etc.
> The name and uri are not calculated by Tuscany, and not implicit in
> the
> SCDL.
They are supplied by the host in the definition being deployed.
>
> Maybe I should have phrased my question: will Tuscany's host API
> support
> registration of Composite Context name and uri supplied by the host
> environment?
For now we do name. Adding URI should be easy once we figure out what
it should be (from the spec) - in 0.9 we mostly ignored it.
> Maybe this will be one option among several, including some where the
> name,uri are supplied by Tuscany or calculated somehow.
Depends what you mean by "Tuscany" - the core will never take a guess
at these, it will always use values supplied to the deployer. They
could be specified by the user, or they could be determined by the
deployment environment (for example, the directory scanner uses the
filename sans extension as the component name).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Imbedded model
Posted by Scott Kurz <sc...@gmail.com>.
Jim,
Thanks for your response..replies below...
On 7/25/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Jul 25, 2006, at 10:50 AM, Scott Kurz wrote:
>
> > I have a couple thoughts on the subject of Host APIs:
> >
> > First, I think it would be valuable for the host environment to be
> > able to
> > access any CompositeContext via some sort of namespace of Composites
> > registered with a given runtime instance... or to at least access any
> > top-level Composite.
> > (Maybe it would best left up to the host environment to manage the
> > naming
> > convention and not Tuscany. )
> >
> For management purposes it may make sense for a host to access
> composites but I think it should recurse through the composite tree
> as opposed to having a global namespace.
>
> > For example, IIRC, back in the March tagged version (and probably
> > still in
> > M1) a given module was registered under the runtime context along
> > with a key
> > corresponding to the name of the WAR (or maybe it was the WAR's
> > context
> > root) that the module was packaged in.
> >
> I think this is problematic. In the spec we were careful not to tie
> the addressing scheme to the structure of the composite tree since
> URIs shouldn't necessarily reflect "application" structure.
Yes, I figured the namespace would be hierarchical, not flat.
I mentioned the "old" (not really so old since M1 worked this way too)
Tomcat integration's use of WAR-level info to pass as the 'name' and 'uri'
on this call ... not because this was a good way to do it... but to
illustrate that it was the host environment that determines the name and uri
to "register" a composite context at.
So the method I was referring to had signature:
ModuleComponent loadModuleComponent(String name, String uri)
The name and uri are not calculated by Tuscany, and not implicit in the
SCDL.
Maybe I should have phrased my question: will Tuscany's host API support
registration of Composite Context name and uri supplied by the host
environment?
Maybe this will be one option among several, including some where the
name,uri are supplied by Tuscany or calculated somehow.
> Some sort of global Tuscany naming scheme seems like it useful.
> > For one, it
> > would give the host more flexibility in setting up
> > CurrentCompositeContext
> > (assuming the spec leaves something to the implementation here). I
> > also
> > have it in my mind that this would help in implementing a binding,
> > allowing
> > the binding to grab the right CompositeContext and the
> > EntryPointContext out
> > of it. However, in reading other emails I can see that what other
> > people
> > have in mind is to use a separate host API to register a specific
> > reference
> > with a binding-level object.
> This may be more complicated than what we need. A basic notification/
> registration mechanism (e.g. the host API) allows the binding to stay
> simple, decouples references from protocol bindings (e.g. Axis) from
> transport bindings (e.g. Jetty) and maintains a separation between
> configuration and runtime artifacts. For example, I'm not sure it is
> a good thing for binding code to interpret SCDL and then dig around
> in the composite tree for a service or reference.
I've read a few statements now saying this sort of thing: from Jeremy, in
the callbacks discussion, here. However I'm too dense to really envision
what you're talking about until seeing a sample of how this type of scheme
works.
The JettyServiceImpl I see now (grabbed Friday) only seems to "implement"
one Host API, the ServletHost.. however I put that in quotes since the
registerMapping() method is actually left blank. So this obviously isn't
what everyone is talking about.
I look forward to seeing the first example of this type of implementation so
I can follow this discussion better.
> Second, I wonder if a single system-level WorkManager is too coarse-
> > grained,
> > and if instead it would be nicer to provide a WorkManager setter at
> > other
> > levels, (say, for specific bindings).
> We can do this today with autowire; it's just a matter of
> configuration. One thing we may want is some notion of priority
> queues though.
>
> > I understand Jeremy's point that a
> > single WorkManager allows for a single point of configuration for the
> > underlying thread pool. However, if the host environment has
> > disparate
> > thread pools and/or WorkManagers to begin with then it would have
> > to provide
> > a single WorkManager facade just for Tuscany just to defer the
> > complexity to
> > another level.
> >
> Tuscany could wire to multiple work managers as well. We aren't bound
> to one, although as an out-of-the-box configuration it seems like a
> good idea.
Thanks for clarifying that.
> Not sure which is better, and since I'm not backing up this
> > suggestion with
> > code now just consider it food for thought for now.
> >
> Ideas are always good :-) Keep them coming.
> > Scott Kurz
> >
> >
> > On 7/19/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> Comments inline ...
> >>
> >> On Jul 19, 2006, at 5:20 PM, scabooz wrote:
> >>
> >> > Jeremy (and others of course),
> >> > There have been a few recent threads that have touched on the
> >> > various aspects of how Tuscany might be imbedded in a larger
> >> > runtime environment. At least Jeremy is already starting to form
> >> > a mental model of what that should look like, so I'm wondering
> >> > if someone could elaborate more in general about what you're
> >> > thinking. Questions like the following come to mind:
> >> > 1) Is there a distribution for imbedders?
> >>
> >> There might be a more fundamental question here: what's a
> >> distribution?
> >>
> >> For M1, we focused on a end-user distribution, by which I mean
> >> something someone could download, unpack and everything that they
> >> needed to run Tuscany would be there. As a result it ended by a bit
> >> kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
> >> etc. and ended up just a tadge under 50MB in size. I don't think this
> >> will scale as we add more functionality.
> >>
> >> I would suggest that we continue to produce distributions aimed at
> >> end-users but tailor them to particular runtime environments.
> >> Specific ones that come to mind would be a simple client, one with
> >> Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so
> >> on. These may include the environment (like we did with Tomcat in M1)
> >> or they may packages that can install on top (e.g. as a CAR for
> >> Geronimo).
> >>
> >> Each one of these would be tailored for the runtime - for example,
> >> the Tomcat one would be web-oriented, the Celtix one message-
> >> oriented. The baseline distribution could be extended by adding in
> >> plugins that would be distributed separately. This is a similar model
> >> to e.g. Eclipse, Maven, etc.
> >>
> >> We would also distribute each module from the build through the Maven
> >> repository system. During incubation, all artifacts would be
> >> available from the Apache snapshot repository; post-incubation,
> >> released artifacts would also be available through the mirror system
> >> (e.g. from ibiblio.org).
> >>
> >> Someone looking to embed Tuscany could go about it in a couple of
> >> ways. One would be to start with one of our distributions, take it
> >> apart and integrate it into their environment. This would have the
> >> advantage that all artifacts would have been tested to work with each
> >> other but may mean that they are dependent on more than they need or
> >> that they would have to wait for a full release to get fixes etc.
> >>
> >> Alternatively they could work directly with the artifacts from the
> >> maven repo. In trunk we are now using the maven assembly plugin to
> >> build the distribution and it would be trivial for someone to
> >> assemble a different distribution just be reconfiguring that plugin.
> >>
> >> > 2) Is the runtime config mechanism extensible enough?
> >>
> >> It's based on the SCA config mechanism so I hope so - otherwise we
> >> will have valuable feedback for the spec ;-)
> >>
> >> The runtime is constructed by deploying a SCA component implemented
> >> by an SCA composite (which contains other SCA components). Which
> >> components are present are determined by the content of the composite
> >> and they can be configured in the same way any component can
> >> (including via xpath expressions once we get complex properties
> >> working).
> >>
> >> > 3) Is the build modular enough to only build the pieces you want to
> >> > imbed? I saw some posts on modularizing the build
> >> > that seemed useful.
> >>
> >> At this point probably not - for example, in order to work around the
> >> issues building JAXB Meeraj had to hack a couple of the pom files and
> >> that is not very desirable. As you said there have been a couple of
> >> posts on making the build more modular and it may be better to
> >> continue on that thread.
> >>
> >> > 4) What's the right way to think about Tuscany in relation to a
> >> > hosting environment? Is it always imbedded or are there use
> >> > cases where server function in imbedded in Tuscany?
> >> >
> >>
> >> I consider the "core" to be the bit that is always embedded in some
> >> host environment, with the core being the bit that provides the SPIs
> >> and the framework for running system services. The host is
> >> responsible for bootstrapping the basic runtime and for determining
> >> which services will be started. Such services will include things
> >> like programming models, bindings and policies as well as normal
> >> application components.
> >>
> >> Different hosts will start different services depending on what type
> >> of host they are. Some may just be clients, some may start "server"
> >> services in Tuscany and some may start "bridge" services that
> >> transfer function between the host and the Tuscany runtime.
> >>
> >> > ...there's many more questions...
> >>
> >> We probably should work on a guide for embedding Tuscany with more
> >> information on the bootstrap APIs. So, ask away so we can get the
> >> right information there and tidy up the JavaDoc.
> >>
> >> --
> >> 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: Imbedded model
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 25, 2006, at 10:50 AM, Scott Kurz wrote:
> I have a couple thoughts on the subject of Host APIs:
>
> First, I think it would be valuable for the host environment to be
> able to
> access any CompositeContext via some sort of namespace of Composites
> registered with a given runtime instance... or to at least access any
> top-level Composite.
> (Maybe it would best left up to the host environment to manage the
> naming
> convention and not Tuscany. )
>
For management purposes it may make sense for a host to access
composites but I think it should recurse through the composite tree
as opposed to having a global namespace.
> For example, IIRC, back in the March tagged version (and probably
> still in
> M1) a given module was registered under the runtime context along
> with a key
> corresponding to the name of the WAR (or maybe it was the WAR's
> context
> root) that the module was packaged in.
>
I think this is problematic. In the spec we were careful not to tie
the addressing scheme to the structure of the composite tree since
URIs shouldn't necessarily reflect "application" structure.
> Some sort of global Tuscany naming scheme seems like it useful.
> For one, it
> would give the host more flexibility in setting up
> CurrentCompositeContext
> (assuming the spec leaves something to the implementation here). I
> also
> have it in my mind that this would help in implementing a binding,
> allowing
> the binding to grab the right CompositeContext and the
> EntryPointContext out
> of it. However, in reading other emails I can see that what other
> people
> have in mind is to use a separate host API to register a specific
> reference
> with a binding-level object.
This may be more complicated than what we need. A basic notification/
registration mechanism (e.g. the host API) allows the binding to stay
simple, decouples references from protocol bindings (e.g. Axis) from
transport bindings (e.g. Jetty) and maintains a separation between
configuration and runtime artifacts. For example, I'm not sure it is
a good thing for binding code to interpret SCDL and then dig around
in the composite tree for a service or reference.
>
> Second, I wonder if a single system-level WorkManager is too coarse-
> grained,
> and if instead it would be nicer to provide a WorkManager setter at
> other
> levels, (say, for specific bindings).
We can do this today with autowire; it's just a matter of
configuration. One thing we may want is some notion of priority
queues though.
> I understand Jeremy's point that a
> single WorkManager allows for a single point of configuration for the
> underlying thread pool. However, if the host environment has
> disparate
> thread pools and/or WorkManagers to begin with then it would have
> to provide
> a single WorkManager facade just for Tuscany just to defer the
> complexity to
> another level.
>
Tuscany could wire to multiple work managers as well. We aren't bound
to one, although as an out-of-the-box configuration it seems like a
good idea.
> Not sure which is better, and since I'm not backing up this
> suggestion with
> code now just consider it food for thought for now.
>
Ideas are always good :-) Keep them coming.
> Scott Kurz
>
>
> On 7/19/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> Comments inline ...
>>
>> On Jul 19, 2006, at 5:20 PM, scabooz wrote:
>>
>> > Jeremy (and others of course),
>> > There have been a few recent threads that have touched on the
>> > various aspects of how Tuscany might be imbedded in a larger
>> > runtime environment. At least Jeremy is already starting to form
>> > a mental model of what that should look like, so I'm wondering
>> > if someone could elaborate more in general about what you're
>> > thinking. Questions like the following come to mind:
>> > 1) Is there a distribution for imbedders?
>>
>> There might be a more fundamental question here: what's a
>> distribution?
>>
>> For M1, we focused on a end-user distribution, by which I mean
>> something someone could download, unpack and everything that they
>> needed to run Tuscany would be there. As a result it ended by a bit
>> kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
>> etc. and ended up just a tadge under 50MB in size. I don't think this
>> will scale as we add more functionality.
>>
>> I would suggest that we continue to produce distributions aimed at
>> end-users but tailor them to particular runtime environments.
>> Specific ones that come to mind would be a simple client, one with
>> Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so
>> on. These may include the environment (like we did with Tomcat in M1)
>> or they may packages that can install on top (e.g. as a CAR for
>> Geronimo).
>>
>> Each one of these would be tailored for the runtime - for example,
>> the Tomcat one would be web-oriented, the Celtix one message-
>> oriented. The baseline distribution could be extended by adding in
>> plugins that would be distributed separately. This is a similar model
>> to e.g. Eclipse, Maven, etc.
>>
>> We would also distribute each module from the build through the Maven
>> repository system. During incubation, all artifacts would be
>> available from the Apache snapshot repository; post-incubation,
>> released artifacts would also be available through the mirror system
>> (e.g. from ibiblio.org).
>>
>> Someone looking to embed Tuscany could go about it in a couple of
>> ways. One would be to start with one of our distributions, take it
>> apart and integrate it into their environment. This would have the
>> advantage that all artifacts would have been tested to work with each
>> other but may mean that they are dependent on more than they need or
>> that they would have to wait for a full release to get fixes etc.
>>
>> Alternatively they could work directly with the artifacts from the
>> maven repo. In trunk we are now using the maven assembly plugin to
>> build the distribution and it would be trivial for someone to
>> assemble a different distribution just be reconfiguring that plugin.
>>
>> > 2) Is the runtime config mechanism extensible enough?
>>
>> It's based on the SCA config mechanism so I hope so - otherwise we
>> will have valuable feedback for the spec ;-)
>>
>> The runtime is constructed by deploying a SCA component implemented
>> by an SCA composite (which contains other SCA components). Which
>> components are present are determined by the content of the composite
>> and they can be configured in the same way any component can
>> (including via xpath expressions once we get complex properties
>> working).
>>
>> > 3) Is the build modular enough to only build the pieces you want to
>> > imbed? I saw some posts on modularizing the build
>> > that seemed useful.
>>
>> At this point probably not - for example, in order to work around the
>> issues building JAXB Meeraj had to hack a couple of the pom files and
>> that is not very desirable. As you said there have been a couple of
>> posts on making the build more modular and it may be better to
>> continue on that thread.
>>
>> > 4) What's the right way to think about Tuscany in relation to a
>> > hosting environment? Is it always imbedded or are there use
>> > cases where server function in imbedded in Tuscany?
>> >
>>
>> I consider the "core" to be the bit that is always embedded in some
>> host environment, with the core being the bit that provides the SPIs
>> and the framework for running system services. The host is
>> responsible for bootstrapping the basic runtime and for determining
>> which services will be started. Such services will include things
>> like programming models, bindings and policies as well as normal
>> application components.
>>
>> Different hosts will start different services depending on what type
>> of host they are. Some may just be clients, some may start "server"
>> services in Tuscany and some may start "bridge" services that
>> transfer function between the host and the Tuscany runtime.
>>
>> > ...there's many more questions...
>>
>> We probably should work on a guide for embedding Tuscany with more
>> information on the bootstrap APIs. So, ask away so we can get the
>> right information there and tidy up the JavaDoc.
>>
>> --
>> 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: Imbedded model
Posted by Scott Kurz <sc...@gmail.com>.
I have a couple thoughts on the subject of Host APIs:
First, I think it would be valuable for the host environment to be able to
access any CompositeContext via some sort of namespace of Composites
registered with a given runtime instance... or to at least access any
top-level Composite.
(Maybe it would best left up to the host environment to manage the naming
convention and not Tuscany. )
For example, IIRC, back in the March tagged version (and probably still in
M1) a given module was registered under the runtime context along with a key
corresponding to the name of the WAR (or maybe it was the WAR's context
root) that the module was packaged in.
Some sort of global Tuscany naming scheme seems like it useful. For one, it
would give the host more flexibility in setting up CurrentCompositeContext
(assuming the spec leaves something to the implementation here). I also
have it in my mind that this would help in implementing a binding, allowing
the binding to grab the right CompositeContext and the EntryPointContext out
of it. However, in reading other emails I can see that what other people
have in mind is to use a separate host API to register a specific reference
with a binding-level object.
Second, I wonder if a single system-level WorkManager is too coarse-grained,
and if instead it would be nicer to provide a WorkManager setter at other
levels, (say, for specific bindings). I understand Jeremy's point that a
single WorkManager allows for a single point of configuration for the
underlying thread pool. However, if the host environment has disparate
thread pools and/or WorkManagers to begin with then it would have to provide
a single WorkManager facade just for Tuscany just to defer the complexity to
another level.
Not sure which is better, and since I'm not backing up this suggestion with
code now just consider it food for thought for now.
Scott Kurz
On 7/19/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Comments inline ...
>
> On Jul 19, 2006, at 5:20 PM, scabooz wrote:
>
> > Jeremy (and others of course),
> > There have been a few recent threads that have touched on the
> > various aspects of how Tuscany might be imbedded in a larger
> > runtime environment. At least Jeremy is already starting to form
> > a mental model of what that should look like, so I'm wondering
> > if someone could elaborate more in general about what you're
> > thinking. Questions like the following come to mind:
> > 1) Is there a distribution for imbedders?
>
> There might be a more fundamental question here: what's a distribution?
>
> For M1, we focused on a end-user distribution, by which I mean
> something someone could download, unpack and everything that they
> needed to run Tuscany would be there. As a result it ended by a bit
> kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
> etc. and ended up just a tadge under 50MB in size. I don't think this
> will scale as we add more functionality.
>
> I would suggest that we continue to produce distributions aimed at
> end-users but tailor them to particular runtime environments.
> Specific ones that come to mind would be a simple client, one with
> Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so
> on. These may include the environment (like we did with Tomcat in M1)
> or they may packages that can install on top (e.g. as a CAR for
> Geronimo).
>
> Each one of these would be tailored for the runtime - for example,
> the Tomcat one would be web-oriented, the Celtix one message-
> oriented. The baseline distribution could be extended by adding in
> plugins that would be distributed separately. This is a similar model
> to e.g. Eclipse, Maven, etc.
>
> We would also distribute each module from the build through the Maven
> repository system. During incubation, all artifacts would be
> available from the Apache snapshot repository; post-incubation,
> released artifacts would also be available through the mirror system
> (e.g. from ibiblio.org).
>
> Someone looking to embed Tuscany could go about it in a couple of
> ways. One would be to start with one of our distributions, take it
> apart and integrate it into their environment. This would have the
> advantage that all artifacts would have been tested to work with each
> other but may mean that they are dependent on more than they need or
> that they would have to wait for a full release to get fixes etc.
>
> Alternatively they could work directly with the artifacts from the
> maven repo. In trunk we are now using the maven assembly plugin to
> build the distribution and it would be trivial for someone to
> assemble a different distribution just be reconfiguring that plugin.
>
> > 2) Is the runtime config mechanism extensible enough?
>
> It's based on the SCA config mechanism so I hope so - otherwise we
> will have valuable feedback for the spec ;-)
>
> The runtime is constructed by deploying a SCA component implemented
> by an SCA composite (which contains other SCA components). Which
> components are present are determined by the content of the composite
> and they can be configured in the same way any component can
> (including via xpath expressions once we get complex properties
> working).
>
> > 3) Is the build modular enough to only build the pieces you want to
> > imbed? I saw some posts on modularizing the build
> > that seemed useful.
>
> At this point probably not - for example, in order to work around the
> issues building JAXB Meeraj had to hack a couple of the pom files and
> that is not very desirable. As you said there have been a couple of
> posts on making the build more modular and it may be better to
> continue on that thread.
>
> > 4) What's the right way to think about Tuscany in relation to a
> > hosting environment? Is it always imbedded or are there use
> > cases where server function in imbedded in Tuscany?
> >
>
> I consider the "core" to be the bit that is always embedded in some
> host environment, with the core being the bit that provides the SPIs
> and the framework for running system services. The host is
> responsible for bootstrapping the basic runtime and for determining
> which services will be started. Such services will include things
> like programming models, bindings and policies as well as normal
> application components.
>
> Different hosts will start different services depending on what type
> of host they are. Some may just be clients, some may start "server"
> services in Tuscany and some may start "bridge" services that
> transfer function between the host and the Tuscany runtime.
>
> > ...there's many more questions...
>
> We probably should work on a guide for embedding Tuscany with more
> information on the bootstrap APIs. So, ask away so we can get the
> right information there and tidy up the JavaDoc.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Imbedded model
Posted by Jim Marino <jm...@myromatours.com>.
Just a few minor comments inline...
On Jul 19, 2006, at 6:33 PM, Jeremy Boynes wrote:
> Comments inline ...
>
> On Jul 19, 2006, at 5:20 PM, scabooz wrote:
>
>> Jeremy (and others of course),
>> There have been a few recent threads that have touched on the
>> various aspects of how Tuscany might be imbedded in a larger
>> runtime environment. At least Jeremy is already starting to form
>> a mental model of what that should look like, so I'm wondering
>> if someone could elaborate more in general about what you're
>> thinking. Questions like the following come to mind:
>> 1) Is there a distribution for imbedders?
>
> There might be a more fundamental question here: what's a
> distribution?
>
> For M1, we focused on a end-user distribution, by which I mean
> something someone could download, unpack and everything that they
> needed to run Tuscany would be there. As a result it ended by a bit
> kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
> etc. and ended up just a tadge under 50MB in size. I don't think
> this will scale as we add more functionality.
>
> I would suggest that we continue to produce distributions aimed at
> end-users but tailor them to particular runtime environments.
> Specific ones that come to mind would be a simple client, one with
> Tomcat, one with Celtix, one with Equinox, one with Geronimo, and
> so on. These may include the environment (like we did with Tomcat
> in M1) or they may packages that can install on top (e.g. as a CAR
> for Geronimo).
>
> Each one of these would be tailored for the runtime - for example,
> the Tomcat one would be web-oriented, the Celtix one message-
> oriented. The baseline distribution could be extended by adding in
> plugins that would be distributed separately. This is a similar
> model to e.g. Eclipse, Maven, etc.
>
> We would also distribute each module from the build through the
> Maven repository system. During incubation, all artifacts would be
> available from the Apache snapshot repository; post-incubation,
> released artifacts would also be available through the mirror
> system (e.g. from ibiblio.org).
>
> Someone looking to embed Tuscany could go about it in a couple of
> ways. One would be to start with one of our distributions, take it
> apart and integrate it into their environment. This would have the
> advantage that all artifacts would have been tested to work with
> each other but may mean that they are dependent on more than they
> need or that they would have to wait for a full release to get
> fixes etc.
>
> Alternatively they could work directly with the artifacts from the
> maven repo. In trunk we are now using the maven assembly plugin to
> build the distribution and it would be trivial for someone to
> assemble a different distribution just be reconfiguring that plugin.
One of the things we've been toying with (alluded to by Jeremy) is
the (optional) ability for the core to pull down extension
dependencies from maven repositories. This would be kind of like the
server equivalent to Eclipse's plugin installation.
>
>> 2) Is the runtime config mechanism extensible enough?
>
> It's based on the SCA config mechanism so I hope so - otherwise we
> will have valuable feedback for the spec ;-)
>
> The runtime is constructed by deploying a SCA component implemented
> by an SCA composite (which contains other SCA components). Which
> components are present are determined by the content of the
> composite and they can be configured in the same way any component
> can (including via xpath expressions once we get complex properties
> working).
Dave, it would be good if you can also outline some of the use cases
you have in mind so we can make sure we cover them.
>
>> 3) Is the build modular enough to only build the pieces you want
>> to imbed? I saw some posts on modularizing the build
>> that seemed useful.
>
> At this point probably not - for example, in order to work around
> the issues building JAXB Meeraj had to hack a couple of the pom
> files and that is not very desirable. As you said there have been a
> couple of posts on making the build more modular and it may be
> better to continue on that thread.
>
>> 4) What's the right way to think about Tuscany in relation to a
>> hosting environment? Is it always imbedded or are there use
>> cases where server function in imbedded in Tuscany?
>>
>
> I consider the "core" to be the bit that is always embedded in some
> host environment, with the core being the bit that provides the
> SPIs and the framework for running system services. The host is
> responsible for bootstrapping the basic runtime and for determining
> which services will be started. Such services will include things
> like programming models, bindings and policies as well as normal
> application components.
>
> Different hosts will start different services depending on what
> type of host they are. Some may just be clients, some may start
> "server" services in Tuscany and some may start "bridge" services
> that transfer function between the host and the Tuscany runtime.
>
>> ...there's many more questions...
>
> We probably should work on a guide for embedding Tuscany with more
> information on the bootstrap APIs. So, ask away so we can get the
> right information there and tidy up the JavaDoc.
>
> --
> 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: Imbedded model
Posted by Jeremy Boynes <jb...@apache.org>.
Comments inline ...
On Jul 19, 2006, at 5:20 PM, scabooz wrote:
> Jeremy (and others of course),
> There have been a few recent threads that have touched on the
> various aspects of how Tuscany might be imbedded in a larger
> runtime environment. At least Jeremy is already starting to form
> a mental model of what that should look like, so I'm wondering
> if someone could elaborate more in general about what you're
> thinking. Questions like the following come to mind:
> 1) Is there a distribution for imbedders?
There might be a more fundamental question here: what's a distribution?
For M1, we focused on a end-user distribution, by which I mean
something someone could download, unpack and everything that they
needed to run Tuscany would be there. As a result it ended by a bit
kitchen-sick like containing, for example, Tomcat, Axis2, Celtix,
etc. and ended up just a tadge under 50MB in size. I don't think this
will scale as we add more functionality.
I would suggest that we continue to produce distributions aimed at
end-users but tailor them to particular runtime environments.
Specific ones that come to mind would be a simple client, one with
Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so
on. These may include the environment (like we did with Tomcat in M1)
or they may packages that can install on top (e.g. as a CAR for
Geronimo).
Each one of these would be tailored for the runtime - for example,
the Tomcat one would be web-oriented, the Celtix one message-
oriented. The baseline distribution could be extended by adding in
plugins that would be distributed separately. This is a similar model
to e.g. Eclipse, Maven, etc.
We would also distribute each module from the build through the Maven
repository system. During incubation, all artifacts would be
available from the Apache snapshot repository; post-incubation,
released artifacts would also be available through the mirror system
(e.g. from ibiblio.org).
Someone looking to embed Tuscany could go about it in a couple of
ways. One would be to start with one of our distributions, take it
apart and integrate it into their environment. This would have the
advantage that all artifacts would have been tested to work with each
other but may mean that they are dependent on more than they need or
that they would have to wait for a full release to get fixes etc.
Alternatively they could work directly with the artifacts from the
maven repo. In trunk we are now using the maven assembly plugin to
build the distribution and it would be trivial for someone to
assemble a different distribution just be reconfiguring that plugin.
> 2) Is the runtime config mechanism extensible enough?
It's based on the SCA config mechanism so I hope so - otherwise we
will have valuable feedback for the spec ;-)
The runtime is constructed by deploying a SCA component implemented
by an SCA composite (which contains other SCA components). Which
components are present are determined by the content of the composite
and they can be configured in the same way any component can
(including via xpath expressions once we get complex properties
working).
> 3) Is the build modular enough to only build the pieces you want to
> imbed? I saw some posts on modularizing the build
> that seemed useful.
At this point probably not - for example, in order to work around the
issues building JAXB Meeraj had to hack a couple of the pom files and
that is not very desirable. As you said there have been a couple of
posts on making the build more modular and it may be better to
continue on that thread.
> 4) What's the right way to think about Tuscany in relation to a
> hosting environment? Is it always imbedded or are there use
> cases where server function in imbedded in Tuscany?
>
I consider the "core" to be the bit that is always embedded in some
host environment, with the core being the bit that provides the SPIs
and the framework for running system services. The host is
responsible for bootstrapping the basic runtime and for determining
which services will be started. Such services will include things
like programming models, bindings and policies as well as normal
application components.
Different hosts will start different services depending on what type
of host they are. Some may just be clients, some may start "server"
services in Tuscany and some may start "bridge" services that
transfer function between the host and the Tuscany runtime.
> ...there's many more questions...
We probably should work on a guide for embedding Tuscany with more
information on the bootstrap APIs. So, ask away so we can get the
right information there and tidy up the JavaDoc.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Imbedded model
Posted by scabooz <sc...@gmail.com>.
Jeremy (and others of course),
There have been a few recent threads that have touched on the
various aspects of how Tuscany might be imbedded in a larger
runtime environment. At least Jeremy is already starting to form
a mental model of what that should look like, so I'm wondering
if someone could elaborate more in general about what you're
thinking. Questions like the following come to mind:
1) Is there a distribution for imbedders?
2) Is the runtime config mechanism extensible enough?
3) Is the build modular enough to only build the pieces you
want to imbed? I saw some posts on modularizing the build
that seemed useful.
4) What's the right way to think about Tuscany in relation to a
hosting environment? Is it always imbedded or are there use
cases where server function in imbedded in Tuscany?
...there's many more questions...
Hopefully that's enough to provoke a discussion.
Dave Booz
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: CurrentCompositeContext.getContext() in chianti?
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 19, 2006, at 6:02 AM, Scott Kurz wrote:
> Would you agree it would make sense for Tuscany to provide this
> function
> rather than the host env?
>
> If this is the host env's job then it must get a notification every
> time a
> Composite boundary is crossed in the case of recursively nested
> composites. True it may be easy enough for the host env to set up
> CurrentCompositeContext for the outermost, deployable composite
> (there's
> likely a more correct term). But it seems simpler to consistently
> have
> Tuscany set up this context as a step in the invocation chain
> rather than to
> have the host to have to set up the context correctly for both
> outer-level
> and nested composites.
>
> Or is there already such a notification mechanism for crossing
> Composite
> boundary in effect? (I apologize that I haven't studied the code
> extensively to understand this; I'm mostly relying on learning via
> running
> samples and stepping through the debugger).
The host env is responsible for setting this up for unmanaged code
i.e. code that is running that is not managed by the Tuscany runtime.
By definition, the runtime can't do this (I'm classifying launcher a
host code not runtime code).
Once we have entered managed code then the runtime takes over. It is
responsible for creating the invocation chains and would handle the
context switch as appropriate - I was thinking this would be in the
code that supports Services exposed by a Composite; I don't think
it's there yet. It may well need to set the Thread context
ClassLoader at the same time.
All this switching makes me worried, especially when we have closely
coupled composites. Having to intercept every call to a component
implemented by a composite just to reset context that is never used
seems like a lot of overhead. In addition, references to services
obtained this way bypass all the context associated with a component
(for example, policy information defined on a reference). I would
like to see this API go away do that it cannot be used from within
managed code, with us finding a simpler solution for unmanaged code.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: CurrentCompositeContext.getContext() in chianti?
Posted by Scott Kurz <sc...@gmail.com>.
Would you agree it would make sense for Tuscany to provide this function
rather than the host env?
If this is the host env's job then it must get a notification every time a
Composite boundary is crossed in the case of recursively nested
composites. True it may be easy enough for the host env to set up
CurrentCompositeContext for the outermost, deployable composite (there's
likely a more correct term). But it seems simpler to consistently have
Tuscany set up this context as a step in the invocation chain rather than to
have the host to have to set up the context correctly for both outer-level
and nested composites.
Or is there already such a notification mechanism for crossing Composite
boundary in effect? (I apologize that I haven't studied the code
extensively to understand this; I'm mostly relying on learning via running
samples and stepping through the debugger).
Scott
On 7/18/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Responsibility still lies with the host environment.
>
> In the launcher's case, it is the J2SE (command line) host
> environment so it sets up the context before calling the application
> code; it is kind of similar to a J2EE application client container.
>
> We do a similar thing in SCATestCase to set up the environment before
> calling the user's TestCase (we do it in setUp).
>
> --
> Jeremy
>
> On Jul 18, 2006, at 6:52 PM, Scott Kurz wrote:
>
> > Does Tuscany, now with Chianti, take responsibility for setting up the
> > CurrentCompositeContext?
> >
> > When I last understood the relevant code, at M1, Tuscany was more
> > or less
> > requiring the host environment to set this up (then
> > CurrentModuleContext).
> > This was done with Tomcat via the TuscanyValve, for example, (which
> > I'm not
> > counting as part of Tuscany proper).
> >
> > I see in chianti that
> > org.apache.tuscany.core.launcher.CompositeContextImplis setting up
> > CurrentCompositeContext but I'm not sure what to make of
> > this. Is Tuscany already setting up CurrentCompositeContext or
> > might this
> > be an area in which to propose an improvement?
> >
> > Thanks
> > Scott Kurz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: CurrentCompositeContext.getContext() in chianti?
Posted by Jeremy Boynes <jb...@apache.org>.
Responsibility still lies with the host environment.
In the launcher's case, it is the J2SE (command line) host
environment so it sets up the context before calling the application
code; it is kind of similar to a J2EE application client container.
We do a similar thing in SCATestCase to set up the environment before
calling the user's TestCase (we do it in setUp).
--
Jeremy
On Jul 18, 2006, at 6:52 PM, Scott Kurz wrote:
> Does Tuscany, now with Chianti, take responsibility for setting up the
> CurrentCompositeContext?
>
> When I last understood the relevant code, at M1, Tuscany was more
> or less
> requiring the host environment to set this up (then
> CurrentModuleContext).
> This was done with Tomcat via the TuscanyValve, for example, (which
> I'm not
> counting as part of Tuscany proper).
>
> I see in chianti that
> org.apache.tuscany.core.launcher.CompositeContextImplis setting up
> CurrentCompositeContext but I'm not sure what to make of
> this. Is Tuscany already setting up CurrentCompositeContext or
> might this
> be an area in which to propose an improvement?
>
> Thanks
> Scott Kurz
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org