You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by di...@apache.org on 2002/03/29 14:27:39 UTC
cvs commit: jakarta-commons/docs/latka developers-guide.html
dion 02/03/29 05:27:38
Modified: docs/latka developers-guide.html
Log:
Added Rodney's development style comments
Revision Changes Path
1.7 +6 -8 jakarta-commons/docs/latka/developers-guide.html
Index: developers-guide.html
===================================================================
RCS file: /home/cvs/jakarta-commons/docs/latka/developers-guide.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- developers-guide.html 25 Mar 2002 22:09:20 -0000 1.6
+++ developers-guide.html 29 Mar 2002 13:27:38 -0000 1.7
@@ -6,23 +6,21 @@
on <a href="index.html">Latka</a>. Hopefully they will make sense to
those coming after me, and possibly clarify the current state for the existing
</p>
- <p>This should probably be set out (from the source side) more
-like a book than a chapter</p>
- <p>That said, on with the disorganised discourse</p>
</blockquote></td></tr></table><table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#525D76"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Coding%20Style"><strong>Coding Style</strong></a></font></td></tr><tr><td><blockquote>
- <p>Latka has some unusual coding conventions, which I'm trying to
-capture at the moment using a tool, <a href="http://checkstyle.sourceforge.net">CheckStyle</a>. Since I'm not quite
-sure what all the conventions are myself, nothing is really authoratative except
-the source code</p>
+ <p>Latka has some unusual coding conventions, which we've hopefully
+captured using a tool, <a href="http://checkstyle.sourceforge.net">CheckStyle
+</a>.</p>
<p>Onto the conventions... The Sun coding conventions are followed in
most places, except for the items that follow</p>
<ul>
<li><p>private and protected member variables begin with an
underscore, <div align="left"><table border="0" cellpadding="0" cellspacing="4"><tr><td height="1" width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td><td height="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td><td height="1" width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td></tr><tr><td width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td><td height="1" bgcolor="#ffffff"><pre>_requestSucceeded</pre></td><td width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td></tr><tr><td height="1" width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td><td height="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td><td height="1" width="1" bgcolor="#023264"><img border="0" hspace="0" vspace="0" height="1" width="1" src="/images/void.gif"></td></tr></table></div></p></li>
- <li><p>private methods also begin with an underscore</p>
+ <li><p>private methods also begin with an underscore on
+rare occasions (mainly when there is some public method and protected/private
+method with an otherwise identical signature)</p>
</li>
<li><p>Javadoc on classes and methods is not yet complete.
Feel free to help out here :-)</p></li>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DBCP] - 2 Serious Bugs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 2 Apr 2002, James House wrote:
> Date: Tue, 02 Apr 2002 15:02:13 -0700
> From: James House <ja...@interobjective.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [DBCP] - 2 Serious Bugs
>
>
> Just curious - should I be posting bugs like this into Bugzilla, or
> reporting them in this mail list?
>
Bugzilla is better, for two reasons:
* The reports don't get lost in mailboxes
* Everything that happens in bugzilla gets reflected to COMMONS-DEV
anyway.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DBCP] - 2 Serious Bugs
Posted by James House <ja...@interobjective.com>.
Just curious - should I be posting bugs like this into Bugzilla, or
reporting them in this mail list?
At 3/29/2002 11:00 AM -0700, you wrote:
>Actually, the loading of the driver class is what registers it with the
>DriverManager - not the instantiation of the driver class.
>
>The following is from Dirver's doc:
>
> When a Driver class is loaded, it should create an instance of
> itself and register it with the DriverManager. This means that a
> user can load and register a driver by calling
> Class.forName("foo.bah.Driver")
>
>So in the code I outlined below, the driver IS instantiated and registered
>with the DriverManager before getDriver(url) is called.
>
>This is why many drivers have a private constructor -- because a static
>block in the driver is responsible for instantiating and registering
>itself as the class is loaded.
>
>James
>
>
>At 3/29/2002 08:57 PM +0300, you wrote:
>>The following is from DriverManager's doc:
>>
>>public static Driver getDriver(String url)
>> throws SQLException
>>
>> Attempts to locate a driver that understands the given URL. The
>>DriverManager attempts to select an appropriate driver from the
>> set of registered JDBC drivers.
>>
>>
>>So to get driver via url it must be registered first.
>>But to register it you have to have the driver's class instance!
>>
>>James House wrote:
>> >
>> > In the "BasicDataSource.createDataSource()" method, there are 2 serious
>> > bugs in the following block of code:
>> >
>> > ===========================================
>> > // Load the JDBC driver class
>> > Class driverClass = null;
>> > try {
>> > driverClass = Class.forName(driverClassName);
>> > } catch (Throwable t) {
>> > String message = "Cannot load JDBC driver class '" +
>> > driverClassName + "'";
>> > getLogWriter().println(message);
>> > t.printStackTrace(getLogWriter());
>> > throw new SQLException(message);
>> > }
>> >
>> > // Create a JDBC driver instance
>> > Driver driver = null;
>> > try {
>> > driver = (Driver) driverClass.newInstance();
>> > } catch (Throwable t) {
>> > String message = "Cannot create JDBC driver of class '" +
>> > driverClassName + "'";
>> > getLogWriter().println(message);
>> > t.printStackTrace(getLogWriter());
>> > throw new SQLException(message);
>> > }
>> > ===========================================
>> >
>> > The if method createDataSource() encounters a problem loading or
>> > instantiating the JDBC driver, it calls the method
>> > getLogWriter(). getLogWriter() in turn calls createDataSource(), thus
>> > creating an infinite loop, and a stack-overflow exception. Perhaps
>> > createDataSource() needs to simply log it's errors to stderr ???
>> >
>> > The second bug in this block of code causes the creation of the data
>> source
>> > to fail, even though there's no real problem.
>> >
>> > This problem stems from the fact that many JDBC drivers (well, at least 2
>> > that I use regularly) do not have a public constructor, and therefore you
>> > can't call newInstance() on them. (the instantiate themselves in a static
>> > {} block, as they are loaded and registered with driver manager).
>> >
>> > The EASY solution is to replace the second try block body with this call:
>> >
>> > driver = DriverManager.getDriver(url);
>> >
>> > Simple huh?
>> >
>> > If you want to "fix" the two bugs in the manner I've suggested, the
>> > replacement of the block outlined above would be:
>> > ===========================================
>> > import java.sql.DriverManager;
>> > ...
>> >
>> > // Load the JDBC driver class
>> > Class driverClass = null;
>> > try {
>> > driverClass = Class.forName(driverClassName);
>> > } catch (Throwable t) {
>> > String message = "Cannot load JDBC driver class '" +
>> > driverClassName + "'";
>> > System.err.println(message);
>> > t.printStackTrace();
>> > throw new SQLException(message);
>> > }
>> >
>> > // Create a JDBC driver instance
>> > Driver driver = null;
>> > try {
>> > driver = DriverManager.getDriver(url);
>> > } catch (Throwable t) {
>> > String message = "Cannot get a reference to JDBC driver of
>> > class '" +
>> > driverClassName + "' - " + t.getMessage();
>> > System.err.println(message);
>> > t.printStackTrace();
>> > throw new SQLException(message);
>> > }
>> > ===========================================
>> >
>> > BTW: I REALLY appreciate the recent changes that have made the pool
>> > (getConnection()) throw SQLException.
>> >
>> > James
>> >
>> > --
>> > To unsubscribe,
>> e-mail: <ma...@jakarta.apache.org>
>> > For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>--
>>Lev Assinovsky Peterlink Web
>>Programmer St. Petersburg, Russia
>>Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á
>>E-mail: lev@peterlink.ru
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DBCP] - 2 Serious Bugs
Posted by James House <ja...@interobjective.com>.
Actually, the loading of the driver class is what registers it with the
DriverManager - not the instantiation of the driver class.
The following is from Dirver's doc:
When a Driver class is loaded, it should create an instance of
itself and register it with the DriverManager. This means that a
user can load and register a driver by calling
Class.forName("foo.bah.Driver")
So in the code I outlined below, the driver IS instantiated and registered
with the DriverManager before getDriver(url) is called.
This is why many drivers have a private constructor -- because a static
block in the driver is responsible for instantiating and registering itself
as the class is loaded.
James
At 3/29/2002 08:57 PM +0300, you wrote:
>The following is from DriverManager's doc:
>
>public static Driver getDriver(String url)
> throws SQLException
>
> Attempts to locate a driver that understands the given URL. The
>DriverManager attempts to select an appropriate driver from the
> set of registered JDBC drivers.
>
>
>So to get driver via url it must be registered first.
>But to register it you have to have the driver's class instance!
>
>James House wrote:
> >
> > In the "BasicDataSource.createDataSource()" method, there are 2 serious
> > bugs in the following block of code:
> >
> > ===========================================
> > // Load the JDBC driver class
> > Class driverClass = null;
> > try {
> > driverClass = Class.forName(driverClassName);
> > } catch (Throwable t) {
> > String message = "Cannot load JDBC driver class '" +
> > driverClassName + "'";
> > getLogWriter().println(message);
> > t.printStackTrace(getLogWriter());
> > throw new SQLException(message);
> > }
> >
> > // Create a JDBC driver instance
> > Driver driver = null;
> > try {
> > driver = (Driver) driverClass.newInstance();
> > } catch (Throwable t) {
> > String message = "Cannot create JDBC driver of class '" +
> > driverClassName + "'";
> > getLogWriter().println(message);
> > t.printStackTrace(getLogWriter());
> > throw new SQLException(message);
> > }
> > ===========================================
> >
> > The if method createDataSource() encounters a problem loading or
> > instantiating the JDBC driver, it calls the method
> > getLogWriter(). getLogWriter() in turn calls createDataSource(), thus
> > creating an infinite loop, and a stack-overflow exception. Perhaps
> > createDataSource() needs to simply log it's errors to stderr ???
> >
> > The second bug in this block of code causes the creation of the data source
> > to fail, even though there's no real problem.
> >
> > This problem stems from the fact that many JDBC drivers (well, at least 2
> > that I use regularly) do not have a public constructor, and therefore you
> > can't call newInstance() on them. (the instantiate themselves in a static
> > {} block, as they are loaded and registered with driver manager).
> >
> > The EASY solution is to replace the second try block body with this call:
> >
> > driver = DriverManager.getDriver(url);
> >
> > Simple huh?
> >
> > If you want to "fix" the two bugs in the manner I've suggested, the
> > replacement of the block outlined above would be:
> > ===========================================
> > import java.sql.DriverManager;
> > ...
> >
> > // Load the JDBC driver class
> > Class driverClass = null;
> > try {
> > driverClass = Class.forName(driverClassName);
> > } catch (Throwable t) {
> > String message = "Cannot load JDBC driver class '" +
> > driverClassName + "'";
> > System.err.println(message);
> > t.printStackTrace();
> > throw new SQLException(message);
> > }
> >
> > // Create a JDBC driver instance
> > Driver driver = null;
> > try {
> > driver = DriverManager.getDriver(url);
> > } catch (Throwable t) {
> > String message = "Cannot get a reference to JDBC driver of
> > class '" +
> > driverClassName + "' - " + t.getMessage();
> > System.err.println(message);
> > t.printStackTrace();
> > throw new SQLException(message);
> > }
> > ===========================================
> >
> > BTW: I REALLY appreciate the recent changes that have made the pool
> > (getConnection()) throw SQLException.
> >
> > James
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>--
>Lev Assinovsky Peterlink Web
>Programmer St. Petersburg, Russia
>Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á
>E-mail: lev@peterlink.ru
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DBCP] - 2 Serious Bugs
Posted by Juozas Baliuka <ba...@centras.lt>.
Yes, driver doe's it this way :
static{
DriverManager.registerDriver( new MyDriversPrivateConstructor() );
}
> The following is from DriverManager's doc:
>
> public static Driver getDriver(String url)
> throws SQLException
>
> Attempts to locate a driver that understands the given URL. The
> DriverManager attempts to select an appropriate driver from the
> set of registered JDBC drivers.
>
>
> So to get driver via url it must be registered first.
> But to register it you have to have the driver's class instance!
>
> James House wrote:
> >
> > In the "BasicDataSource.createDataSource()" method, there are 2 serious
> > bugs in the following block of code:
> >
> > ===========================================
> > // Load the JDBC driver class
> > Class driverClass = null;
> > try {
> > driverClass = Class.forName(driverClassName);
> > } catch (Throwable t) {
> > String message = "Cannot load JDBC driver class '" +
> > driverClassName + "'";
> > getLogWriter().println(message);
> > t.printStackTrace(getLogWriter());
> > throw new SQLException(message);
> > }
> >
> > // Create a JDBC driver instance
> > Driver driver = null;
> > try {
> > driver = (Driver) driverClass.newInstance();
> > } catch (Throwable t) {
> > String message = "Cannot create JDBC driver of class '" +
> > driverClassName + "'";
> > getLogWriter().println(message);
> > t.printStackTrace(getLogWriter());
> > throw new SQLException(message);
> > }
> > ===========================================
> >
> > The if method createDataSource() encounters a problem loading or
> > instantiating the JDBC driver, it calls the method
> > getLogWriter(). getLogWriter() in turn calls createDataSource(), thus
> > creating an infinite loop, and a stack-overflow exception. Perhaps
> > createDataSource() needs to simply log it's errors to stderr ???
> >
> > The second bug in this block of code causes the creation of the data
source
> > to fail, even though there's no real problem.
> >
> > This problem stems from the fact that many JDBC drivers (well, at least
2
> > that I use regularly) do not have a public constructor, and therefore
you
> > can't call newInstance() on them. (the instantiate themselves in a
static
> > {} block, as they are loaded and registered with driver manager).
> >
> > The EASY solution is to replace the second try block body with this
call:
> >
> > driver = DriverManager.getDriver(url);
> >
> > Simple huh?
> >
> > If you want to "fix" the two bugs in the manner I've suggested, the
> > replacement of the block outlined above would be:
> > ===========================================
> > import java.sql.DriverManager;
> > ...
> >
> > // Load the JDBC driver class
> > Class driverClass = null;
> > try {
> > driverClass = Class.forName(driverClassName);
> > } catch (Throwable t) {
> > String message = "Cannot load JDBC driver class '" +
> > driverClassName + "'";
> > System.err.println(message);
> > t.printStackTrace();
> > throw new SQLException(message);
> > }
> >
> > // Create a JDBC driver instance
> > Driver driver = null;
> > try {
> > driver = DriverManager.getDriver(url);
> > } catch (Throwable t) {
> > String message = "Cannot get a reference to JDBC driver of
> > class '" +
> > driverClassName + "' - " + t.getMessage();
> > System.err.println(message);
> > t.printStackTrace();
> > throw new SQLException(message);
> > }
> > ===========================================
> >
> > BTW: I REALLY appreciate the recent changes that have made the pool
> > (getConnection()) throw SQLException.
> >
> > James
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
> Lev Assinovsky Peterlink Web
> Programmer St. Petersburg, Russia
> Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á
> E-mail: lev@peterlink.ru
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DBCP] - 2 Serious Bugs
Posted by Lev Assinovsky <le...@peterlink.ru>.
The following is from DriverManager's doc:
public static Driver getDriver(String url)
throws SQLException
Attempts to locate a driver that understands the given URL. The
DriverManager attempts to select an appropriate driver from the
set of registered JDBC drivers.
So to get driver via url it must be registered first.
But to register it you have to have the driver's class instance!
James House wrote:
>
> In the "BasicDataSource.createDataSource()" method, there are 2 serious
> bugs in the following block of code:
>
> ===========================================
> // Load the JDBC driver class
> Class driverClass = null;
> try {
> driverClass = Class.forName(driverClassName);
> } catch (Throwable t) {
> String message = "Cannot load JDBC driver class '" +
> driverClassName + "'";
> getLogWriter().println(message);
> t.printStackTrace(getLogWriter());
> throw new SQLException(message);
> }
>
> // Create a JDBC driver instance
> Driver driver = null;
> try {
> driver = (Driver) driverClass.newInstance();
> } catch (Throwable t) {
> String message = "Cannot create JDBC driver of class '" +
> driverClassName + "'";
> getLogWriter().println(message);
> t.printStackTrace(getLogWriter());
> throw new SQLException(message);
> }
> ===========================================
>
> The if method createDataSource() encounters a problem loading or
> instantiating the JDBC driver, it calls the method
> getLogWriter(). getLogWriter() in turn calls createDataSource(), thus
> creating an infinite loop, and a stack-overflow exception. Perhaps
> createDataSource() needs to simply log it's errors to stderr ???
>
> The second bug in this block of code causes the creation of the data source
> to fail, even though there's no real problem.
>
> This problem stems from the fact that many JDBC drivers (well, at least 2
> that I use regularly) do not have a public constructor, and therefore you
> can't call newInstance() on them. (the instantiate themselves in a static
> {} block, as they are loaded and registered with driver manager).
>
> The EASY solution is to replace the second try block body with this call:
>
> driver = DriverManager.getDriver(url);
>
> Simple huh?
>
> If you want to "fix" the two bugs in the manner I've suggested, the
> replacement of the block outlined above would be:
> ===========================================
> import java.sql.DriverManager;
> ...
>
> // Load the JDBC driver class
> Class driverClass = null;
> try {
> driverClass = Class.forName(driverClassName);
> } catch (Throwable t) {
> String message = "Cannot load JDBC driver class '" +
> driverClassName + "'";
> System.err.println(message);
> t.printStackTrace();
> throw new SQLException(message);
> }
>
> // Create a JDBC driver instance
> Driver driver = null;
> try {
> driver = DriverManager.getDriver(url);
> } catch (Throwable t) {
> String message = "Cannot get a reference to JDBC driver of
> class '" +
> driverClassName + "' - " + t.getMessage();
> System.err.println(message);
> t.printStackTrace();
> throw new SQLException(message);
> }
> ===========================================
>
> BTW: I REALLY appreciate the recent changes that have made the pool
> (getConnection()) throw SQLException.
>
> James
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Lev Assinovsky Peterlink Web
Programmer St. Petersburg, Russia
Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á
E-mail: lev@peterlink.ru
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[DBCP] - 2 Serious Bugs
Posted by James House <ja...@interobjective.com>.
In the "BasicDataSource.createDataSource()" method, there are 2 serious
bugs in the following block of code:
===========================================
// Load the JDBC driver class
Class driverClass = null;
try {
driverClass = Class.forName(driverClassName);
} catch (Throwable t) {
String message = "Cannot load JDBC driver class '" +
driverClassName + "'";
getLogWriter().println(message);
t.printStackTrace(getLogWriter());
throw new SQLException(message);
}
// Create a JDBC driver instance
Driver driver = null;
try {
driver = (Driver) driverClass.newInstance();
} catch (Throwable t) {
String message = "Cannot create JDBC driver of class '" +
driverClassName + "'";
getLogWriter().println(message);
t.printStackTrace(getLogWriter());
throw new SQLException(message);
}
===========================================
The if method createDataSource() encounters a problem loading or
instantiating the JDBC driver, it calls the method
getLogWriter(). getLogWriter() in turn calls createDataSource(), thus
creating an infinite loop, and a stack-overflow exception. Perhaps
createDataSource() needs to simply log it's errors to stderr ???
The second bug in this block of code causes the creation of the data source
to fail, even though there's no real problem.
This problem stems from the fact that many JDBC drivers (well, at least 2
that I use regularly) do not have a public constructor, and therefore you
can't call newInstance() on them. (the instantiate themselves in a static
{} block, as they are loaded and registered with driver manager).
The EASY solution is to replace the second try block body with this call:
driver = DriverManager.getDriver(url);
Simple huh?
If you want to "fix" the two bugs in the manner I've suggested, the
replacement of the block outlined above would be:
===========================================
import java.sql.DriverManager;
...
// Load the JDBC driver class
Class driverClass = null;
try {
driverClass = Class.forName(driverClassName);
} catch (Throwable t) {
String message = "Cannot load JDBC driver class '" +
driverClassName + "'";
System.err.println(message);
t.printStackTrace();
throw new SQLException(message);
}
// Create a JDBC driver instance
Driver driver = null;
try {
driver = DriverManager.getDriver(url);
} catch (Throwable t) {
String message = "Cannot get a reference to JDBC driver of
class '" +
driverClassName + "' - " + t.getMessage();
System.err.println(message);
t.printStackTrace();
throw new SQLException(message);
}
===========================================
BTW: I REALLY appreciate the recent changes that have made the pool
(getConnection()) throw SQLException.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>