• Post Reply Bookmark Topic Watch Topic
  • New Topic

If my listener fails to achieve it's tasks...  RSS feed

 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a piece of my code:
What happens if someone has failed to configure the 'config' init-parameter? The method doesn't throw any exceptions. Is my only choice to throw a RuntimeException ?
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
alright, maybe that was an obvious question.

Yes, it's my only alternative. I guess I'm really asking is : "isn't there a better idiom?"

But maybe I'm using the listener for the wrong sort of thing? But the type of thing I'm trying to do (initialize a database framework) is almost precisely the type of thing the specification mentions for this class.

And even throwing a new java.lang.NullPointerException() seems really hackish. Without my framework, there is no application. So it *should* get taken out. And throwing a Runtime certainly does the job.. the listener throws an exception, and horray, the whole context fails to load.

But maybe I just want the context to say something nice like "unavailable". Which perhaps a container other than Tomcat might do... but that's why I wanted to throw an UnavailableException.

How about this... if I do my stuff in the listener, inside a big try/catch block. If something happens, I can set an application-level flag "configured=false". Then, a filter that listens to /* can check for the configured parameter equal to true.. and if so, then let it pass, otherwise, throw the Exception.

But this seems 'expensive'. Can anyone think of something else ?
[ December 09, 2003: Message edited by: Mike Curwen ]
 
Chad McGowan
Ranch Hand
Posts: 265
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe instead of using a filter, you could just have your controller (if you are using mvc) check the configured flag. If it is configured, it passes the request on. If it is not configured, you forward to the 'Unavailable' page.
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although it's not really "expensive", I see your point and it's not something that you should have to check before *every* request. I've done something similar in my blogging app - if the blog directory isn't setup then the app isn't setup and I throw out an exception. Just make sure you print out a big enough stack trace so that somebody will know that they've incorrectly deployed your app.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm.
1. You don't give many hints what you want to do with the value of the parameter - as it stands, the code just discards it. A bit more idea of how critical the result is to the operation of the application might be handy - can any part of the application continue to work if this is not specified?
2. You don't seem to have considered simply applying a default value in the code if the config value is not present. I never trust deployers or users to set config files right the first time, so I always have a default value in the code:

3. Have you considered doing such initialisation in the "init" method of a servlet marked as "load-on-startup" in the deployment descriptor? At least you are free to return a ServletExceptiom to indoicate that the init did not complete correctly.
[ December 10, 2003: Message edited by: Frank Carver ]
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) from my second post: Without my framework, there is no application. So it *should* get taken out.

2) yup, I do that all the time, but just didn't show it.

3) yes, I've done this before, but thought perhaps a context listener was a more appropriate place... it's what the spec suggests. And it makes a kind of sense. This listener is notified when the entire app is initialized, and if I manage to throw an Exception, it affects the entire context.

If I do the load-on-startup, that's just for one servlet (which of course, could implement an empty doGet and doPost, and *merely* be there for initialization of a ServletContext). But then again, if an exception occured, this won't bring my whole app to an 'unavailable' state (what I need)... it would only mark the single servlet unavailable.

Does the area of 'unavailable application' start to tread into vendor-specifics? I believe (from my thinkings on this particular listener) that the spec should be expanded to provide for some type of higher-level awareness.. not just on a servlet-by-servlet basis. I wonder how long the spec writers thought about the contextInitialized method, and whether or not it could throw an Exception? I believe the reasoning probably went: "who would catch it? - it's a *listener*!"
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) from my second post: Without my framework, there is no application. So it *should* get taken out.
OK, but even in extreme cases I've still always been tempted to have some sort of friendly "system unavailable" page visible to users rather than just a 404 or 500 error. Remember that if an app is completely unavailable, you can't use its custom error page.
Does the area of 'unavailable application' start to tread into vendor-specifics? I believe (from my thinkings on this particular listener) that the spec should be expanded to provide for some type of higher-level awareness..
Hmm. Something like an "init() throws WebApplicationException" for a whole application? In general I like the idea, but I guess I'd be worried that it would be too open to inadvertent abuse - it's kind of equivalent to the dreaded System.exit(), but for web applications.
Your framework may be a vital part of the application at the moment, but what if next month someone adds on a bunch of JSPs which don't need your framework, but just provide useful utility features for users of your application, or even a bunch of static html help files. Your choice to shut down the whole application if your framework can't initialise might seem inappropriate in that situation, but who would think to look for such a case when adding simple new features?
Thinking about this a bit more (and assuming that after reading your init parameter the end result is something shoved into the application context for other code to use) my preferred solution would currently be simply to check the existance of just the required context values in the bits of code that actually use them, and throw an exception there if there is a problem. That way, any parts of the application which actually don't need that particular value can continue to limp on. This just seems a more robust solution for "live" software, than just giving up in initialisation. Keeping the availability-checking near the point of use just seems more intuitive to me.
Sure, log a message, send an email, ring a bell, raise an SNMP trap, or whetever during the init code, so that anyone interested in whether it has failed early will get to know, but don't make life extra hard for users if you don't need to.
I wonder how long the spec writers thought about the contextInitialized method, and whether or not it could throw an Exception? I believe the reasoning probably went: "who would catch it? - it's a *listener*!"
Possibly. But there are also a lot if us who get fed up with the number of explicit exceptions in the APIs at the moment which we have to declare, catch or propagate even though we don't care. Adding a throws clause to an interface method is really something that should not be done lightly - as it forces all implementers and users to add extra code.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!