Leif Mortenson wrote: > Berlin, (Berin)
> I was wondering if you have any ideas on this. My application defines a > component which encapsulates an HSQLDB server. Then another > ResourceLimitingJdbcDataSource components is configured to connect to > the interval HSQL component: <snip type="config"/> > > The problem is that I would like to declare the rl-jdbc component as being > dependent on the hsqldb component so that shutdown and startup will always > take place in the correct order. > > I am thinking of creating a subclass of ResourceLimitingJdbcDataSource > which will have such a dependency. Does that sound like the best way to do > this? Most likely it is the only real option as there is no place else > to declare > the dependency. > Would it make sense to define a way to declare dependencies in a > component's configuration block? This may not be a common enough > problem to warrant the added clutter. > Thoughts? In the absence of dependency information, Fortress follows the order of component declaration in the configuration. The DAG stuff should only override that order if there is explicit dependencies. What we have here is not a "real" dependency in that the <rl-jdbc/> component directly uses HSQL. We have a logical dependency issue where the server needs to be running before we can connect to it. Subclassing so that you can add the additional dependency information isn't really the best option--although it will work (as long as you actually look it up). Fortress has a startup order hint that you can use in your config files. The hint is in the "activation" attribute. For example: <hsqldb activation="inline"/> <rl-jdbc activation="background"/> <foo activation="request"/> <hsqldb/> would be started as we are initializing (which prolongs the perceived startup time. <rl-jdbc/> would be started in the background when the system got around to it--this is the default behavior. <foo/> would not be started until you actually looked it up. The activation values are below: startup/background -- asynchronously starting components inline -- synchronously starting components at init time lazy/request -- synchronously starting components during lookup This should be enough to ensure a certain startup order, although it does not affect the shutdown order. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
