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 11:22:21 GMT
On Jan 3, 2008 11:03 AM, Rajini Sivaram <rajinisivaram@googlemail.com>
wrote:

> On 1/3/08, Simon Laws <simonslaws@googlemail.com> wrote:
> >
> > On Jan 3, 2008 12:12 AM, Jean-Sebastien Delfino <jsdelfino@apache.org>
> > wrote:
> >
> > > 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).
>
>
> Shouldn't resolution be associated with a contribution rather than a
> composite contained within it? When a composite is assigned to a node,
> should the node find out which contribution it came from and process all
> composites and componentType files from the contribution?
>
> >
> > > --
> > > 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.xmlinformation.
> > 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.
>
>
> We rely on the order of addContribution only because the contribution is
> resolved when it is added. If the resolution can be delayed until all the
> contributions are added (ie. all sca-contribution.xml files are processed
> first as each addContribution is called, and the composite and
> componentType
> files from all contributions are processed later when the domain is
> started), then the order in which the contributions were added or the
> order
> in which they are resolved wont matter (except if there are multiple
> copies
> of the same class in different contributions). But with the current APIs

Are you referring to the contribution service or to the node/domain here?

>
> where contributions can be added or removed at any time, can you really
> assume that "start" is the right time to resolve contributions?

You can't change the node once it has been started (or if you can it's a
bug), I.e. you can't add/remove contributions or composites. You can't use a
node until it has been started.

My question was about the contribution service API which allows
contributions to be added one at a time. Even if we did nothing in the
Domain/Node until start() was requested, when we assume all required
contributions/composites are available, we still have to process
contributions one at a time.

I agree that we should determine the tree of contributions based on
sca-contribution.xml. However sca-contribution.xml is inside each
contribution so it may be sensible to separate the read and resolve phases
of the contribution service so that all contributions can be read first and
then resolved in the correct order. Otherwise we need some extra processing
to extract the sca-contribution.xml information.

So I think we are saying the same thing.


>
> Sebastien, are the changes you are thinking about going to allow
> unresolved
> > contributions to resolve dependencies after initial processing?
> >
> > Regards
> >
> > Simon
> >
>
> Thank you...
>
> Regards,
>
> Rajini
>

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