>> Are you thinking of something that may cause complications with this approach? No, dependencies was the first the first thing that popped into my mind when Jeremy mentioned sort order. As you suggested, dependencies will have to override sort order.
-----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 14 July 2006 21:18 To: tuscany-dev@ws.apache.org Subject: Re: Component start order On Jul 14, 2006, at 1:13 PM, Meeraj Kunnumpurath wrote: >>> First, eagerness is associated with the scope, not an initializer > callback, IMO. > Jim, would this mean there would be another annotation for > initialization callbacks? > I think it would just be @Init, but with no attributes > Also, what are the implications of start order on component > dependencies and wirings? That's a good question. I think dependencies override start order such that when we initialize a component, we perform a depth-first traversal of dependencies, instantiating them regardless of start level. Are you thinking of something that may cause complications with this approach? Jim > > Many thanks > Meeraj > -----Original Message----- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: 14 July 2006 21:05 > To: tuscany-dev@ws.apache.org > Subject: Re: Component start order > > > On Jul 14, 2006, at 12:43 PM, Jeremy Boynes wrote: > >> The Java implementation model allows components to designate that >> they > >> are "eager" init which means that they will be initialized when the >> composite they are in is started rather than on first use. >> >> One problem that I ran into with the extension stuff is that the >> specification does not say or even allow a user to say in which order >> the components will be started. >> >> One option would be to follow a lexical convention and say that >> components will be started in the order that they appear in the SCDL. >> I have a few reservations about this: >> * users may have other criteria for laying out the file (for example >> grouping components together) >> * this can be confusing in the presence of include elements - users >> may want to group >> components together in an include that would fit in different >> places > >> in the start order >> > This can also be dangerous if a tool doesn't preserve the exact order > or someone inadvertently changes something. > >> Instead I'd like to propose we support an init-level indicator like >> the run level from Unix systems. Components would be started in >> ascending order of the init level they provided. >> >> This could be done as an attribute on the <component> element, >> something like: >> >> <component name="start2nd" initLevel="20"> ... >> <component name="start1st" initLevel="10"> ... >> > >> This would also allow us to eagerly initialize components without >> having to use an @Init annotation. >> > I'm wondering if specifying the start level in SCDL is crossing > semantics with eager init... > > As background, one thing I was planning on proposing to the spec was > moving eager init off of @Init and onto @Scope for couple of reasons. > First, eagerness is associated with the scope, not an initializer > callback, IMO. The second reason is that it avoids a problem I've been > noticing lately where I want to eager init something but I don't need > an initializer callback, and I am forced to add an empty method just > to get the component to be instantiated eagerly. Couple that with > constructor-based injection, and I think it is better to but things on > @Scope. > > What if we said eager init is a component type concept and is true or > false (specified on @Scope)? Then, run level is the SCDL configuration > of eager init. So, a component would be eager initialized based on the > component type info and would be done so in the order specified by the > SCDL runlevel attribute. If no runlevel attribute were present, we > would default it to some level (maybe 100). > > Also, I think we should have a default runlevel attribute on > composites as well that applies to all children. This may be implicit > in the above since composites are just components. > > Jim > > >> Seem reasonable? >> -- >> Jeremy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message has been checked for all email viruses by MessageLabs. > > > > > ***************************************************** > > You can find us at www.voca.com > > ***************************************************** > This communication is confidential and intended for > the exclusive use of the addressee only. You should > not disclose its contents to any other person. > If you are not the intended recipient please notify > the sender named above immediately. > > Registered in England, No 1023742, > Registered Office: Voca Limited > Drake House, Three Rivers Court, > Homestead Road, Rickmansworth, > Hertfordshire, WD3 1FX > > > This message has been checked for all email viruses by MessageLabs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
