tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Date Thu, 03 Jan 2008 10:24:35 GMT
On Jan 3, 2008 12:12 AM, Jean-Sebastien Delfino <jsdelfino@apache.org>

> Rajini Sivaram wrote:
> > Sebastien,
> >
> > When I was implementing OSGi bundle contributions, I was very frustrated
> > about the fact that even though bundles can have cyclic dependencies,
> > bundles with cyclic dependencies could not be added to SCA, if the
> bundles
> > contained SCA artifacts (composites/componentType files). OSGi copes
> with
> > cyclic dependencies because bundles have separate install and start
> methods.
> > So classes need to get resolved only before the start method is called.
> The
> > bundle is moved to resolved state by the OSGi runtime when its
> dependencies
> > are satisfied, and only resolved bundles can be started. With SCA
> > contributions, when would the composites/componentType files in a
> > contribution get processed, if it is not done when the contribution is
> > added? Class resolution for contributions is lazy, and hence the
> ordering of
> > contributions is only relevant when there are multiple contributions
> > containing the same class. But classes used in SCA composites and
> > componentType files get resolved when those files are processed, and at
> the
> > moment addContribution is the trigger, requiring all dependent
> contributions
> > containing classes referred to in composites/componentType files to be
> > installed first. If addContribution is not the trigger to process
> > composites, I am not sure what the trigger would be. node.start() for
> the
> > node? What about the domain? Wouldn't it have been much simpler if
> Tuscany
> > had a better lifecycle layer (like OSGi :-))?
> >
> >
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> Short answer to a long question :) when a composite is assigned to a
> node: node.setComposite(composite).
> --
> Jean-Sebastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> Rajini is correct that at the moment when a contribution is added to the
domain (or directly to the node) then it is passed through the contribution
processor resulting in an in
memory model of the provided contribution. The model isn't "built" and
"activated" until the node is started.

AFAIUI there is no lifecycle model in the contribution processor. Either all
the required dependencies are available or they aren't. So, in the case
where dependent contributions are being added separately, they must be
processed in the correct order according to the
sca-contribution.xml is itself provided inside the contribution.

The domain/node currently assume a user adds contributions incrementally
(there is no bulk load capability). We could consider delaying the
processing until the user trys to start the domain, i.e. you assume that is
the point they have all of the contributions added that they need. However I
don't think that helps as how do we know which contribution to process
first. From this thread we are relying on the order of addition.

Sebastien, are the changes you are thinking about going to allow unresolved
contributions to resolve dependencies after initial processing?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message