I think lazy initialization is a simple choice, because it is not dependent on the J2EE container, this make your code easy to test.
If you worry about duplicated-initialization triggered by multi request, the simple solution is, make your initialization code [synchronized], using reserved word [synchronized] of Java language. However, if your initialization process is too heavy, the lazy initialization mode will make the first access slow. If you care about this problem, the [ServletContextListener] and [initialization servlet] is a better choice. As Eric and Chris said, they can be good entry point to call your initialization process. I suggest： (1)implement your initialization process as a util-class or something, so you can do unit test, out of the J2EE context. (2)call the initialization process from [ServletContextListener], or [initialization servlet], or some lazy initialize code as you want. The basic principle is: (1)implement the real business logic in an independent mode (2)create some adapter code, to connect your business logic and your run time context 2011/11/11 Scott Smith <[email protected]>: > In struts 1, I used org.apache.struts.action.PlugIn as a way to create an > object at web app startup and put it into the application context so that all > sessions had access to it. What's the equivalent method in Struts2? That > is, how can I have an object created at web application startup. > > I guess the alternative is lazy initialization (first guy who tries to access > it and doesn't find it, creates it, and saves it into the app context; down > side is I might end up with several sessions trying to create it until one > finally makes it to the app context). > > Any better solutions? > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
