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 14:45:27 GMT
On Jan 3, 2008 1:18 PM, Luciano Resende <luckbr1975@gmail.com> wrote:

> 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://people.apache.org/%7Elresende>
> 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
>
> OK, Thanks Luciano. That's interesting. Did you have any thoughts when you
when through this about how the responsibility for managing contributions
would be shared between the contribution service and the domain. Maybe the
same question asked a different way, is the contribution service in a
position to tell the domain which contributions are fully resolved w.r.t to
their dependencies and which are not.

Looking back at the spec we are maybe missing the notion of a contribution
being installed (p67 of the assembly model) vs it just being contributedto
the domain. So we should revisit what we think the lifecycle of a
contribution is. Something like...

created (by some assembler)
contributed (to a domain)
installed (resolved w.r.t it's dependencies)
deployed (to a node where a composite requires the installed contribution
artifacts in order to run)

Does that make sense?

Regards

Simon

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