|
FWIW: I believe you don't actually need to use a static initializer for a servlet. The init() method has the single threaded, first touch concept as part of its contract. I think code in a servlet's init() method and code in a static initializer, while being different in when they are executed, are functionally equivalent for application programs. A common technique that builds on this is to then define one servlet for a web application that gets loaded when the server starts up (allowing the rest to get loaded on an as needed basis. For example, I'm working on a project where we have "SetupServlet" which looks like this: public class SetupServlet extends HttpServlet { public void init(ServletConfig config) throws ServletException { super.init(config); // Do application level setup here. } public void destroy() { // Do application level cleanup here. } } Then you define the file in your web.xml file to load on startup: <servlet> <servlet-name>setup</servlet-name> <servlet-class>SetupServlet</servlet-class> <load-on-startup>0</load-on-startup> </servlet> That's it. You don't every have to call or reference that servlet at all and it can serve as a mechanism for you to make sure that you have things setup correctly that the rest of your application relies on. One possible advantage of this approach is that, when there are problems in initialization, it will be easier to handle them gracefully. For example, you can throw a ServletException from init(), but exceptions thrown from static initializers are pretty spotty in what will happen to the application and container. ============================================ One place where static initializers are very popular (and actually now required by the specification) is in JDBC drivers. When a JDBC driver loads, it is supposed to register itself with the DriverManager. So when a user application types: Class.forName("com.ibm.db2.jdbc.app.DB2Driver"); It cause the native JDBC driver to load. There is a static initializer in the DB2Driver class that does this: java.sql.DriverManager.registerDriver(new DB2Driver()); Richard D. Dettinger iSeries Java Data Access Team Democracy's enemies have always underestimated the courage of the American people. It was true at Concord Bridge. It was true at Pearl Harbor. And it was true today. Rochester Post-Bulletin Tuesday September 11, 2001 |---------+----------------------------> | | Larry | | | Loen/Rochester/IB| | | M@IBMUS | | | Sent by: | | | java400-l-admin@m| | | idrange.com | | | | | | | | | 03/06/2002 02:05 | | | PM | | | Please respond to| | | java400-l | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------------------| | | | To: java400-l@midrange.com | | cc: | | Subject: Re: Have you seen anything like this? | | | | | >-----------------------------------------------------------------------------------------------------------------------------| As has been said, these are usually called "static initializers" >In my java class yesterday, my instructor went over a new constructor >type thing. He called it a class constructor. Here is an example: >public class Test { > static { > // set of instructions here > } > > Test() { > // set of instructions here >} > } In servlets, I have found these static (class) initializers extremely useful. You have guaranteed, single-threaded execution at class load time. This is a great opportunity to do one-time things like get connections, prepare SQL statements, initialize Vectors and Hashtables and so on. Especially good for "immutable" type objects that don't have to by otherwise synchronized because you can't or won't change them after you build them in the static initializer. Larry W. Loen - Senior Linux, Java, and iSeries Performance Analyst Dept HP4, Rochester MN _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
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.