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 12:30:29 GMT
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
>

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