Ok great, I guess the only reason I wanted to do application ini'ng in a JSP file was so that I could easily view all the structures in the scopes (and tag markup like that is clear at a glance) and alter them without recompiling, But I agree that I am a bit held back by my past designs in coldfusion and that the application event listeners are the right place for that, so onwards :) XML/property files will work best for this too. I am quite new to JNDI so I need to study up there.
Thanks for the input. -John. : > Hey All, : > : > I am a bit confused in J2EE (and tomcat) concerning the best spot to : > do a bunch of initializations, and other startup code. : > : > Now, in Coldfusion you have the Application.cfm file which gets run on : > every request, thus you can load up the application scope (if its : > unitialized) or recycle it periodically with data/objects (which is : > great for cache queues). : > : > In jsp, I would like to have a jsp file run on initialization so that : > I can offer that file as a jsp based application initialization file : > (using custom tags to load up the application scope and even session : > and other goodies like internationalization bundles etc). : > : > It seems the best spot would be a ServletContext listener that would, : > on startup, fire a request to the Application.jsp file ... but this : > does not seem possible given the ServletContextListener interface (or : > is it)? : > : > In general, I haven't found much info on best practices for setting up : > the initial state of an application. If I wanted load up some JNDI : > entries on startup, where is the best place to do this (in a : > ServletContextListener perhaps?) ? And for some application : > attributes, same question. And to initialize the session for a user? : > : : The JNDI context is read-only from the perspective of the application. : The only way to populate it is in the configuration of your server (for : Tomcat, that means entries in server.xml). See below for a programmatic : alternative. : : > I really like the Coldfusion concept of the Application.cfm file since : > you can do all your state checks there, and then all your : > scripts/servlets can expect the web application state to be well : > managed. Its also a great spot for loading in internationalization : > resource bundles. : > : : That is exactly what application event listeners are for in the Servlet : API. : : > It would be even better to have a more fine grained Application.jsp : > file that would fire on initialization and vice versa, and for a few : > other significant application events. I don't particularly like : > putting a lot of params in the web.xml file since this can complicate : > migrations and makes it a bit un-programmatic. I also like having : > simple custom tags loading the application and session scope so that : > you can glance at one script for the app and see what is in those : > scopes by default, rather than having servlets doing their own thing : > and promoting decentralized scope processes. : > : : You're already found the right answer :-) : : Servlet context listeners are the correct place to do application-wide : initialization. The contextInitialized() method is called when the : application is first started (or when it is reloaded by the container), so : it is the perfect place to do things like set up resources that must be : present before the first request is processed. Likewise, the : contextDestroyed() method is called at shutdown time, so you can clean up : after yourself. : : In a similar manner, you can register listeners for session creation and : destruction, as well as changes to servlet context and session attributes. : : However, it's not necessary (or appropriate, IMHO) to embed the : initialization code in a JSP page -- save those for things that need a : user interface. The preferred design pattern is to have your context : listener set up objects (such as connection pools and resource bundles) : and make them available as ServletContext attributes. From the JSP page : perspective, these are just beans in application scope. The page doesn't : have to care how they got there -- thus achieving your goal of separation. : : Remember that the event listeners can easily communicate information to : your JSP pages by storing objects in ServletContext scope or Session : scope, as appropriate. It is *not* necessary to use JSP to *create* those : objects. : : > Any ideas? : > : > Thanks, : > John. : > : : Craig McClanahan : : : -- : To unsubscribe: <mailto:[EMAIL PROTECTED]> : For additional commands: <mailto:[EMAIL PROTECTED]> : Troubles with the list: <mailto:[EMAIL PROTECTED]> : : -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
