Hello J�rg! SJ> just as a side note: It is not guaranteed that a servlet SJ> container uses only one instance of a servlet. He might SJ> even create a new instance of it with each request
In fact reading servlet 2.2 spec, section 3.2: 3.2 Number of Instances By default there must be only one instance of a servlet class per servlet definition in a container. In the case of a servlet that implements the SingleThreadModel interface, the servlet container may instantiate mulitple instances of this servlet ... In the case where a servlet is part of an application that is marked in the deployment descriptor as distributable, there is one instance of a servlet class per servlet definition in VM in a container. If the servlet implements SingleThreadModel interface as well ... So this _must not_ happen :) SJ> (I had to deal with such a beast). Seems like it violated Servlet 2.2! What was it? SJ> Therefore I propose the ApplicationListner for the Avalon SJ> initialization. This would guarantee the Avalon services SJ> beeing available for any servlet in the webapp. There may be other reasons for preferring an application listener over a servlet. It may be just conceptually cleaner. On the other hand the application listeners were not addeded untill after Servlet 2.3, weren't they? Well, I like Servlet 2.3 okay and I feel it would be okay to do it in an Application Listener too. Maybe even somewhat cleaner. Another option would be a filter and then it would bind the serlvet manager at request scope. This will allow different servlets use different containers in one web app, potentially usefull too. -Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
