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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
