Otherwise if samskivert.jar is loaded via the root classloader, this will fail
to find classes and resources in the servlet/webapp classloader. Let's not
require that samskivert.jar be duplicated into the webapp in cases where we're
doing complex things like hosting webapps inside larger app servers. That can
cause other fiddly problems with mismatched duplicate copies of classes.
- Nix attempts to link to ancient, no longer in existence, Oracle hosted
Javadocs.
- Manually include code to attach javadocs and source jars during release,
because we no longer get that from the OSS parent pom. We can't use the OSS
parent pom because it redirects release stuff to the ossrh Maven Central
servers that no longer exist. Would be nice if they made and published a new
OSS parent pom. Shrug.
This is the preferred way to obtain a JDBC connection in this millenium. No
longer does one manually instantiate the JDBC driver by name. The JDBC driver
jar file will have a mapping that indicates that it handles a particular type
of JDBC URL and the JDBC infrastructure will handle instantiating the driver.
This makes them invisible to JavaScript (which we don't use) to avoid the
danger of someone injecting JavaScript somehow and stealing auth cookies. It's
a dangerous world out there.
- De-static checkedApply(). It should be overrideable and know
other things about the ObserverList that it belongs to.
- Created an overrideable observerForLog().
- Have the DerefOp include the original Op's toString() in its own.
The SiteResourceLoader is some ancient stuff that's not used anywhere any more,
and there's no use in keeping this crufty crap around to test it. I'd nix it
too but I don't want to cause yet more trouble.
TestUtil was weird and a bad idea and good riddance to it as well.
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.
Michael Bayne