On Jan 3, 2008 12:13 PM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > On 1/3/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On Jan 3, 2008 11:03 AM, Rajini Sivaram <[EMAIL PROTECTED]> > > wrote: > > > > > On 1/3/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > On Jan 3, 2008 12:12 AM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> > > > > 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: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > 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 >
