RealtionalDatabase DataConnectory documentation
Cantor, Scott
cantor.2 at osu.edu
Wed Feb 4 10:37:30 EST 2015
> I'd appreciate it if you could review it for the usual typos, but mostly for
> accuracy (this aimed particularly Daniel and Scott since I might have missed
> a nuance somewhere).
I've been bogged in other stuff, but I'll get back to docs soon hopefully.
> 1) I haven't a clue how JNDI works and so the documentation I wrote is less
> than helpful (especially the example)
I use it now, so I'll take care of it. You have to edit web.xml in general, and it's container specific obviously. I know how to do Jetty.
> 2) Is it worth shimming the C3PO pool element we use for
> ApplicationManagedConnection to allow XML durations to be specified? I
> think not since the legacy configuration is a mishmash of seconds and
> milliseconds and adding durations would probably confuse rather than help.
We're actually deprecating that, we just didn't get around to that formally, so we'll do it as of 3.1. c3p0 is buggy as hell and basically broken, so we were kind of stuck with that for now but we want to dump it. The "proper" way is with a Spring bean or JNDI data source that uses whatever pooling you want (dbcp being a good choice).
> 3) (An observation rather than a question) There are three different
> mechanisms to inject Spring Beans: The freestanding config resource, and
> beans specified as attributes (velocityEngine and mappingStrategyRef) and
> as element contents (<BeanManagedConnection> and <ResultCacheBean>).
Is that 3, or 2?
Anyway, yeah, I sort of wasn't sure if we should use elements for those when we shipped, but I decided to leave it since it was a nice parallel with the other connection types. I don't expect anybody's ever going to inject a velocityEngine, and the mapping bean is going to be almost as rare, so I doubt it will hurt much.
-- Scott
More information about the dev
mailing list