> Meh... I'd still like to log the exception in English, and have
> a way to gather a message useful enough for reporting in
> the UI. The way gt2 does it logs the messages transalated.
> Now, I'm not sure I would be happy to receive a stacktrace
> from a users's log in Thai :)
Right :). Good point.
>
> As for a wicket way, I don't know... but I don't believe there
> is one. I'll look into it, yet so far it seems the viable way is
> still to attach a generic key and param inside the exceptions
> that we know we'll need to use for error reporting in the UI?
>
> interface LocalizableException {
> String getKey();
> Object[] getParams();
> }
I could go for this. I guess under the covers it would run through the
GeoServer i18n process to resolve the key to an error message? If so
then perhaps we should break out an exception for ui purposes. Something
like:
class WebException extends Exception (or RuntimeException?) {
WebException(GeoServerApplication app, String key);
WebException(GeoServerApplication app, String key, Object[] params );
...
}
>
> Generally speaking a normal exception would do, it's just that
> in this auto configure case many things may go wrong. I can
> create a set of exception subclasses of course, and avoid messing
> with the rest of the code.
>
> Cheers
> Andrea
>
> !DSPAM:4007,48653410267535409313003!
>
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
