Interaction between servlet filters and ServletContextListeners

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Interaction between servlet filters and ServletContextListeners

Eric Rizzo
I've got a servlet filter and a context listener that both interact
with a shared component. I've noticed that Jetty's
WebApplicationContext notifies the context listener(s) before it
actually initializes the servlet filters. What I'm wondering is if
that is the "correct" sequence.

I am about to go try to read the servlet spec to see if it is specific
in the ordering of servlet/filter init-ing and context listener
notification, but the current Jetty implementation causes me a bit of
a headache because I rely on the filter init to properly configure the
shared component. The filter has access to init params that I use to
configure things, but the context listener has no such capabilities
and thus replies on the shared component to have already been
configured.

I can probably use <env-entry> and JNDI to initialize the shared
component if I must, but I don't want to introduce JNDI unless I
really need it. I thought using the filter init params would be a
reasonable alternative.

Does anyone know if Jetty is either correct, wrong, or just making an
implementation choice that is afforded it by the spec?
Anyone have any other ideas for configuring a shared component without
relying on a servlet or filter to do it?

Thanks,
Eric


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Interaction between servlet filters and ServletContextListeners

Chris Haynes
Have a static flag in the shared component Class which is set when
initialization has been done. Check this each time the component is used. There
is usually something which is 'null' before initialization - test this. Just
watch out for thread-safety - make sure that two (or more) threads can't both
think they are doing the initialization.

Alternative, if this fits your logic: initialize the components by including a
static{} block in the Class. This block will be executed as the class is loaded,
and it is guaranteed to be thread-safe.

If using this latter method, watch out for a snag: There was a change between
Sun's Java 1.4 and 1.5. In 1.4 simply mentioning the class somewhere else was
enough to have it loaded that that time (I used to use MyClass.getName()).  That
doesn't work now, you now need to call a static method which _requires_ the
class to have been loaded. (It took me a few hours to track this one down when I
upgraded Java :-( ).

Chris Haynes


"Eric Rizzo" asked



<snip>
>Anyone have any other ideas for configuring a shared component without
>relying on a servlet or filter to do it?






-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Interaction between servlet filters and ServletContextListeners

Eric Rizzo
On 10/3/05, Chris Haynes <[hidden email]> wrote:
> Have a static flag in the shared component Class which is set when
> initialization has been done. Check this each time the component is used. There
> is usually something which is 'null' before initialization - test this. Just
> watch out for thread-safety - make sure that two (or more) threads can't both
> think they are doing the initialization.
>
> Alternative, if this fits your logic: initialize the components by including a
> static{} block in the Class. This block will be executed as the class is loaded,
> and it is guaranteed to be thread-safe.

I'd like to avoid having to make the component read it's own
configuration file - my hope was to use the filter or an
"initialization servlet" loaded at startup, which have init params
from web.xml, to be the bootstrap of the component.

I did look at the Servlet spec and all it has to say about ordering
are these bits:
[describing context lifecycle events] "The servlet context has just
been created and is available to service its first request, or the
servlet context is about to be shut down."

"The container is required to complete instantiation of the listener
classes in a Web
application prior to the start of execution of the first request into
the application."

Could it be argued that Jetty is in violation of the first statement,
because when Jetty sends the context start event the servlets and
filters are NOT ready to begin servicing requests?

Even if there is no agreement about that interpretation, I guess I'm
asking if the Jetty team would consider that context listeners should
not be notified until the servlets and filters have been initialized.
It seems less logical that the listeners get called before the
servlets/filters are actually ready for servicing requests.

Any of the Jetty devs have anything to say about this?

Eric


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Interaction between servlet filters and ServletContextListeners

Greg Wilkins-5


the javadoc (which is considered part of the specification) says:

     /**
     * Notification that the web application initialization
     * process is starting.
     * All ServletContextListeners are notified of context
     * initialisation before any filter or servlet in the web
     * application is initialized.
     */
    public void contextInitialized(ServletContextEvent sce);


Now I had the "debate" on the JSR that this is some strange
definition of the past tense and that perhaps we should have
taken the opportunity of the 2.3, 2.4 or 2.5 to rename this
(or at least introduce the correctly named method with a deprecated
wrongly named version).

But no....

So I'm 99.9% sure jetty is compliant with the spec... but I've been
bittne by that 0.1% before :-)

cheers
 



Eric Rizzo wrote:

> On 10/3/05, Chris Haynes <[hidden email]> wrote:
>
>>Have a static flag in the shared component Class which is set when
>>initialization has been done. Check this each time the component is used. There
>>is usually something which is 'null' before initialization - test this. Just
>>watch out for thread-safety - make sure that two (or more) threads can't both
>>think they are doing the initialization.
>>
>>Alternative, if this fits your logic: initialize the components by including a
>>static{} block in the Class. This block will be executed as the class is loaded,
>>and it is guaranteed to be thread-safe.
>
>
> I'd like to avoid having to make the component read it's own
> configuration file - my hope was to use the filter or an
> "initialization servlet" loaded at startup, which have init params
> from web.xml, to be the bootstrap of the component.
>
> I did look at the Servlet spec and all it has to say about ordering
> are these bits:
> [describing context lifecycle events] "The servlet context has just
> been created and is available to service its first request, or the
> servlet context is about to be shut down."
>
> "The container is required to complete instantiation of the listener
> classes in a Web
> application prior to the start of execution of the first request into
> the application."
>
> Could it be argued that Jetty is in violation of the first statement,
> because when Jetty sends the context start event the servlets and
> filters are NOT ready to begin servicing requests?
>
> Even if there is no agreement about that interpretation, I guess I'm
> asking if the Jetty team would consider that context listeners should
> not be notified until the servlets and filters have been initialized.
> It seems less logical that the listeners get called before the
> servlets/filters are actually ready for servicing requests.
>
> Any of the Jetty devs have anything to say about this?
>
> Eric
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Interaction between servlet filters and ServletContextListeners

Eric Rizzo
On 10/6/05, Greg Wilkins <[hidden email]> wrote:

>
>
> the javadoc (which is considered part of the specification) says:
>
>      /**
>      * Notification that the web application initialization
>      * process is starting.
>      * All ServletContextListeners are notified of context
>      * initialisation before any filter or servlet in the web
>      * application is initialized.
>      */
>     public void contextInitialized(ServletContextEvent sce);

Which, in addition to contradicting its own method name (as you point
out), seems to pretty much contradict the phrase "The servlet context
has just
been created and is available to service its first request" because a
context is not ready to service a request until its filters and
servlets have been init-ed.
Gosh, I love it when specifications are contradictory and ambiguous :-(


> Now I had the "debate" on the JSR that this is some strange
> definition of the past tense and that perhaps we should have
> taken the opportunity of the 2.3, 2.4 or 2.5 to rename this
> (or at least introduce the correctly named method with a deprecated
> wrongly named version).
>
> But no....
>
> So I'm 99.9% sure jetty is compliant with the spec... but I've been
> bittne by that 0.1% before :-)

That is a pretty sad story. But I'll agree that Jetty is not
technically in violation (I suppose there's a separate debate about
whether you can ever be in compliance or violation with a
contradictory and ambiguous specification).
Luckily for me I have some alternative approaches for what I need to
do - sad for the community because it is crap like this in the specs
that keeps people from using what are supposed to be useful features.

Thanks for the info,
Eric


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support