You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/02/06 16:46:47 UTC
Queries related in the Trunk
Hi Jeremy, Jim, Meeraj,
I assume that runtime/standalone/assembly is going to be the way a SCA
Runtime will be started. Is this right?
Is there any test or sample in the trunk that can be used to understand how
to program a sca client for example things like how to get hold of a
ComponentContext and use methods over it. Could you please help with some
pointers?
Thanks
- Venkat
Re: Queries related in the Trunk
Posted by Rick Rineholt <cr...@gmail.com>.
Sorry Jeremy, I had thought I saw someone sent the log on the mailing
list, but it wasn't. . I just did.
Jeremy Boynes wrote:
> What IRC?
>
> --
> Jeremy
>
> On Feb 6, 2007, at 8:06 AM, Rick Rineholt wrote:
>
>> This isn't answering your question; but I'd like to see a version of
>> the iTest
>> framework running against the trunk as discussed in the last IRC.
>> This would
>> allow bring up whole user scenarios and provide a means to quickly
>> (automatically) validate they're still working as discussed in the
>> last IRC chat. Creating a sample is always a manual setup and
>> validation.
>>
>> Venkata Krishnan wrote:> Hi Jeremy, Jim,
>> Meeraj,
>> > <br>
>> > <br>I assume that runtime/standalone/assembly is going to be the way
>> a SCA
>> > <br>Runtime will be started. Is this right?
>> > <br>
>> > <br>Is there any test or sample in the trunk that can be used to
>> understand how
>> > <br>to program a sca client for example things like how to get hold
>> of a
>> > <br>ComponentContext and use methods over it. Could you
>> please help with some
>> > <br>pointers?
>> > <br>
>> > <br>Thanks
>> > <br>
>> > <br>- Venkat
>> > <br>
>> > <br></body>
>> > </html>
>> > </html>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Queries related in the Trunk
Posted by Jeremy Boynes <jb...@apache.org>.
What IRC?
--
Jeremy
On Feb 6, 2007, at 8:06 AM, Rick Rineholt wrote:
> This isn't answering your question; but I'd like to see a version
> of the iTest
> framework running against the trunk as discussed in the last IRC.
> This would
> allow bring up whole user scenarios and provide a means to quickly
> (automatically) validate they're still working as discussed in the
> last IRC chat. Creating a sample is always a manual setup and
> validation.
>
> Venkata Krishnan wrote:> Hi Jeremy, Jim,
> Meeraj,
> > <br>
> > <br>I assume that runtime/standalone/assembly is going to be the
> way
> a SCA
> > <br>Runtime will be started. Is this right?
> > <br>
> > <br>Is there any test or sample in the trunk that can be used to
> understand how
> > <br>to program a sca client for example things like how to get hold
> of a
> > <br>ComponentContext and use methods over it. Could you
> please help with some
> > <br>pointers?
> > <br>
> > <br>Thanks
> > <br>
> > <br>- Venkat
> > <br>
> > <br></body>
> > </html>
> > </html>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Queries related in the Trunk
Posted by Rick Rineholt <cr...@gmail.com>.
This isn't answering your question; but I'd like to see a version of the
iTest
framework running against the trunk as discussed in the last IRC. This
would
allow bring up whole user scenarios and provide a means to quickly
(automatically) validate they're still working as discussed in the last IRC
chat. Creating a sample is always a manual setup and validation.
Venkata Krishnan wrote:> Hi Jeremy, Jim,
Meeraj,
> <br>
> <br>I assume that runtime/standalone/assembly is going to be the way
a SCA
> <br>Runtime will be started. Is this right?
> <br>
> <br>Is there any test or sample in the trunk that can be used to
understand how
> <br>to program a sca client for example things like how to get hold
of a
> <br>ComponentContext and use methods over it. Could you
please help
with some
> <br>pointers?
> <br>
> <br>Thanks
> <br>
> <br>- Venkat
> <br>
> <br></body>
> </html>
> </html>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Programming models and Deployment, was: Queries related in the Trunk
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 10, 2007, at 9:06 AM, Luciano Resende wrote:
> Hi Jeremy
>
> I'm working on a implementation based on a slightly updated model
> that
> Raymond had proposed and already committed to trunk. I should have
> something
> in the next couple days available.
OK, thanks.
For the itest plugin, I would like to have a processor that can scan
the test classes and find all test harness classes. I think can do
this by providing an implementation of a SureFireTestSuite that can
look for tests in one of two ways:
1) it can load a SCDL file from the test tree, find the components
with <tuscany:junit> implementations and add them to the suite, or
2) scan the test tree identifying test classes, introspect their
references, create components for them with <tuscany:junit>
implementations, and autowire them to components in the composite-
under-test
The first one is simpler to implement but requires that the user
writes/maintains a SCDL file which is a bit of a hassle. I'm going to
start with this as I can see that in some circumstances they will
need to customize the assembly (so we'll need it anyway).
Both of these are a form of contribution introspection (the
contribution being the test tree) - is there an interface I should be
implementing to integrate with your stuff?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Programming models and Deployment, was: Queries related in the Trunk
Posted by Luciano Resende <lu...@gmail.com>.
Hi Jeremy
I'm working on a implementation based on a slightly updated model that
Raymond had proposed and already committed to trunk. I should have something
in the next couple days available.
--
Luciano Resende
http://people.apache.org/~lresende
On 2/10/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Feb 6, 2007, at 12:11 PM, Jeremy Boynes wrote:
>
> > One of the things that is changing in the spec is the way in which
> > user code outside SCA can access SCA resources. The
> > CompositeContext and CurrentCompositeContext classes have been
> > replaced with ComponentContext. You can see a prototype of this in
> > the spec/sca-api-r1.0 module.
> >
> > This has a direct impact on user code including all our samples and
> > SCATestCase. The old way using CurrentCompositeContext is no longer
> > available and so we need to define alternatives.
> >
> > There are many ways in which a Tuscany runtime can be started,
> > including:
> > * from application code, using an installed distribution
> > * from a Maven plugin like the itest one
> > * using a command line wrapper like the launcher and startServer
> > commands
> > * in a web-application using a ServletContextListener
> > and so forth.
> >
> > For the web-app case, I think the easiest solution for users is to
> > automatically make the ComponentContext, Property values, and
> > References available as ServletContext attributes. They would
> > supply the URI for a component whose implementation type is
> > <tuscany:webapp> as a context parameter and the listener would do
> > the rest. Application code (servlets and jsps) would typically get
> > properties and references from the servlet context.
> >
> > The same could be used for the launcher. Instead of passing in a
> > jar file on the command line, the would supply the URI for a
> > component whose implementation is <tuscany:launched> which would
> > reference a class that implemented Runnable. The launcher would
> > boot the runtime and invoke the component's run() method.
> >
> > The itest plugin would need a harness composite defined which would
> > either <include> the composite-under-test or use it to implement a
> > component. The harness composite would also contain a component
> > whose references would target services from the composite-under-
> > test. We can use a implementation of <tuscany:junit> to define the
> > test class and introspection to run the tests it contains (probably
> > through surefire); this can automatically inject property and
> > reference values into the TestCase instance.
> >
> > For API code we can add
> > ComponentContext getComponentContext(URI componentId)
> > }
> > to the TuscanyRuntime interface. Code that is using an installed
> > standalone distribution can use the helpers in
> > o.a.t.runtime.standalone to instantiate a StandaloneRuntime and
> > from that get the ComponentContext for a component.
>
> I've implemented the user-facing parts of this in the standalone and
> webapp runtimes but both require that the user's component is
> deployed into the system (i.e. it's part of the assembly and it's
> implementation artifacts are available).
>
> Raymond, Luciano, you both talked about getting the deployment
> infrastructure working - is this in the works and near a point where
> I would be able to pick it up?
>
> In the meantime, I'm going to get started on the maven plugin.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Programming models and Deployment, was: Queries related in the Trunk
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 6, 2007, at 12:11 PM, Jeremy Boynes wrote:
> One of the things that is changing in the spec is the way in which
> user code outside SCA can access SCA resources. The
> CompositeContext and CurrentCompositeContext classes have been
> replaced with ComponentContext. You can see a prototype of this in
> the spec/sca-api-r1.0 module.
>
> This has a direct impact on user code including all our samples and
> SCATestCase. The old way using CurrentCompositeContext is no longer
> available and so we need to define alternatives.
>
> There are many ways in which a Tuscany runtime can be started,
> including:
> * from application code, using an installed distribution
> * from a Maven plugin like the itest one
> * using a command line wrapper like the launcher and startServer
> commands
> * in a web-application using a ServletContextListener
> and so forth.
>
> For the web-app case, I think the easiest solution for users is to
> automatically make the ComponentContext, Property values, and
> References available as ServletContext attributes. They would
> supply the URI for a component whose implementation type is
> <tuscany:webapp> as a context parameter and the listener would do
> the rest. Application code (servlets and jsps) would typically get
> properties and references from the servlet context.
>
> The same could be used for the launcher. Instead of passing in a
> jar file on the command line, the would supply the URI for a
> component whose implementation is <tuscany:launched> which would
> reference a class that implemented Runnable. The launcher would
> boot the runtime and invoke the component's run() method.
>
> The itest plugin would need a harness composite defined which would
> either <include> the composite-under-test or use it to implement a
> component. The harness composite would also contain a component
> whose references would target services from the composite-under-
> test. We can use a implementation of <tuscany:junit> to define the
> test class and introspection to run the tests it contains (probably
> through surefire); this can automatically inject property and
> reference values into the TestCase instance.
>
> For API code we can add
> ComponentContext getComponentContext(URI componentId)
> }
> to the TuscanyRuntime interface. Code that is using an installed
> standalone distribution can use the helpers in
> o.a.t.runtime.standalone to instantiate a StandaloneRuntime and
> from that get the ComponentContext for a component.
I've implemented the user-facing parts of this in the standalone and
webapp runtimes but both require that the user's component is
deployed into the system (i.e. it's part of the assembly and it's
implementation artifacts are available).
Raymond, Luciano, you both talked about getting the deployment
infrastructure working - is this in the works and near a point where
I would be able to pick it up?
In the meantime, I'm going to get started on the maven plugin.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Queries related in the Trunk
Posted by Jeremy Boynes <jb...@apache.org>.
One of the things that is changing in the spec is the way in which
user code outside SCA can access SCA resources. The CompositeContext
and CurrentCompositeContext classes have been replaced with
ComponentContext. You can see a prototype of this in the spec/sca-api-
r1.0 module.
This has a direct impact on user code including all our samples and
SCATestCase. The old way using CurrentCompositeContext is no longer
available and so we need to define alternatives.
There are many ways in which a Tuscany runtime can be started,
including:
* from application code, using an installed distribution
* from a Maven plugin like the itest one
* using a command line wrapper like the launcher and startServer
commands
* in a web-application using a ServletContextListener
and so forth.
For the web-app case, I think the easiest solution for users is to
automatically make the ComponentContext, Property values, and
References available as ServletContext attributes. They would supply
the URI for a component whose implementation type is <tuscany:webapp>
as a context parameter and the listener would do the rest.
Application code (servlets and jsps) would typically get properties
and references from the servlet context.
The same could be used for the launcher. Instead of passing in a jar
file on the command line, the would supply the URI for a component
whose implementation is <tuscany:launched> which would reference a
class that implemented Runnable. The launcher would boot the runtime
and invoke the component's run() method.
The itest plugin would need a harness composite defined which would
either <include> the composite-under-test or use it to implement a
component. The harness composite would also contain a component whose
references would target services from the composite-under-test. We
can use a implementation of <tuscany:junit> to define the test class
and introspection to run the tests it contains (probably through
surefire); this can automatically inject property and reference
values into the TestCase instance.
For API code we can add
ComponentContext getComponentContext(URI componentId)
}
to the TuscanyRuntime interface. Code that is using an installed
standalone distribution can use the helpers in
o.a.t.runtime.standalone to instantiate a StandaloneRuntime and from
that get the ComponentContext for a component.
--
Jeremy
On Feb 6, 2007, at 7:46 AM, Venkata Krishnan wrote:
> Hi Jeremy, Jim, Meeraj,
>
> I assume that runtime/standalone/assembly is going to be the way a SCA
> Runtime will be started. Is this right?
>
> Is there any test or sample in the trunk that can be used to
> understand how
> to program a sca client for example things like how to get hold of a
> ComponentContext and use methods over it. Could you please help
> with some
> pointers?
>
> Thanks
>
> - Venkat
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org