In OSGi-land, the dependency issue was tackled by the Declarative Services specification. You can find the spec in the OSGi R4 companion document: http://www.osgi.org/osgi_technology/download_specs.asp?section=2. Perhaps there's an opportunity to commonize on an approach.
Relevent passages: 112.5 Component Life Cycle 112.5.1 Enabled A component must first be enabled before it can be used. A component cannot be enabled unless the component's bundle is started. All components in a bundle become disabled when the bundle is stopped. So the life cycle of a component is contained within the life cycle of its bundle. Every component can be enabled or disabled. The initial enabled state of a component is specified in the component description via the enabled attribute of the component element. See Component Element on page 290. Component configurations can be created, satisfied and activated only when the component is enabled. The enabled state of a component can be controlled with the Component Context enableComponent(String) and disableComponent(String) methods. The purpose of later enabling a component is to be able to decide programmatically when a component can become enabled. For example, an immediate component can perform some initialization work before other components in the bundle are enabled. The component descriptions of all other components in the bundle can be disabled by having enabled set to false in their component descriptions. After any necessary initialization work is complete, the immediate component can call enableComponent to enable the remaining components. The enableComponent and disableComponent methods must return after changing the enabled state of the named component. Any actions that result from this, such as activating or deactivating a component configuration, must occur asynchronously to the method call. Therefore a component can disable itself. All components in a bundle can be enabled by passing a null as the argument to enableComponent. 112.5.2 Satisfied Component configurations can only be activated when the component configuration is satisfied. A component configuration becomes satisfied when the following conditions are all satisfied: * The component is enabled. * Using the component properties of the component configuration, all the component's references are satisfied. A reference is satisfied when the reference specifies optional cardinality or there is at least one target service for the reference. Once any of the listed conditions are no longer true, the component configuration becomes unsatisfied. An activated component configuration that becomes unsatisfied, must be deactivated. Immediate Component A component is an immediate component when it must be activated as soon as its dependencies are satisfied. Once the component configuration becomes unsatisfied, the component configuration must be deactivated. If an immediate component configuration is satisfied and specifies a service, SCR must register the component configuration as a service in the service registry and then activate the component configuration. The state diagram is shown in Figure 45. Figure 45 Immediate Component Configuration 112.5.4 Delayed Component A key attribute of a delayed component is the delaying of class loading and object creation. Therefore, the activation of a delayed component configuration does not occur until there is an actual request for a service object. A component is a delayed component when it specifies a service but it is not a factory component and does not have the immediate attribute of the component element set to true. SCR must register a service after the component configuration becomes satisfied. The registration of this service must look to observers of the service registry as if the component's bundle actually registered this service. This strategy makes it possible to register services without creating a class loader for the bundle and loading classes, thereby allowing reduction in initialization time and a delay in memory footprint. When SCR registers the service on behalf of a component configuration, it must avoid causing a class load to occur from the component's bundle. SCR can ensure this by registering a ServiceFactory object with the Framework for that service. By registering a ServiceFactory object, the actual service object is not needed until the ServiceFactory is called to provide the service object. The service properties for this registration consist of the component properties as defined in Component Properties on page 301. The activation of a component configuration must be delayed until its service is requested. When the service is requested, if the service has the servicefactory attribute set to true, SCR must create and activate a unique component configuration for each bundle requesting the service. Other- wise, SCR must activate a single component configuration which is used by all bundles requesting the service. A component instance can determine the bundle it was activated for by calling the getUsingBundle() method on the Component Context. The activation of delayed components is depicted in a state diagram in Figure 46. Notice that multiple component configurations can be created from the REGISTERED state if a delayed component specifies servicefactory set to true. If the service registered by a component configuration becomes unused because there are no more bundles using it, then SCR should deactivate that component configuration. This allows SCR implementations to eagerly reclaim activated component configurations. This would greatly simplify integrating Tuscany into Equinox. :-) Cheers, Joel Hawkins -----Original Message----- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Friday, July 14, 2006 4:20 PM To: [email protected] Subject: Re: Component start order Hi, I don't think this is an "init" specific issue. To me, it's more about how to define dependencies for components. If one component A is required to be initialized before component B, it hints that Component B has a dependency on Component A. I remember that Jeremy was proposing to use maven style to lable composites with group/artifact ids so that a composite version can be identified and loaded. I guess the maven dependency declarations can also be applied here. Thanks, Raymond ----- Original Message ----- From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, July 14, 2006 12:43 PM Subject: Component start order > 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 > > 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. > > 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] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
