Hi Anton, Anton Tagunov wrote: > Hello J�rg! > >> just as a side note: It is not guaranteed that a servlet >> container uses only one instance of a servlet. He might >> 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 :)
Well, I just scanned the second paragraph <g> > >> (I had to deal with such a beast). > Seems like it violated Servlet 2.2! Well, not really. They deal with one instance too, but the instance is created and destroyed for each request. This behavior is not covered by the spec AFAIK. > What was it? It is a closed-source CMS from Day. It is itself a valid webapp. To offer JSP and servlet templating they include a nested servlet and JSP container that behaves sometimes somewhat different ... ;) >> Therefore I propose the ApplicationListner for the Avalon >> initialization. This would guarantee the Avalon services >> 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? Yes, they're new (and not suported in this CMS' container). But we found a way to fake it. > 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. It depends. At least your containers are initialized at start-up and you avoid the delay of the first call to a servlet (or filter) for the initialization. > 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. Yes, basically this sounds interesting (although not supported again by my CMS). Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
