Slava, Thanks for the tip. I assume all you have to do to register a tool is:
- implement ApplicationTool in your own tool - register the class(es) through tr.props Right? And I notice in tr.props you must implement global tools in a threadsafe manner -- I haven't done a lot of thread development, could you give me a brief outline of what's involved for a tool? Or a reference to a good place to learn about threadsafe implementations? Finally, can you outline a scenario where you'd want to use a Service instead of a global scope tool? Thanks very much, Derek ----- Original Message ----- From: "Slava Zimine" <[EMAIL PROTECTED]> To: "Turbine Users List" <[EMAIL PROTECTED]> Sent: Tuesday, July 16, 2002 12:32 AM Subject: Re: Newbie question: services vs tools vs ...? > Hi, Derek. > > I do this task with a tool having a global scope. > It will initialize only once when you launch tomcat. > > The public members/variables of this tool class are available in all > velocity macros on your site through > $yourtoolregisteredname.yourMethod() > > with 'yourtoolregisteredname' a name you register your tool class in > Turbine.properties > > regards > slava > > > On Mon, Jul 15, 2002 at 03:07:19PM -0700, Derek Stevenson wrote: > > Hi there, > > > > I'm using TDK 2.1 for development, and I want to load up some configuration > > data on startup of the application. Once loaded, the configuration data > > will not change and will be used across all user sessions as they log in. > > Configuration data is stored on the server in an XML doc. > > > > I've managed to put together a Turbine service and register it in tr.props, > > and was planning on putting the XML parsing code in the service to make it > > available to the rest of the site. However, I'm not sure this is the right > > way to go about it. Since this data is basically server configuration data > > that is loaded once, I thought perhaps it should be registered as a global > > tool. Any recommendations? If neither of these approaches makes the most > > sense for what I'm trying to do, could you recommend another option? > > > > Derek > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
