ConnectionProvider may normally return the same connection for a call to
getConnection(), so we add a separate getTxConnection() which is guaranteed to
always return a connection that's not in use by anyone else.
The DataSourceConnectionProvider already meets that requirement because it
returns connections from a pool, but the StaticConnectionProvider does not. In
the latter case, we just open a new connection to the database every time you
do a transaction. Since StaticConnectionProvider is only used for testing (in
conjunction with Depot anyway, Yohoho uses it in production IIRC), this is not
a big deal.
For the 'IntAdjust' and 'BooleanAdjust' classes, handle
PropertyChangeEvents where the values are null or Strings instead of
the expected Integer or Boolean types, respectively.
It's kinda amazing that this has never come up before.
Each Adjust stores to a PrefsConfig, which is backed by a Properties,
which stores all values as Strings. Not only that, but it does not
store in any way what the expected type of a property is.
It is determined by which getter you call:
_cfg.setValue("foo", "2");
_cfg.getValue("foo", (String)null); // returns "2"
_cfg.getValue("foo", 0); // returns 2
_cfg.getValue("foo", 3.0f); // returns 2.0f
If a property is removed, then null is the new value, and it also
doesn't know what type the old value was. These runtime adjusts
need to be able to revert to their default value and they will
always need to be able to potentially parse a String. And since
someone can legally change the type of a property, they need
to be able to recover if the property is a type they don't even
expect.
The real problem here is using shitty Properties for backing,
and/or not storing something more complex than the simple toString()
representation of the value.
Don't interpret this fix as a blessing to use these old, old things.
I'm supporting legacy code.
The other adjust subclasses weren't ...adjusted... because my project
doesn't use them and I'm not going to dig in and test them.
Since we're rejiggering, we'll take this opportunity to eliminate the use of -1
as a sentinel id. Maybe your database id generator returns -1. Unlikely, but
not impossible.
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.
Michael Bayne