> -----Original Message----- > From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 12:26 > To: Struts Users Mailing List > Subject: RE: application configuration > > > I tend to put such things in XML files rather than properties files > nowadays. > > When the app starts up I have a plugin read the files and create > configuration objects (using Digester), and put these objects into the > servlet context (application scope) where my code can get at > them easily. > >
Agreed +1 Basically this is the same I am persuaded to. I written some Digester stuff in the past for simple and complex XML configuration I have a simple property file for a service layer. org.foobar.somelayer.MyPOJI = org.foobar.somelayer.impl.MyPOJOImpl "MyPOJI" is a service Java interface. "MyPOJOImpl" is a concreate java class that implements the service "MyPOJI" I can easily turn this into a XML file or allow a light weight framework to load. Such a simple service layer could load up the service implementations and stick in the application scope where Struts action (or Expresso Controllers) can get them. I have come around to the thinking that Business Delegate and Service Locator can be overfluous ( I have been reading Rod Johnson's new book also). The problem is that I want my services to be lazy loaded. If there a complex service that pulls in XYZ number of Java class, very resource intensive, or is generally particular heavy, then I dont want all of my service to "spring" into life. Is there any IoC frameworks out there that do lazy loading? Or has anyone on the knowledgeable Struts user done something like this? Tia ==////== -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
