>> First, eagerness is associated with the scope, not an initializer callback, IMO. Jim, would this mean there would be another annotation for initialization callbacks?
Also, what are the implications of start order on component dependencies and wirings? 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]
