× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Source Evaluation?
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Fri, 9 Feb 2001 14:23:12 -0600

Very cool!  

The only thing that still boggles my mind is what sets the default path
where the program will look for these files?  Is it one path, or is it the
entire classpath?

Brad

> -----Original Message-----
> From: Joe Teff [mailto:JoeTeff@earthlink.net]
> Sent: Friday, February 09, 2001 2:04 PM
> To: JAVA400-L@midrange.com
> Subject: RE: Source Evaluation?
> 
> 
> You can use instance variable as long as you don't update
> them. That's the thread exposure. The init() is the proper
> place to initialize them as it is called prior to servicing
> any requests.
> 
> One comment I was going to make about Brad's code is to
> place your jdbc values in a file and then load them into
> a Properties object. Very easy to do. I do that because
> I'll test on my home PC using Access and switch to the
> AS/400 for production. I have a database.properties file
> on both machines, so I don't have to change my code to
> switch.
> 
> The file is plain ascii text that has key=value pairs.
> So I would have entries in my file like:
> 
>    driver=com.ibm.as400.access.AS400JDBCDriver
>    url=jdbc:as400://web400
>    user=jdbc
>    password=jdbc
> 
> The Properties class extends Hashtable. To create my
> Properties object from my file I use:
> 
>    Properties prop = new Properties();
>    prop.load(new FileInputStream("database.properties"));
> 
> I then use the getProperty() method that takes the key
> as a String and returns the value as a String.
> 
>    Class.forName(prop.getProprty("driver"));
>    con  = DriverManager.getConnection(prop.getProperty("url"),
>           prop.getProperty("user"), prop.getProperty("password"));
> 
> Joe
> 
> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of Larry Loen
> Sent: Friday, February 09, 2001 12:03 PM
> To: JAVA400-L@midrange.com
> Subject: RE: Source Evaluation?
> 
> 
> 
> Paul Clapham wrote:
> 
> >But in my (limited) experience, I've found that
> >most of my servlets don't require an init() method.
> 
> Well, strictly speaking, you are correct.  However,
> this is an interesting topic.  Either a static class 
> initializer or the
> init
> method is a good place to stick read-only kinds of objects, especially
> those that are fairly expensive to construct.
> 
> As I understand the servlet rules, you can't really use 
> regular "instance"
> variables on grounds that architecturally, multiple threads can
> simultaneously
> use the same servlet object.  This means modification raises 
> thread safety
> issues.  However, you can put instance variables in them that are
> what Java calls "immutable" -- don't change after they are 
> constructed.
> These are thread safe by design and definition.
> 
> Still, an init method can in the end include a lot of stuff, the kind
> of stuff that starts out in .ini files and are configuration 
> specific, such
> as
> the www.whateversystemthisis.com prefix  and like things.
> 
> I must admit, I tend to use the static class initializer 
> because most of
> this
> stuff only needs to be done once and can fit in class-wide 
> variables.  But
> if I thought about it longer, I could probably find examples that made
> sense for
> init as well.
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> 
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.