Thanks Filip,

I figured something was going on to stop it loading on subsequent
attempts - 
most of my testing was on non-servlet classes - but I want to have one
point
of entry for getting properties (my util is a singleton).  The servlets
trip
it up.

I just want to be able to pick up the .properties file from the same dir
as the
calling/client class - the reason I used the method below was because it
looks
in the class dir of the class instance passed in.

Is there a "best" way to identify the file path from the class passed
in?
I guess I could create it from the class.getName() and replace the "."
with
"\" but that seems ugly.

Anyone got any suggestions?

Is there a good package for doing this properties loading already?

Many thanks as ever,
Chris



> -----Original Message-----
> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] 
> 
> if you want to be able to reload it, I suggest that you load 
> it using a 
> FileInputstream, and not getResourceAsStream from the class 
> loader. if you load it through the class loader, the class 
> loader doesn't reload 
> it until restart.
> 
> Filip
> 
> Chris Ward wrote:
> > Hi all,
> >
> > I've build a little util class for sucking in properties.  
> When I use 
> > it from "command line" progs it seems to work okay, but 
> when I call it 
> > from a servlet it never seems to load an *updated*  version of the 
> > .properties file.
> >
> > I am using a HashMap to cache the Properties and associated 
> timestamp 
> > (of type long).  It detects a stale timestamp okay - then 
> goes through 
> > the Properties.load( ... ) but the returned Properties seem 
> to always 
> > be the ones it first loaded.
> >
> > If I restaart Tomcat the newest version of the Properties file *is* 
> > loaded.
> >
> >
> > Here's some of the util  code...
> >
> > <snip>
> >
> >
> >     static private Properties loadPropertiesFile(Class callerClass,
> >                                                  String 
> configName) {
> >         
> >         Properties appProperties = null;
> >
> >             ...
> >             if detect "stale" timestamp on disk property file 
> >             vs. the cache one, set "entry = null" - this works...
> >             ...
> >
> >
> >                 if (entry == null) {
> >                     // create and load properties 
> >                     appProperties = new Properties();
> >                     
> appProperties.load(callerClass.getResourceAsStream(
> >                         configName + ".properties"));
> >             
> >                     // stuff it in the cache
> >                     entry = new MapEntry(lastModified, 
> appProperties);
> >                     propertiesCache.put(appName, entry);
> >                     
> >                     appProperties.list(System.out);
> >                     
> >                 }
> >
> >             ...
> >             ...
> >
> >
> > <snip>
> >
> > And here's how I test it from a servlet...
> >
> >
> > <snip>
> >
> >
> >     public void doGet(HttpServletRequest req, 
> HttpServletResponse res) 
> > throws
> >         ServletException, IOException {
> >         PrintWriter out = res.getWriter();
> >
> >         try {
> >             Properties prop = null;
> >
> >             
> >             prop = 
> > HAL_PropertiesUtils.getPropertiesHandler(this.getClass(),
> > "PropertiesUtilsServlet");
> >             out.println(prop.getProperty("name"));
> >         }
> >         catch (Exception ex) {
> >         }
> >     }
> >
> > <snip>
> >
> >
> >
> > Any wisdom on this?  Do I have to do something different/extra when 
> > loading properties in this way under Tomcat?
> >
> > I just do all this so the .properties files can be found in 
> the same 
> > dir as whatever class calls the util.
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to