You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Michael Hart <mi...@perceptek.com.au> on 2003/05/28 03:54:53 UTC

Logging issues/suggestions

Hi,

I'm not sure if this should be considered a developer issue or not, so if
it's more relevant to the developer's list, let me know and I'll move it
over there.

It seems to me that while the logging in OJB is currently pretty good, it
could be improved quite a bit by a number of small enhancements before going
to RC4:


1. Changing line 247 in OJB.properties that currently reads:
org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=WARN
to:
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN

because AFAICS the first line doesn't do anything. (users can then change
the level to DEBUG if they want to see interesting output)

Note that in the log4j.properties file, JdbcAccessImpl is there (commented)
instead of the incorrect JdbcAccess.


2. Making sure PoorMansLoggerImpl actually checks the logging level before
returning false for isDebugEnabled() (instead of always returning false,
which stops a number of classes from outputting debug statements, including
SqlGeneratorDefaultImpl). Log4J works fine, but PoorMansLoggerImpl should as
well.


3. Including logging statements in JdbcAccessImpl.java after each statement
is bound (usually before it's executed). If the PreparedStatement
implementation has overridden the toString method in a useful way (as does
the PostGres JDBC driver, and I'm sure others), then you can see the SQL
without needing P6Spy. For example, lines 258-259 could become:

broker.serviceStatementManager().bindStatement(stmt, query, cld, 1);
logger.debug("Executing SQL: " + stmt);
ResultSet rs = stmt.executeQuery();

I've made this change in my local version of JdbcAccessImpl.java and it
works a treat.

HSQLDB doesn't have the toString method in their PreparedStatement
implementation, but if you download the source, then you can see that it's a
very easy fix. Just add this method to
src/org/hsqldb/jdbcPreparedStatement.java:

public String toString()
{
    return this.build();
}

(unfortunately jdbcPreparedStatement.build() is a private method so the
above method cannot be implemented in a subclass).


Do these suggestions sound useful to anyone, or am I way off track?

Cheers,

Michael

P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server would help
a lot of newbies as well :-) (I'm assuming this is the problem - that .tgz
is being interpreted as a TAR archive instead of a GZIP archive. An entry
like this into Apache's mime.types might help: "application/x-gzip  tgz")


Re: Logging issues/suggestions

Posted by Mauricio CASTRO <mc...@hotmail.com>.
Great!

>
> P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server would
help
> a lot of newbies as well :-) (I'm assuming this is the problem - that .tgz
> is being interpreted as a TAR archive instead of a GZIP archive. An entry
> like this into Apache's mime.types might help: "application/x-gzip  tgz")


Re: Logging issues/suggestions

Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi michael,

checked id 3.

jakob


Michael Hart wrote:

>Hi Armin,
>
>  
>
>>currently checked in
>>1. and 2.
>>    
>>
>
>Vielen Dank!
>
>  
>
>>please re-post your remaining proposals to
>>the dev-list.
>>    
>>
>
>Will do, as soon as I get the time. Just gotta join up first.
>
>Thanks,
>
>Michael
>
><snip>
>
>  
>
>>>It seems to me that while the logging in OJB is currently pretty good,
>>>      
>>>
>>it
>>    
>>
>>>could be improved quite a bit by a number of small enhancements before
>>>      
>>>
>>going
>>    
>>
>>>to RC4:
>>>
>>>
>>>1. Changing line 247 in OJB.properties that currently reads:
>>>org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=WARN
>>>to:
>>>org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN
>>>
>>>because AFAICS the first line doesn't do anything. (users can then
>>>      
>>>
>>change
>>    
>>
>>>the level to DEBUG if they want to see interesting output)
>>>
>>>Note that in the log4j.properties file, JdbcAccessImpl is there
>>>      
>>>
>>(commented)
>>    
>>
>>>instead of the incorrect JdbcAccess.
>>>
>>>
>>>2. Making sure PoorMansLoggerImpl actually checks the logging level
>>>      
>>>
>>before
>>    
>>
>>>returning false for isDebugEnabled() (instead of always returning
>>>      
>>>
>>false,
>>    
>>
>>>which stops a number of classes from outputting debug statements,
>>>      
>>>
>>including
>>    
>>
>>>SqlGeneratorDefaultImpl). Log4J works fine, but PoorMansLoggerImpl
>>>      
>>>
>>should as
>>    
>>
>>>well.
>>>
>>>
>>>3. Including logging statements in JdbcAccessImpl.java after each
>>>      
>>>
>>statement
>>    
>>
>>>is bound (usually before it's executed). If the PreparedStatement
>>>implementation has overridden the toString method in a useful way (as
>>>      
>>>
>>does
>>    
>>
>>>the PostGres JDBC driver, and I'm sure others), then you can see the
>>>      
>>>
>>SQL
>>    
>>
>>>without needing P6Spy. For example, lines 258-259 could become:
>>>
>>>broker.serviceStatementManager().bindStatement(stmt, query, cld, 1);
>>>logger.debug("Executing SQL: " + stmt);
>>>ResultSet rs = stmt.executeQuery();
>>>
>>>I've made this change in my local version of JdbcAccessImpl.java and
>>>      
>>>
>>it
>>    
>>
>>>works a treat.
>>>
>>>HSQLDB doesn't have the toString method in their PreparedStatement
>>>implementation, but if you download the source, then you can see that
>>>      
>>>
>>it's a
>>    
>>
>>>very easy fix. Just add this method to
>>>src/org/hsqldb/jdbcPreparedStatement.java:
>>>
>>>public String toString()
>>>{
>>>    return this.build();
>>>}
>>>
>>>(unfortunately jdbcPreparedStatement.build() is a private method so
>>>      
>>>
>>the
>>    
>>
>>>above method cannot be implemented in a subclass).
>>>
>>>
>>>Do these suggestions sound useful to anyone, or am I way off track?
>>>
>>>Cheers,
>>>
>>>Michael
>>>
>>>P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server
>>>      
>>>
>>would help
>>    
>>
>>>a lot of newbies as well :-) (I'm assuming this is the problem - that
>>>      
>>>
>>.tgz
>>    
>>
>>>is being interpreted as a TAR archive instead of a GZIP archive. An
>>>      
>>>
>>entry
>>    
>>
>>>like this into Apache's mime.types might help: "application/x-gzip
>>>      
>>>
>>tgz")
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>  
>


RE: Logging issues/suggestions

Posted by Michael Hart <mi...@perceptek.com.au>.
Hi Armin,

> currently checked in
> 1. and 2.

Vielen Dank!

> please re-post your remaining proposals to
> the dev-list.

Will do, as soon as I get the time. Just gotta join up first.

Thanks,

Michael

<snip>

> > It seems to me that while the logging in OJB is currently pretty good,
> it
> > could be improved quite a bit by a number of small enhancements before
> going
> > to RC4:
> >
> >
> > 1. Changing line 247 in OJB.properties that currently reads:
> > org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=WARN
> > to:
> > org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN
> >
> > because AFAICS the first line doesn't do anything. (users can then
> change
> > the level to DEBUG if they want to see interesting output)
> >
> > Note that in the log4j.properties file, JdbcAccessImpl is there
> (commented)
> > instead of the incorrect JdbcAccess.
> >
> >
> > 2. Making sure PoorMansLoggerImpl actually checks the logging level
> before
> > returning false for isDebugEnabled() (instead of always returning
> false,
> > which stops a number of classes from outputting debug statements,
> including
> > SqlGeneratorDefaultImpl). Log4J works fine, but PoorMansLoggerImpl
> should as
> > well.
> >
> >
> > 3. Including logging statements in JdbcAccessImpl.java after each
> statement
> > is bound (usually before it's executed). If the PreparedStatement
> > implementation has overridden the toString method in a useful way (as
> does
> > the PostGres JDBC driver, and I'm sure others), then you can see the
> SQL
> > without needing P6Spy. For example, lines 258-259 could become:
> >
> > broker.serviceStatementManager().bindStatement(stmt, query, cld, 1);
> > logger.debug("Executing SQL: " + stmt);
> > ResultSet rs = stmt.executeQuery();
> >
> > I've made this change in my local version of JdbcAccessImpl.java and
> it
> > works a treat.
> >
> > HSQLDB doesn't have the toString method in their PreparedStatement
> > implementation, but if you download the source, then you can see that
> it's a
> > very easy fix. Just add this method to
> > src/org/hsqldb/jdbcPreparedStatement.java:
> >
> > public String toString()
> > {
> >     return this.build();
> > }
> >
> > (unfortunately jdbcPreparedStatement.build() is a private method so
> the
> > above method cannot be implemented in a subclass).
> >
> >
> > Do these suggestions sound useful to anyone, or am I way off track?
> >
> > Cheers,
> >
> > Michael
> >
> > P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server
> would help
> > a lot of newbies as well :-) (I'm assuming this is the problem - that
> .tgz
> > is being interpreted as a TAR archive instead of a GZIP archive. An
> entry
> > like this into Apache's mime.types might help: "application/x-gzip
> tgz")
> >


Re: Logging issues/suggestions

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Michael,

currently checked in
1. and 2.

please re-post your remaining proposals to
the dev-list.

regards,
Armin

----- Original Message -----
From: "Michael Hart" <mi...@perceptek.com.au>
To: "OJB Users List" <oj...@db.apache.org>
Sent: Wednesday, May 28, 2003 3:54 AM
Subject: Logging issues/suggestions


> Hi,
>
> I'm not sure if this should be considered a developer issue or not, so
if
> it's more relevant to the developer's list, let me know and I'll move
it
> over there.
>
> It seems to me that while the logging in OJB is currently pretty good,
it
> could be improved quite a bit by a number of small enhancements before
going
> to RC4:
>
>
> 1. Changing line 247 in OJB.properties that currently reads:
> org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=WARN
> to:
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN
>
> because AFAICS the first line doesn't do anything. (users can then
change
> the level to DEBUG if they want to see interesting output)
>
> Note that in the log4j.properties file, JdbcAccessImpl is there
(commented)
> instead of the incorrect JdbcAccess.
>
>
> 2. Making sure PoorMansLoggerImpl actually checks the logging level
before
> returning false for isDebugEnabled() (instead of always returning
false,
> which stops a number of classes from outputting debug statements,
including
> SqlGeneratorDefaultImpl). Log4J works fine, but PoorMansLoggerImpl
should as
> well.
>
>
> 3. Including logging statements in JdbcAccessImpl.java after each
statement
> is bound (usually before it's executed). If the PreparedStatement
> implementation has overridden the toString method in a useful way (as
does
> the PostGres JDBC driver, and I'm sure others), then you can see the
SQL
> without needing P6Spy. For example, lines 258-259 could become:
>
> broker.serviceStatementManager().bindStatement(stmt, query, cld, 1);
> logger.debug("Executing SQL: " + stmt);
> ResultSet rs = stmt.executeQuery();
>
> I've made this change in my local version of JdbcAccessImpl.java and
it
> works a treat.
>
> HSQLDB doesn't have the toString method in their PreparedStatement
> implementation, but if you download the source, then you can see that
it's a
> very easy fix. Just add this method to
> src/org/hsqldb/jdbcPreparedStatement.java:
>
> public String toString()
> {
>     return this.build();
> }
>
> (unfortunately jdbcPreparedStatement.build() is a private method so
the
> above method cannot be implemented in a subclass).
>
>
> Do these suggestions sound useful to anyone, or am I way off track?
>
> Cheers,
>
> Michael
>
> P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server
would help
> a lot of newbies as well :-) (I'm assuming this is the problem - that
.tgz
> is being interpreted as a TAR archive instead of a GZIP archive. An
entry
> like this into Apache's mime.types might help: "application/x-gzip
tgz")
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>