> Hi Giorgio
>
> So this is about adding components to a composite dynamically. Can we do
> what you need to do by either,
>
> Allowing contributions to be updated (so that you can add a new component to
> the composite through the normal contribution process)
> OR
> Adding a new contribution for each new component. The contribution could
> still contain generated XML if required and it could depend on the first
> contribution if this is where the component implementation is
>
> This way we don't have to provide new Tuscany specific interfaces for
> composite management.
>
Ok I agree, so i need a way to update contribution by contribution manager,
I process by the composite api the metacomponent, because i want keep
hierarchical structure that a composite could have.
I'm seeing that's a lot of code, but it's feasible.
> Once you have added the component what do you want to happen to it. For
> example, will it be wired to the manager that is controlling the workpool.
yes.
> If so how will this wiring be introduced? Here is some psuedo code for how
> the workpool manager might work without sca wiring (this does depend on the
> trunk code with the latest domain implementation).
I create a new wire on fly: adding dynamically a wire is not difficult.
> run() {
> under normal operation pass work out to worker components
>
> if (run out of components and max components not reached) {
> create a new composite giving the new worker a name
> add the composite to a new contribution
>
> domain = SCADomainFinder.newInstance().getSCADomain(domainName);
> domain.addContribution(the new contribution)
> domain.startComposite(the name of the new composite)
> reference to new component = domain.getService(WorkerService.class,
> "the name of the new component")
>
> use the new reference to allocate work to the component
> store the reference for future use
> }
> }
This solution is better and it's simple, but i want a hierarch
The manager is a component.
> If the manager were a component in its own right I think it could be done by
> making the reference to workers have a multiplicity greater than 1 and by
> adding a new wire when you add the new component. This would rely on doing
> some work to make contribution updates work. Don't know how hard that would
> be.
>
> Am thinking aloud here so let me know if this is useful.
>
> It would be good to understand a little more about the requirement as we
> have some similarly devious code in the current domain implementation and,
> now that callable reference support is better, I think we can replace it
> with code that only depends on the Tuscany API as opposed to the innards of
> the runtime. I haven't done this yet but maybe this is the motivation I need
> to sort it out:-)
So a method like:
void updateDeployedArtifact(Composite c, String ComponentDefintion) is
still in my contributionservice code.
I'm working on..
I'll help now you in order to provide a contribution update service,
because it's what i
need.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
