I wanted something like this before, but with guava's Function,
and samskivert doesn't depend have dependencies.
But with Java 8 coming, functional interfaces make the distinction
between different interfaces less important.
There was no way to set the "long threshold" per-Invoker.
A Unit could override getLongThreshold(), or you could set a static
jvm-wide long threshold for all Invokers.
That doesn't make sense. Set the long threshold you need on each invoker.
All existing behavior is preserved for the time being, but I've deprecated
the static method.
Units return 0 now to indicate that they don't have their own setting.
I'm pretty sure nobody out there is doing anything kooky like
"return 500 + super.getLongThreshold();" at least in the code I've scanned.
Really, they should both be deprecated. Log your exceptions.
If there's a special place where you have to hack it to not log
an exception, that special place can damn well create its own no-op
listener. Or be fixed!
Having an abstract class that only implements a blank requestCompleted()
would make sense, as would a sharable singleton instance that does
nothing on success and always logs on failure. Hmm.
This is somewhat temporary code to try something out...
In our production environment there are mails getting lost.
I'd like to find out why.
Try using a TransportListener. This is more complicated.
Also the listener may be getting added many times. We shall see.
I also made them package private where possible. It's too easy for code that
depends on samskivert to accidentally import com.samskivert.Log rather than
define its own logger.
Unfortunately Java doesn't have "this package and subpackages" protection, so
some of the package loggers have to be public to allow sub-packages to access
them. I didn't really want to have to define loggers for half a dozen
subpackages as well.
Going through the servlet config is kind of pointless when there's almost
always a one to one connection between a DispatcherServlet and an Application.
Said version of HSQLDB freaks out if primary keys are included in the UNIQUE
clause when creating a table. They're unique by definition, and the HSQLDB
authors are clearly strong believers in DRY. So much so that RY is considered
an error in this case.
This adds an overload. A better way might be to configure some sort of builder
and finish with request(), but that's a larger refactor and if I was doing
that there'd be plenty to fix.
ArrayList and friends explicitly call equals() on the supplied object with the
array object as the argument, rather than the other way around. This allows one
to, for example, pass in some sort of Key object that can compare itself for
equality against a list of KeyedValue objects.
This sort of delicate dance around the equality contract is dangerous, but we
should let the caller decide whether they wish to dance with the devil.
Per the wailing and gnashing of teeth in response to 7e51d4c and 7bb7ee2,
I'll do the extra legwork to keep my bits in a List despite java handing
them to me as an array.
Ray J. Greenwell