> like any other library...
> put the .jar file of the lib in the WEB-INF/lib of
> your webapp
Wrong in so many ways.
You don't add drivers to WEB-INF/lib if they're being acquired as datasources - the server needs access to the driver to create the data source. If you're not using a DataSource but materializing the connection directly, then this advice is semi-correct, but it's a crappy way to build a web app.
You don't normally add a JAR for the Sun JDBC ODBC bridge anyway as it's present by default in their J2SE implementation.
And finally, I think WebLogic doesn't use the Sun J2SE implementation anyway, so it's possible that the bridge is not available at all.
So the correct answer is: Don't use the bridge driver. Acquire a driver for your specific database and use that. And make sure that it's available to the application server. If you absolutely must use the bridge driver, you're going to have to use the Sun J2SE implementation to run WebLogic - and I think you'll have to consult the WebLogic site for help with that.
> why wouldn't he manage is own datasource?
Because in a server application it's bad practice.
> there is a world between server managed pooled
> datasources and DriverManager.getConnection
True. And a webapp is no place for the latter. Note that this has nothing to do with connection pooling considerations.
> note that sometime in a certain professional context,
> you don't really have the choice.
Huh? Such as?
The only circumstances I can imagine under which you'd have this obligation is if you're condemned to work with an application that already does this. In which case someone else has already made an unprofessional choice.
> the bad practice, as far as I know, is to apply the
> good practices mindlessly
What benefits do you believe accrue from acquiring connections directly?
> > note that sometime in a certain professional
> context,
> > you don't really have the choice.
>
> Huh? Such as?
Such as "I'm being paid to do a job that I have no fsking clue how to do correctly, so I'll beat it with a hammer until it works."
> > > note that sometime in a certain professional
> > context,
> > > you don't really have the choice.
> >
> > Huh? Such as?
>
> Such as "I'm being paid to do a job that I have no
> fsking clue how to do correctly, so I'll beat it with
> a hammer until it works."
And if it doesn't work get a BFH (Bigger F*cking Hammer). ;-)
> Such as "I'm being paid to do a job that I have no
> fsking clue how to do correctly, so I'll beat it with
> a hammer until it works."
:-)
The only one I can think of is that it's easier in the short term. So it might be just about suitable for a really simple prototype that will never be deployed elsewhere. Except that the marginal difference is pretty slight once you know how to set up a data source, so even then I doubt it's really worth it, particularly given the tendancy for prototype code to get sucked into the end project.
> The only one I can think of is that it's easier in
> the short term. So it might be just about suitable
> for a really simple prototype that will never be
> deployed elsewhere.
Famous last words: "This is just sloppy prototype code. It'll never make it in to production."
;-)