On Wed, 28 Mar 2001, Kevin Jones wrote:
> > Here's the rationale for this behavior (and the fact that Tomcat also
> > marks the app unavailable if it didn't initialize all the listeners and
> > filters successfully):
>
> But it doesn't, at least not in the latest nightly. I have a listener
> configured and the class file is missing. Tomcat seems not to have
> initialised any of the listeners but the application is still available.
>
That's a bug. The intent was to mark the app as unavailable in that
circumstance.
> > Let's say you are implementing user authentication yourself, and using
> > filters. You specify connection information to a database in your filter
> > params, but mistype the password so that the connection cannot be
> > established, so your filter's init() method throws an exception. If
> > Tomcat just logged this as a warning and went on deploying your app, it
> > would now be running with *no* authentication, potentially exposing
> > sensitive information. Is that what you *really* want to have happen?
> >
> > One might argue missing listeners would be less severe a risk than missing
> > filters, but IMHO that isn't the container's judgement to make -- the user
> > has an incomplete application deployed; better to make them go fix it
> > rather than trying to run only part of it.
>
> But it is a judgement the container is making - In my app it doesn't matter
> much if the filters/listeners are missing. I would argue that for listeners
> the behaviour should be the same as for <load-on-startup> servlets and that
> the principle of least surprise would be applied. I would guess that
> initially most listeners would be ported from load-on-startup servlets (mine
> are), of one of those servlets was missing the application still started,
> and the servlets still executed. Least surprise tells me that listeners
> should behave the same way. Is there some way we could configure this in
> server.xml or do you think that is overkill.
>
In the absence of spec requirements one way or the other, that is probably
rational -- adding an attribute on <Context> (and <DefaultContext)) that
defines this would not be terribly difficult.
> BTW should we also add a note in the spec. about this?
>
Who is "we" ? :-) We can certainly communicate that suggestion to
[EMAIL PROTECTED] and to the expert group.
> Kevin Jones
> DevelopMentor
> www.develop.com
>
Craig
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: 28 March 2001 04:14
> > To: Tomcat-Dev
> > Subject: Re: Listeners
> >
> >
> >
> >
> > On Tue, 27 Mar 2001, Kevin Jones wrote:
> >
> > > Tomcat 4.0 stops configuring listeners if one of the listeners
> > in the list
> > > isn't present, should it carry on configuring the rest of the
> > listeners it
> > > finds? The spec is silent on this and it seems odd that if
> > somebody (maybe
> > > accidentally) deletes a listener class all other following
> > listeners are not
> > > configured (any listener preceding the missing listener would
> > already have
> > > been initialised).
> > >
> >
> > Here's the rationale for this behavior (and the fact that Tomcat also
> > marks the app unavailable if it didn't initialize all the listeners and
> > filters successfully):
> >
> > Let's say you are implementing user authentication yourself, and using
> > filters. You specify connection information to a database in your filter
> > params, but mistype the password so that the connection cannot be
> > established, so your filter's init() method throws an exception. If
> > Tomcat just logged this as a warning and went on deploying your app, it
> > would now be running with *no* authentication, potentially exposing
> > sensitive information. Is that what you *really* want to have happen?
> >
> > One might argue missing listeners would be less severe a risk than missing
> > filters, but IMHO that isn't the container's judgement to make -- the user
> > has an incomplete application deployed; better to make them go fix it
> > rather than trying to run only part of it.
> >
> > > I've also raised this as a bug,
> > >
> > > Thanks,
> > >
> > > Kevin
> > >
> > >
> >
> > Craig
> >
>
>
