The surefire report only shows the test results using the H2 database. It might make sense to capture the output of the tests for all database platforms that we are using in the CI environment.

is licensing clarified?

License says:

• 2. Redistributions in binary form must reproduce the above copyright
• notice, this list of conditions and the following disclaimer in
• the documentation and/or other materials provided with the
• distribution.
  Not sure that binary form (jar in this case I believe) contains license. I think the license file is not present anywhere in the jar.

License says:

• 5. Products derived from this software may not be called "P6Spy"
• nor may "P6Spy" appear in their names without prior written
• permission of Jeff Goke and Andy Martin.

Is that OK with original authors, that the fork is called the same as original?

this one was inspired by the project: https://code.google.com/p/log4jdbc/

I'd consider it as an alternative configuration way (the old one via modifed classname and unchanged url + configured driver in the spy.properties would work as well)

However together with #29 this could lead us to zero-conf use case (for those not interested in any specifics).

sample would be to migrate url from:

jdbc:h2:mem:p6spy

to:

jdbc:p6spy:h2:mem:p6spy

no more mapping in the spy.properties would be required, and we could possibly end up also with the: multi datasource support (#33).

Still not 100% sure on implementation yet :)

• Create a distribution artifact containing p6spy.jar, spy.properties, javadocs, and a static copy of the maven site.
• Update the installation docs accordingly

Hi,

was the current code ever released? The latest version in the public maven repositories seems 1.3.
Also, trying to compile the code results in a whole bunch of test failures. What is the state of this all?

I don' t like the idea of having P6SpyDriver2, P6SpyDriver3 as part of our codebase.

In maven there is however generate-sources phase. I'd like to have the sources of these classes generated. Moreover it could make sence to introduce similar concept for P6DataSource, to have an option to proxy more than just one datasource.

Where the counts of these could be held as some pom.xml property for easy changing it, possibly providing more than just 3.

As far as I understand it, the problem is that the only reference we have is the class name, so it has to be somehow distinguished.

Or am I missing something and there is a better solution available?

Is this version of p6spy able to operate with XA drivers?

I didn't see anything mentioning XA in the (sites) documentation, either in terms of configuration or issues/troubleshooting.

Thanks!

it would be nice to setup continuous integration on the project to prevent legacy code. travis-ci could do the job. in the beginning, maybe some basic junit tests should run automatically. Once this is done, there could be some integration testing introduced for various DBs.

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/18/

I use the trunk version from the SVN (2.0-SNAPSHOT) and when I look at the log I cannot see which values are passed to a stored procedure:
1275938874256|175|1|statement|{call WEB.GET_REM_SAI(?, ?)}|{call WEB.GET_REM_SAI(null, null)}
Nevertheless, it does work for the SELECT statement.
I didn't check the source to see where it could be wrong...

Since p6spy.com is no longer a valid site, there is no place for uses to go to find the most current version of the documentation for p6spy. We should update the build process to publish the documentation to the GitHub wiki pages.

It might also make sense to merge the static html documentation with the site generated by maven.

Any exceptions thrown by proxied class are rethrown as UndeclaredThrowableException with InvocationTargetException as the cause.

I've noticed, that there used to be usually 2 spy.properties spy.log files. One existed if it was configured so (holding all the log module produced messages), however the other one used to be created in the folder where java prg was executed where the reloading related stuff was logged.

Since I refactored the options loading the second one is gone.

However I think this would be a right place for discussion/clarification.
Do we really want to have a static path where we log these? I don't think so.

However as we need to log even prio to having all the properties loaded, system property could be the way for altering the default name/path of this one.

I'd suggest to have this one holding all stuff logged, that is spy framework related itself (reloading, possibly prining the effective settings,... to enable problem analysis). So that common p6spy users would not need to open it at all.

Ideas welcome.

I really like the progress done with maven site publishing.

While browsing it I've seen some minor issues:

• on http://p6spy.github.io/p6spy/index.html clicking link called JBoss gives me HTTP 404
• when going to http://p6spy.github.io/p6spy/install.html there seems to be incorrect encoding/illegal characters used, for example: IBM� WebSphere

See http://maven.apache.org/guides/mini/guide-central-repository-upload.html for details

Add a new module to the build which adds support for java 7. This will allow for the new methods added to the various javax.sql.* interfaces to be called when using p6spy.

Since it is difficult to find the 1.3 version of the docs, we should publish the 1.3 and 2.0 versions. This should make it easier for users to find the version of the documentation that they need.

All of the drivers that we currently use for testing are type4 which register automatically. Since they behave slightly different from other drivers, we should have at least one other type of jdbc driver used in our test cases.

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/14/

Methods like
ResultSet.getInt(int columnIndex)
ResultSet.getString(int)
ResultSet.getObject(int)
etc.
returns invalid values if there is more than one column in the result set with the same name.

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/8/

Say you have table
A
with attribute
x
b_id
and a row:
aaa 1
and table b
with attribute
x
id
and a row:
bbb 1
and you execute a :
SELECT a.x,b.x from a, b where a.b_id=b.id
you get the same value (aaa) returned for the
x-column even if they are very different - this is a

this is something I have in my mind since I started contributing to project.

I think these days AOP is very popular and what could make sence would be to prevent all the referencing of the P6Spy in the bussines code/configuration and just go for the regular stuff, however if adding some specific p6spy-aop-aspectj (or whatever the name would be) to classpath and having particular aop java agent used, P6spy could wrap all the DB communication "automatically" via some interceptors/pointcuts.

The thing is that these days, people consider AOP as the way to go for logging. I think that it makes sense for DB statements logging as well.

And here I see the point where people using aop could find p6spy useful.
If we would have maven modules like these:

• p6spy-parent (already exists)
• p6spy (already exists)
• p6spy-aop-aspectj (would depend on p6spy)
• p6spy-aop-jbossaop (would depend on p6spy)
  ...

people would in the perfect world scenario include just the specific module in their project and having some defaults set via #29 that could be all they need to do. No realdriver config mess at all.

moreover if people currently have own aop wrappers, this could remove implementation fragmentation and bring us all benefit of well tested single code base.

technically, I'm not sure this can be achieved, but based on some playing around with aspectj, I believe it could be. still we could reuse the power of p6spy logging, just the starting point might be interceptor rather than wrapped real connection.

Ideas?

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/17/

I noticed a bug concerning the "exclude" option.
In the file spy.properties it is said that "exclude" takes a "comma separated list of tables to exclude when filtering". After looking in the current source of the svn trunk I found out that
P6LogQuery.foundTable()
contains the statement
found = Pattern.matches(tables[i], sql);
The JDK-API for Pattern states that
public static boolean matches(String regex, CharSequence input)
takes a regexp as first arg but tables[i] is a tablename and no regexp. Therefore e.g. Pattern.matches("SOMETABLE", "SELECT * FROM SOMETABLE WHERE BLA") will not match and every sql call is passed into the p6spy log.
Simple fix:
found = sql.indexOf(tables[i]) >= 0;

I know from my experience, that I always forget to include legal stuff to the file headers.

However I think there should be a maven plugin checking it for us, and I'd be OK with breaking the build in case of violation. Otherwise probably noone cares.

Use JDK proxies instead to the proxy classes that are currently maintained. This will eliminate most of the classes in the com.p6spy.engine.spy package.

Example:
In P6DriverCore, the getConnection method will wrap the connection with an instance of P6Connection for each enabled module. Instead of even having the P6Connection class, we would just create a dynamic proxy which intercepts the methods that we are interested in (determined by the enabled modules of course).

it would be nice to migrate the old issues present at sourceforge (https://sourceforge.net/p/p6spy/_list/tickets), to track progress on what is pending from the old days.

There seems to be a semi-automated way possible using: https://github.com/ttencate/sf2github

travis build fails with the following msg:

[INFO] Creating 897 blobs
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.213s
[INFO] Finished at: Wed Sep 25 20:52:16 UTC 2013
[INFO] Final Memory: 11M/136M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.github:site-maven-plugin:0.8:site (default-cli) on project p6spy-parent: Error creating blob: API rate limit exceeded for quintonm. See http://developer.github.com/v3/#rate-limiting for details. (403) -> > [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

The command "mvn -N ghSite:site" exited with 1.

that is quite bad, as it seems we hit the hour limits of the plugin:
http://developer.github.com/v3/#rate-limiting

the temporary solution I see there is to generate the site only from let's say oraclejdk run.

Anyway, this is quite bad. The more frequently we'd build, the more failing builds we'd have. It pretty much contradits the idea of CI and frequents builds.
Ideas?

https://travis-ci.org/p6spy/p6spy/jobs/12436318

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/13/

Prepared statements are not correctly logged.
The sql statement is not the same as the one executed
by the Database.
example :

1. Prepared statement definition
   UPDATE orders SET OPPOSITECOUNTRY = ? , overseadate = ?
   , hazardousdetails = ? , CONTACTNAME = ? , CONTACTFAX =
   ? , CONTACTEMAIL = ? , CONTACTREMARKS = ? ,
   CONTACTPHONE = ? , containerno = ? , sealno = ? ,
   PRESETMODE = ? , CUSTOMSTDOCU = ? , CUSTOMSINSTRUCTION
   = ? , REMARKS = ? , vatid = ? , loadrequest = ? ,
   lastvalidationstartdate = ? WHERE id = ?
2. Prepared statement execution
   UPDATE orders SET OPPOSITECOUNTRY = '' , overseadate =
   '' , hazardousdetails = '' , CONTACTNAME = '' ,
   CONTACTFAX = '' , CONTACTEMAIL = '' , CONTACTREMARKS =
   '' , CONTACTPHONE = '' , containerno = '' , sealno = ''
   , PRESETMODE = '' , CUSTOMSTDOCU = 'true' ,
   CUSTOMSINSTRUCTION = '' , REMARKS = '' , vatid = '' ,
   loadrequest = '' , lastvalidationstartdate = '' WHERE
   id = 1351
   The last query (2.) is not valid. All values are
   written between single quotes, but some of them are
   boolean or numeric.

as the idea seems worth an effort moving from mailing list discussion, see: https://groups.google.com/forum/#!msg/p6spy-developers/rV3t8Sz86L4/2YINYG0DQtwJ

This was originally part of p6spy but it only worked with JBoss. This can be re-worked to allow it to be used without any app server dependency.

The purpose of Subclasser was to allow access to vendor specific methods without any workarounds (http://p6spy.github.io/p6spy/1.3/knownissues.html). In 1.3 and earlier, there were methods to return the real object that was being proxied. The only way to for users access these methods directly without calling these other methods, was to use the Subclasser. The basic idea is that it would generate subclasses (using the Ant task) of the various classes that got proxied.

Although 2.0 uses dynamic proxies, we still have the same problem. The generated proxy classes only implement the methods defined on the interface(s). It is possible for the dynamics proxies to expose the vendor specific methods but only if they are also defined by an interface.

One benefit of using CGLIB to generate the proxies classes is that the proxies would be subclasses of the classes being proxied. This would allow access to the vendor specific methods without having to go through any extra steps.

The only problem with using CGLIB is that it would be a dependency. I think that one really nice feature of P6Spy is that there is a single jar file which will not conflict with anything else.

One option to use CGLIB would be to only use it if it is found on the classpath. I think that this could work although I am not sure how much work would be involved. Ideally, the ProxyFactory would handle the details without requiring any changes to the invocation handlers or delegates.

Another option would be to include CGLIB in our jar file. The basic idea would be exactly the same as used in cglib_nodep which is to take any dependencies and refactor them into a new package structure. This allows them to be included in the same jar without any risk of conflicts with other libraries.

Hello,

Just wondering if you have any space to host the generated documentation? Would be great not to have to clone the source just to read any documentation.

If you don't I can put it up on my domain for now. If so give me a shout

Regards
Tomas Malmsten

Seems simple enough but the documentation still talks about the ant build

As described in the comments of ad8e282, the format of the log message needs to be configurable.

It's a pretty easy change to
com.p6spy.engine.common.P6LogQuery to get this working.
Line 423, just also add a check that the category is ok, e.g.,
change
if (logger != null) {
to
if (logger != null && isCategoryOk(category)) {
I'll try to attach the modified file to show this if I can
figure out this forum software.

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/9/

I downloaded the newest version today. While I put it
into my system, I found that the "result" could not be
excluded. And I noticed that in the manual, it is said
"result" while in log it's "resultset". So I add
"resultset" to the excluded list. Nothing happens. So I
refer to the source code. Em, I catch it.
In P6ResultSet.java ( I does not use the real code
here, because this box has no source code. :( )
public boolean next() throws SQLException {
// create the string buffer;
// log directly
// return proxyObject.next();
}
Although the sub-class "P6LogResultSet" re-write the
next() method, but it's a wrong way as the following:
public boolean next() throws SQLException {
try {
return super.next();
}
catch ( Exception ex ) {
// log with contriol
}
}
So it's clear where cause the trouble. And in
P6ResultSet.next(), there is a performance issue. Why
not check if log needed first here? Think about a
resultset with over 10K rows and each row has more than
100 columns.
After all, I am glad to see all the SQL's our system
sending to the DBMS. A good job. We can make it better.

this might be a bit weird, but up to now I was not able to figure out how to have multiple datasources proxied with the p6spy.

The way I fixed it for our use case was patching the old (sourceforge) sources and adding P6DataSource2.java, P6DataSource3.java

The point is that the only mapping seem to be the class name (defined in the jdbc pool) that is later in the spy.properties mapped via:
realdatasource=
realdatasourceclass=

having single P6DataSource class mapping doesn't enable multiple datasources as far as I can see.

for the P6Driver it's rather easy, as the mapping is done using connection url as far as I understand.

I was hoping that #32 would help me with that. however the problem with #32 is that it would probably intercept all the connection, not just some.

Ideas?

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/15/

p6spy fails to load when the path to the properties file contains a space.
E.g. /E:/Program%20Files/apache-tomcat-5.5.26/webapps/myapp/WEB-INF/classes/spy.properties
We narrowed the problem to classLoadPropertyFile() in P6Util.java. The solution is to decode the URL path before passing it to the File constructor:
public static File classLoadPropertyFile(java.net.URL purl) {
try {
if (purl != null) {
// modified by jayakumar for JDK 1.2 support
//return new File(purl.getPath());
// return new File(getPath(purl));
// modified by davidmcmeans to handle %20's, etc. in the URL path
return new File( URLDecoder.decode( purl.getPath(), "UTF-8" ));
// end of modification
}
} catch (Exception e) {
// we ignore this, since JDK 1.2 does not suppport this method
}
return null;
}

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/16/

Using the latest 5/27/09 svn snapshot, P6LogResultSet throws a CastCastException with H2Database.
I don't completely understand how it happens since the code seems to indicate that only a P6Connection would be returned, but instead a JDBCConnection is being returned.
The following patch provides a temporary workaround for the problem, but I don't think it qualifies as a real fix.

spy.properties should not be included in the p6spy jar file. This will make it very difficult for users to supply their own version.

However, it does make sense for spy.properties to be an optional file. To accomplish that, we should first load a default version which is stored in the jar and then look for spy.properties on the classpath. Anything found in spy.properties will override any settings in the default properties file.

this should include following steps:

• moving Readme.html to our site docs
• moving JDBCLeak.jsp to webcontrol module
• exposing leak P6Objects via jmx

This was part of the build process for 1.3 but it was not re-implemented when the project was mavenized.

it would be nice to have static analysis running on our code.

here we might depend upon: travis-ci/travis-ci#929

sonarqube (http://www.sonarqube.org/) seem to be the standard for java these days, however hosting might be tricky, however as suggested: http://stackoverflow.com/questions/15715812/free-sonar-instanse-for-open-sourced-projects we might have a chance to get hosting on http://nemo.sonarsource.org/ once asking for it

Migrated from sourceforge: https://sourceforge.net/p/p6spy/bugs/11/

Any idea why when spy is initialised it tries to write
to a spy.log file that is relative to where you are
running it from?
I am specifiying a different logfile path in
spy.properties but I see two spy.log files appear, the
problem is however, I am running the java from a
directory without write permissions...
[email protected]