I created a JIRA issue (with trivial patch).

https://issues.apache.org/jira/browse/WICKET-1991

Regards,
Sebastiaan

Antoine van Wel wrote:
agree with Sebastiaan and Michael here

when a user types a wrong url, you're not going to log that
404 -> client error, file not found -> no fixes necessary, so not logged
500 -> server error -> log it, needs to be fixed


so instead of implementing the filter, I prefer waiting for a Wicket
patch..  :-)


Antoine

On Mon, Dec 22, 2008 at 7:16 PM, Michael Sparer <[email protected]> wrote:
the thing is that 404 is a client error. I'd only log server errors (i.e.
errors in the code) as Error. Of course a 404 can also happen due to a error
in the code, but logging 404 as errors will flood your log file ...

just my two cents



Jeremy Thomerson-5 wrote:
A 404 is an error - so on the one hand you say it is an error, but on the
other, you say it isn't.  I think it should remain an error.

Just my 0.02 though.

On Mon, Dec 22, 2008 at 7:56 AM, Sebastiaan van Erk
<[email protected]>wrote:

Pointbreak wrote:

Not an answer to your question, but why fight this kind of stuff? It's
an invalid request, so it should result in an error.

I actually prefer it would result in a 404 for the client and nothing
more.
Perhaps, when enabling DEBUG, it can log the message + exception it is
currently logging as ERROR.

If you don't want these entries in your log, you could just add a filter
to your logger (e.g. filtering out error messages from
org.apache.wicket.request.target.resource.SharedResourceRequestTarget
where the message equals "unable to lazily register shared resource").

It is annoying (and dangerous) to filter your log in this way. The
problem
is that you may accidentally filter too much and miss real errors. Also,
it
requires you to know a lot about wicket internals (is this a real error,
or
should this be considered a warning?). And it is cumbersome (every time a
new exception appears, you have to go through this process again).

To the Wicket developers: why is this logged using log.error and not
using
log.debug (in SharedResourceRequestTarget#respond? It's not really an
error,
it's a reference to a resource that does not exist, and a 404 should be
sufficient (without ERRORs in the log).

Regards,
Sebastiaan


On Mon, 22 Dec 2008 14:05 +0100, "Antoine van Wel"
<[email protected]> wrote:

Heya,

we're trying to catch all errors caused by hack & search-bots on our
wicket-app. AFAIK these bots take existing links, chop 'em up in
smaller chunks and try to append all kind of ****. We've caught most
of the errors which result due to these bots, but this one still
stands:

XXX.XXX.XXX.XXX - - [22/Dec/2008:00:03:37 +0100] "GET

/resources/org.apache.wicket.markup.html.WicketEventReference_false_61497/
HTTP/1.1" 404 952 "-" "-" "-"

Causing errors such as

2008-12-22 00:03:41,654 ERROR -

[TP-Processor7][org.apache.wicket.request.target.resource.SharedResourceRequestTarget:172]
unable to lazily register shared resource
org.apache.wicket.ajax.WicketAjaxReference_false_61497/
java.lang.ClassNotFoundException:
org.apache.wicket.ajax.WicketAjaxReference_false_61497
     at


org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)

[...snip...]


So... any ideas to catch these errors?



Antoine



--
We don't see things as they are, we see things as we are. - Anais Nin
Whether you think you can or whether you think you can't, you're
right. - Henry Ford

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



--
Jeremy Thomerson
http://www.wickettraining.com



-----
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context: 
http://www.nabble.com/error-messages-due-to-hack-search-bots-tp21127488p21132409.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to