tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Date Thu, 03 Jan 2008 13:18:46 GMT
The Contribution API resembles what is said on the SCA spec, that
mentions that an contribution would be added to a domain, but don't
give any specific on how it is processed, so the ContributionService
API exposes variation of a contribute method today and the multiple
phases that process a given contribution (load, resolve, etc) is done
internally.

On Jan 3, 2008 4:30 AM, Simon Laws <simonslaws@googlemail.com> wrote:
> On Jan 3, 2008 12:13 PM, Rajini Sivaram <rajinisivaram@googlemail.com>
>
> wrote:
>
> > On 1/3/08, Simon Laws <simonslaws@googlemail.com> wrote:
> > >
> > > 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?
> >
> >
> > I was referring to the node/domain APIs since I was expecting something in
> > these APIs to trigger the resolution of contributions.
> >
> > >
> > > > 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.
> >
> >
> > This is the time I should just give up. I thought the domain also
> > processed
> > contributions, and you could add contributions to the domain at any time.
>
>
> No don;t give up ;-) I was referring to node here as that was the API that
> started this discussion. You are correct that domain currently allows
> contributions to be added in a more ad-hoc manner. Perhaps it shouldn't?
>
> >
> >
> > 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.
> >
> >
> > The contribution service does have separate read phase and resolve phase.
>
> Yes. But they don't appear to be part of the public API. Perhaps I am
> missing something.
>
>
> >
> > But at the moment, read and resolve are both triggered by addContribution.
> > If you can trigger them separately from the domain and node APIs...
> >
> > 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
> > > >
> > >
> >
> >
> >
> > --
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message