If a database model does not produce the expected results right away, it can be tricky to figure out what is going wrong. The cause can lie with the application, with the specified properties, with the database, etc. Luckily, there are a number of ways to debug what is going on, at different levels in the application.
Like any other model decoder, LuciadLightspeed will produce an
if it fails to open a spatial database model. The message of the
IOException should provide more details on the origin of the problem.
Typically, some properties are not set correctly, or the spatial
database is not set up properly.
In addition, you can get feedback on the SQL queries that are sent to the database, by switching on logging for the relevant package. See the Logging documentation for more information on setting up logging in a LuciadLightspeed application.
The initial queries that you will see in the logging output generally request some metadata about the spatial tables. Subsequent queries will typically request the actual data, based on spatial bounds and on primary keys. If one of the queries fails, you can try to copy/paste it in an interactive SQL console, to see which part is causing problems. This can be especially useful if you have specified additional selection tables and filters, which are weaved into the SQL query.
At a lower level, you can get feedback about any JDBC operations, directly from JDBC. The JDBC API provides a standard hook, which you can set up from your program by calling:
At similarly low level, the Oracle driver can provide feedback about its interactions with the Oracle database. The Oracle driver provides a debug flag that you can specify from the command line. For this flag to work, the debugging jar ojdbc_g.jar has to be specified in the class path instead of the traditional jar ojdbc.jar. The java command line then looks something like:
java -Doracle.jdbc.Trace=true -Djava.util.logging.config.file=OracleLog.properties ......
Optionally, the resulting output can be directed to a file instead of to the
-Doracle.jdbc.LogFile=/tmp/jdbc.log. More details about
debugging with the help of the Oracle driver can be found at
If you are implementing connection pooling with the help of the Proxool
driver, you can also activate its logging. Proxool uses the Apache Commons
logging facilities, which is an abstraction on top of a number of logging
libraries. For example, one of these is the
log4j library. It can be
configured by creating a
log4j.properties file, like the one in
Program: A sample
log4j.properties configuration file., which has to be put in the class path.
log4j.rootLogger=DEBUG, myappender log4j.appender.myappender=org.apache.log4j.ConsoleAppender log4j.appender.myappender.layout=org.apache.log4j.PatternLayout log4j.appender.myappender.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.logicalcobwebs.proxool=TRACE
Logging is then activated by starting the application with the configuration file and the necessary library jars in the class path:
java -cp commons-logging.jar:log4j.jar ......
More information on Apache Commons logging and
log4j can be found at