I was thinking about this a bit more and I think getResourceAsStream() would
be a good idea for TurbineResources as well. If for some reason you want to
call TurbineResources while the servlet engine is not running you need to
specifically say
TurbineResources.setPropertiesFileName("TurbineResources.properties"); in
your code because the file name hasn't been set in init(). With
getResourceAsStream() TurbineResources will know how to find its props file
by checking the classpath.
Referring back to having a second singleton FooResources. It was suggested
that foo.properties be placed in servlet init params or in TurbineResources.
This also means that the servlet engine would have to be running and
TurbineResources be set to use FooResources even though there may be cases
when you want to use FooResources apart from servlets.
What do people think?
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Kim
> Sent: Wednesday, January 19, 2000 6:25 PM
> To: Turbine
> Subject: RE: ExtendedProperties and TurbineResources
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of jon *
> > Sent: Wednesday, January 19, 2000 6:04 PM
> > To: Turbine
> > Subject: Re: ExtendedProperties and TurbineResources
> >
> >
> > on 1/19/00 2:06 PM, Frank Kim <[EMAIL PROTECTED]> wrote:
> >
> > > I've got a case where I want a FooResources singleton that is
> just like
> > > TurbineResources to store application specific stuff. The nice
> > thing with
> > > TurbineResources is that we can set the props file in init()
> > but there's not
> > > a nice place to store the FooResources props file without hard
> > coding the
> > > path to it (tell me if I'm wrong here).
> >
> > You *could* put it into the servlet engine initArgs like we
> > already do with
> > TurbineResources.properties loading.
> >
> I'd rather not put it in init() since it's not a Turbine specific thing.
>
> > > So what I'd like to do in FooResources is this:
> > >
> > > confs = new Configurations(
> > > new ExtendedProperties(
> > >
> > > RelayResources.class.getResourceAsStream( "/foo.properties" )
> > > )
> > > );
> >
> > I would make it RelayResources.getClass().getResourceAsStream().
> >
> getClass() is not a static method
>
> > You could also put a property into the
> > TurbineResources.properties file that
> > specifies the location of the "extra" properties file. This
> would probably
> > be my preferred method.
> >
> I prefer this over the previous alternative as well although I don't like
> adding non-Turbine stuff to TurbineResources.properties.
>
> > >
> > > But this requires adding this constructor to ExtendedProperties:
> > >
> > > /**
> > > * Creates and loads the extended properties from the specified
> > > InputStream.
> > > */
> > > public ExtendedProperties (InputStream input) throws IOException {
> > > this.load(input);
> > > }
> > >
> > > Would need to synch this with org.apache.java.util
> >
> > I would rather not touch the EP class right now because we just did a
> > release of Apache JServ and I don't want to require people to
> download the
> > CVS of it.
> >
> Since it's just an extra constructor it wouldn't have any effect on JServ
> and since we are already requiring turbine.jar be placed before
> ApacheJServ.jar in the classpath (as per the install doc or is this no
> longer the case) our EP would be found first.
>
> If you don't want to change EP then I'll just use the above approach.
>
>
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
