Hi Valerio,
Some comments and questions inline.
Valerio Schiavoni wrote:
Hello Jean-Sebastian,
On 4/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
- add/update/remove SCA contributions (packages containing composites
and component implementation artifacts) to/from the SCA domain
- add/update/remove deploymentComposites, declaring the top-level
components active in the SCA domain
These operations are described in the SCA assembly spec - chapter 1.10.4
- Operations on SCA contributions.
Doing this will update the configuration of components, including the
configuration of their properties, bindings, and references (by rewiring
them to other components).
Do you have any specific re-configuration use cases in mind that we
should support?
In particular, I was thinking about binding re-configuration at first.
Reading at the specs:
"this functionality makes it possible for the deployer to create a
composite with final configuration and wiring decisions and add it to
an installed contribution without having to modify the contents of the
root contribution."
As you said, updating a contribution will update also declared bindings.
You'll need to restart the components contributed by that contribution
to get the updated bindings.
How does it work when updating binding.java to a different one ?
The wires, binding selection etc. should be re-evaluated when the
impacted components get restarted. Did you mean binding.sca?
Can you point me somewhere within the core module ?
There is really no special processing for handling updates of a
contribution. Updating a contribution is very similar to contributing it
the first time.
Here are a few pointers to code along the contribution and start path:
- in the contribution module,
o.a.t.contribution.service.ContributionService is used to add or update
a contribution
- in the assembly-xml module, o.a.t.assembly.xml.CompositeProcessor
reads a Composite and populates the assembly model in memory, describing
composites, components, services, bindings etc.
- in the core module, o.a.t.core.deployer.DeployerImpl walks the
assembly model and triggers runtime Builders which create runtime
context objects for components, services with bindings etc.
- these runtime context objects (for example
o.a.t.implementation.java.context.JavaComponent) implement
o.a.t.spi.Lifecycle (defined in module core-spi), and their start()
method is called
Would you be interested in helping with some of this work?
I would be interested, but as I'm already working on the fractal
contribution:
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal/
Cool. Do you already have a patch to contribute? If you want to submit a
JIRA issue with a patch, we can contribute it to the sandbox first, and
everybody can take a look at it and help you, let you know when we make
changes that will affect your code etc. and even better at some point
integrate your extension in the trunk...
i guess it'd be difficult for me to productive. Also, I'm trying to
figure out what's changed in 1.0 for extensions..
We have made a number of changes to extensions recently, in particular
to how SCA assembly XML (.composite files etc.) are loaded, and also to
the model interfaces representing SCA assemblies. Feel free to ask any
questions, we'll try to help as much as possible. There are sample
extensions under samples/implementation-crud, samples/echo-binding and
samples/echo-databinding. We're also looking for feedback on the SPIs
and suggestions for improvement.
Would you mind giving us a short summary of how you are extending
Tuscany and integrating with Fractal? A little more context on what
you're doing will probably help us help you better :)
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
