Best practice for initializing JDBC connection in Servlets.

[Roedy Green]

This is a risk you take with any third party library.
The opensource nature of Spring (Apache Licensed) negates a great deal of
this risk.

That certainly helps. The other thing that helps is an API that has
multiple implementations, e.g. JavaMail and Servlet which should be
pretty safe.

 

[Roedy Green]

Spring doesn't, in fact, it works very well with other products. for
example, it has excellent support for Hibernate, JDO, IBatis, JSP,
Velocity, Tapestry, ...

There's the essential problem. If a package interacts with or has
support for some other third party package, then somebody has to keep
tweaking to KEEP things working. It also implies that the product will
not work with competitors. Every new package you add to your
repertoire cuts you off from some others.

I am speaking in general. I don't know anything about Spring.

I work with a company now whose CEO is in love with all new
technology. He is a rare breed. He looks for excuses to try out
anything new. The catch is, anyone coming on board has a huge
learning curve. You are expected to handle that on your own time.

There is always a penalty for introducing ANY new package into your
programming mix. There has to be a substantial benefit IN YOUR CASE
to justify that.

In general people are too reluctant to try anything new. I also think
people are overly eager to ADOPT new technology without taking it out
for a test ride, then reevaluating how useful it indeed was.

I feel like someone on a sea cruise presented with a buffet of 1000
items. There is no way to even sample everything. What should I even
taste?

Marketing is less important. Hints from fellows in the same line of
work are more useful.

See http://www.cluetrain.com/ and scroll down to the 95 theses.

 

[Job Numbers]

There's the essential problem. If a package interacts with or has
support for some other third party package, then somebody has to keep
tweaking to KEEP things working. It also implies that the product will
not work with competitors. Every new package you add to your
repertoire cuts you off from some others.

I am speaking in general. I don't know anything about Spring.

I work with a company now whose CEO is in love with all new
technology. He is a rare breed. He looks for excuses to try out
anything new. The catch is, anyone coming on board has a huge
learning curve. You are expected to handle that on your own time.

There is always a penalty for introducing ANY new package into your
programming mix. There has to be a substantial benefit IN YOUR CASE
to justify that.

In general people are too reluctant to try anything new. I also think
people are overly eager to ADOPT new technology without taking it out
for a test ride, then reevaluating how useful it indeed was.

I feel like someone on a sea cruise presented with a buffet of 1000
items. There is no way to even sample everything. What should I even
taste?

Marketing is less important. Hints from fellows in the same line of
work are more useful.

See http://www.cluetrain.com/ and scroll down to the 95 theses.

But in spring's case, everything is interface based and you can just
implement what you need. So, let's just say the newest version of hibernate
is not supported at all (extremely unlikely, but let's just say), you could
just implement that orm module to spring's interfaces and swap the old one
with the new one and voilla. The thing is, spring doesn't force you to
extend anything really, unless you have to (like controllers). But even
then, you don't even have to use spring's controllers at all. The point is,
it doesn't tie you to spring or any other technology, and when it does, it's
tied to a well designed interface that you can implement yourself if you
really have to (although after 6 months of using the framework, this hasn't
happened). Oh yeah, the two main developers (rod and jeurgon) are really
smart guys who have a lots of enterprise experience. I'd give them some
credit and give the software a try.

 

[Roedy Green]

So, let's just say the newest version of hibernate
is not supported at all (extremely unlikely, but let's just say), you could
just implement that orm module to spring's interfaces and swap the old one
with the new one and voilla.

But you may not have the time, energy or expertise to do that. It is
great thing when people publish and document interfaces so you can fix
broken bits, but it is no substitute for having someone else fix them
for you.

That sort of thing is so easy for the original developers, but takes
such a learning curve for someone coming in cold.

I know about the perils of not-invented here, but the big advantage of
writing my own code is that I can pick it up later and fairly quickly
understand it. I am kind to my future self by leaving the hints on
what I know I will forget. It is so strange communicating with my
former self. I can't recall writing any of it, but the style is
familiar.

So much stuff out there seems like complete Greek. I can't figure out
even what it is even TRYING to do much less how it does it. I just
feel like someone is trying to sell me some triviality wrapped up in a
grand-sounding package with an overly-complicated overly-general
interface. It is like eating too many marshmallows.

 

[Roedy Green]

But in spring's case, everything is interface based and you can just
implement what you need.

Any time you introduce a new package into your toolbox, you want to
ask yourself "What would I do if this package just stopped working?"

1. would it be easy to find a replacement, or would it mean rewriting
every line code I have ever written to switch to something else?
(mitigates against one-source compilers).

2. Could I take on the maintenance myself? Would it a reasonably
shoulderable burden for me or my company? I think some very large
companies are overly skittish in this regard.

3. will many others likely be in my boat so someone else will create
the replacement?

4. Is this unlikely to happen because the interface e.g. JavaMail is
so widely supported or widely used?

5. how deeply intertwined will this be with everything else? How
easily will it be plug replaceable with something else?

6. the biggie is will this tool just introduce complexity and learning
curve for everyone coming aboard or will it pay back many times over?