This is not the only case that you will find on services having a dependency on each other. This is why the order in which the services are listed in TR.props is important. I think that in order to support the existing coupled services, you will need to allow for a configurable initialization order.
-------------------------------------------- Quinton McCombs NequalsOne - HealthCare marketing tools mailto:[EMAIL PROTECTED] http://www.NequalsOne.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 11:40 AM > To: [EMAIL PROTECTED] > Subject: Fragileness in PullService and VelocityService > > > Hi all, > > I discovered something while trying to do final testing on > the Configuration > stuff. I couldn't get Turbine to use pull tools when I loaded via the > ConfigurationFactory, but via the old method, everything > worked. However, I > did come up with what the issue is using the old method: > > > Fails: > services.VelocityService.classname=org.apache.turbine.services > .velocity.Turb > ineVelocityService > services.PullService.classname=org.apache.turbine.services.pul > l.TurbinePullS > ervice > > Suceeds: > services.PullService.classname=org.apache.turbine.services.pul > l.TurbinePullS > ervice > services.VelocityService.classname=org.apache.turbine.services > .velocity.Turb > ineVelocityService > > The TurbineVelocityService REQUIRES the TurbinePullService to > load up first. > However, my darn config factory doesn't have any order to the > parameters as > they are returned.. > > Not sure what to do.. Change Configuration so that if you > have paramerters: > Services.a > Services.b > Services.c > > then they are always returned in that order? Ugh... Or, > change something > in Turbine to force PullService to load before VelocityService? > > Eric Pugh > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
