struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pilgrim, Peter" <>
Subject RE: application configuration
Date Mon, 19 Jul 2004 15:44:16 GMT
> -----Original Message-----
> From: Andrew Hill []
> 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
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?



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:
For additional commands, e-mail:

View raw message