Sonar

Tried with latest release and I have this on startup

RuntimeError in ProjectsController#index

The driver encountered an error: can't convert nil into String
RAILS_ROOT: /Users/snicoll/projects/sonar/tomcat/webapps/sonar/WEB-INF

Application Trace | Framework Trace | Full Trace
gems/gems/activerecord-jdbc-adapter-0.8.2/lib/active_record/connection_adapters/jdbc_adapter.rb:313:in `initialize'
gems/gems/activerecord-jdbc-adapter-0.8.2/lib/active_record/connection_adapters/jdbc_adapter.rb:46:in `jdbc_connection'
gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:291:in `connection='
gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:259:in `retrieve_connection'
gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection'
gems/gems/activerecord-2.0.2/lib/active_record/query_cache.rb:8:in `cache'
gems/gems/actionpack-2.0.2/lib/action_controller/caching.rb:677:in `perform_action_with_caching'
gems/gems/actionpack-2.0.2/lib/action_controller/base.rb:524:in `process'
gems/gems/actionpack-2.0.2/lib/action_controller/filters.rb:685:in `process_with_filters'
gems/gems/actionpack-2.0.2/lib/action_controller/session_management.rb:123:in `process_with_session_management_support'
gems/gems/actionpack-2.0.2/lib/action_controller/base.rb:388:in `process'
gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:171:in `handle_request'
gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:115:in `dispatch'
gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi'
gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:9:in `dispatch'
file:/Users/snicoll/projects/sonar/tomcat/webapps/sonar/WEB-INF/lib/jruby-rack-0.9.3.jar!/rack/adapter/rails.rb:37:in `serve_rails'
file:/Users/snicoll/projects/sonar/tomcat/webapps/sonar/WEB-INF/lib/jruby-rack-0.9.3.jar!/rack/adapter/rails.rb:44:in `call'
file:/Users/snicoll/projects/sonar/tomcat/webapps/sonar/WEB-INF/lib/jruby-rack-0.9.3.jar!/jruby/rack/rails.rb:145:in `call'
file:/Users/snicoll/projects/sonar/tomcat/webapps/sonar/WEB-INF/lib/jruby-rack-0.9.3.jar!/rack/handler/servlet.rb:17:in `call'

Hi Stephane,
do you confirm that the setup phase is OK and that it fails on the second page (all projects) ? What's your JDBC URL please ?
Thank you

I've tried this with 1.6 and here's my experience.

1. Download and install the postgres JDBC driver, see site for appropriate version for installed JVM (http://jdbc.postgresql.org/download.html). Note that the extension location must be postgres for Sonar to locate the driver when starting (see org.sonar.core.ExtensionsFinder.getJdbcDrivers).

   wget http://jdbc.postgresql.org/download/postgresql-8.3-604.jdbc4.jar
   mkdir sonar-1.6/extensions/jdbc-driver/postgres
   cp postgresql-8.3-604.jdbc4.jar sonar-1.6/extensions/jdbc-driver/postgres/

2. Configure Sonar to use PostgreSQL in sonar-1.6/conf/sonar.properties
   The settings I used are:

   # PostgreSQL
   sonar.jdbc.url:                            jdbc:postgresql://localhost/sonar
   sonar.jdbc.driverClassName:                org.postgresql.Driver
   sonar.jdbc.validationQuery:                select 1

3. Add the new jdbc directory to the classpath by editing sonar-1.6/conf/wrapper.conf . This is necessary so that Jetty can load the drivers for JNDI access.

   wrapper.java.classpath.XX=../../extensions/jdbc-driver/postgres/*.jar

A usability suggestion: could the jdbc extensions path be changed to make it easier to add new drivers without changing the wrapper conf. Maybe putting all the drivers into extensions/jdbc-driver/ then the wrapper classpath can just be wrapper.java.classpath.XX=../../extensions/jdbc-driver/*.jar . That would also require changes to the ExtensionsFinder.getJdbcDrivers .

Sonar starts up fine but when I go to the local Sonar instance I get an error page "We're sorry, but something went wrong." and the logs then have an error in them. I can't get to the first page where I setup the database. The error is the same as originally reported, although formatted differently. I'm willing to be a test subject for PostgreSQL support, even if it's unofficial.

Result from wrapper.log; 14:30 is when I hit the web interface.

STATUS | wrapper  | 2009/03/16 14:17:03 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2009/03/16 14:17:03 | Java Service Wrapper Community Edition 3.3.0
STATUS | wrapper  | 2009/03/16 14:17:03 |   Copyright (C) 1999-2008 Tanuki Software, Inc.  All Rights Reserved.
STATUS | wrapper  | 2009/03/16 14:17:03 |     http://wrapper.tanukisoftware.org
STATUS | wrapper  | 2009/03/16 14:17:03 | 
STATUS | wrapper  | 2009/03/16 14:17:03 | Launching a JVM...
INFO   | jvm 1    | 2009/03/16 14:17:04 | WrapperManager: Initializing...
INFO   | jvm 1    | 2009/03/16 14:17:05 | 2009-03-16 14:17:05.788::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
INFO   | jvm 1    | 2009/03/16 14:17:05 | 2009-03-16 14:17:05.051::INFO:  jetty-6.1.11
INFO   | jvm 1    | 2009/03/16 14:17:06 | 2009-03-16 14:17:05.204::INFO:  NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
INFO   | jvm 1    | 2009/03/16 14:17:11 | 2009-03-16 14:17:10.093:/:INFO:  Info: using runtime pool timeout of 30 seconds
INFO   | jvm 1    | 2009/03/16 14:17:11 | 2009-03-16 14:17:10.093:/:INFO:  Info: received min runtimes = 1
INFO   | jvm 1    | 2009/03/16 14:17:11 | 2009-03-16 14:17:10.094:/:INFO:  Info: received max runtimes = 4
INFO   | jvm 1    | 2009/03/16 14:17:24 | 2009-03-16 14:17:24.289:/:INFO:  Info: add application to the pool. size now = 1
INFO   | jvm 1    | 2009/03/16 14:17:24 | 2009-03-16 14:17:24.296:/:INFO:   [CompressingFilter/1.6.4] CompressingFilter has initialized
INFO   | jvm 1    | 2009/03/16 14:17:24 | 2009-03-16 14:17:24.339::INFO:  Started SelectChannelConnector@0.0.0.0:9000
INFO   | jvm 1    | 2009/03/16 14:17:24 | Sonar listens http://0.0.0.0:9000/
INFO   | jvm 1    | 2009/03/16 14:30:43 | JNDI data source unavailable: wrong # of arguments(0 for 1); trying straight JDBC

Result from sonar.log:

2009.03.16 14:17:07 INFO  org.sonar.INFO  JDBC datasource bound to JNDI, name=jdbc/sonar
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish 5 GWT extensions to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish org.sonar.plugins.core.resourceviewer.GwtResourceViewer to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish org.sonar.plugins.core.defaultsourceviewer.GwtDefaultSourceViewer to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish org.sonar.plugins.core.codecoveragesourceviewer.GwtCodeCoverageSourceViewer to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish org.sonar.plugins.core.violationssourceviewer.GwtViolationsSourceViewer to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:17:07 INFO  org.sonar.INFO  publish org.sonar.plugins.core.clouds.GwtClouds to /home/jwhitehouse/sonar-1.6/war/sonar-web/deploy/gwt
2009.03.16 14:30:43 ERROR rails.sonar  

RuntimeError (The driver encountered an error: can't convert nil into String):
    /gems/gems/activerecord-jdbc-adapter-0.8.2/lib/active_record/connection_adapters/jdbc_adapter.rb:313:in `initialize'
    /gems/gems/activerecord-jdbc-adapter-0.8.2/lib/active_record/connection_adapters/jdbc_adapter.rb:46:in `jdbc_connection'
    /gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:291:in `connection='
    /gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:259:in `retrieve_connection'
    /gems/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection'
    /gems/gems/activerecord-2.0.2/lib/active_record/query_cache.rb:8:in `cache'
    /gems/gems/actionpack-2.0.2/lib/action_controller/caching.rb:677:in `perform_action_with_caching'
    /gems/gems/actionpack-2.0.2/lib/action_controller/base.rb:524:in `process'
    /gems/gems/actionpack-2.0.2/lib/action_controller/filters.rb:685:in `process_with_filters'
    /gems/gems/actionpack-2.0.2/lib/action_controller/session_management.rb:123:in `process_with_session_management_support'
    /gems/gems/actionpack-2.0.2/lib/action_controller/base.rb:388:in `process'
    /gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:171:in `handle_request'
    /gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:115:in `dispatch'
    /gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi'
    /gems/gems/actionpack-2.0.2/lib/action_controller/dispatcher.rb:9:in `dispatch'
    file:/lib/jruby-rack-0.9.3.jar!/rack/adapter/rails.rb:37:in `serve_rails'
    file:/lib/jruby-rack-0.9.3.jar!/rack/adapter/rails.rb:44:in `call'
    file:/lib/jruby-rack-0.9.3.jar!/jruby/rack/rails.rb:145:in `call'
    file:/lib/jruby-rack-0.9.3.jar!/rack/handler/servlet.rb:17:in `call'
    :1

I made a typo in step 1 and 2: the path to the driver should be postgre not postres.

I have exactly the same problem ans I can't solve it.
This bug just pass from Major [ 3 ] to Minor [ 4 ]. Does that mean a workaround exist ? In this case could you explain it to me ?

Thanks in advance.

Hi,

I started to work on the PostgreSQL support for Sonar. All our project/build infrastructure is built on top of PostgreSQL and I'd really like it to stay that way for consistency reasons.

I know PostgreSQL well but I'm really not a Rails guy so, even if I made it work after struggling for a few hours, I'd appreciate any input on how to properly fix the problems in a maintainable way.

I'd like to have Sonar working out of the box with PostgreSQL, even if it's not supported officially.

1/ the problem above

It's fixed by adding a "driver: org.postgresql.Driver" in the war/sonar-web/WEB-INF/config/database.yml file. I don't know how it's done for the other database though and why it doesn't work for PostgreSQL specifically.

My database.yml is now:
development:
adapter: jdbc
jndi: jdbc/sonar
driver: org.postgresql.Driver
timeout: 5000

production:
adapter: jdbc
jndi: jdbc/sonar
driver: org.postgresql.Driver
timeout: 5000

Then you have the setup page working and you can try to setup the database.

2/ Problem with decimal types

There is an inconsistency in how Sonar uses the decimal type. Either you use a float type with no precision or a decimal/numeric one with precision but you cannot have a float type with a type modifier (e.g. here precision).

In war/sonar-web/WEB-INF/config/environment.rb, there is a few PostgreSQL specific lines which maps decimal to float8. I tried to remove it to let Rails map decimal to numeric, it works for the database creation but it's not consistent with the type present in the Java files (I have an Hibernate exception).

I temporarily fixed it by removing precision, scale and so on from all decimal types in the database creation scripts.

I think we can either:

• map decimal to numeric as it's supposed to be in Rails and change the according type in the Java files (it's the best solution if we really need precision);
• consider that we don't need the precision, that float arithmetic is OK and do as I did it currently.

3/ Sequence naming convention

Default sequence naming for PostgreSQL is <tablename>_<primary key name>_seq: that's how Rails mapped them by default but it's not consistent with the @SequenceGenerator annotations present in the Java code.

I didn't find any good solution so I roughly changed all the @SequenceGenerator lines to map the sequence naming convention of PostgreSQL (I added ID before _SEQ in sequenceName) to see if I could go a bit further and have a running Sonar/PostgreSQL. I know it's ugly and not portable as Oracle has a different naming convention for sequences: we need to find another way to do it correctly.

One of the possibility to fix this issue is to have a special PostgreSQL dialect which overrides the method related to sequences and rewrite the sequence name before returning the sequence related queries.

Any other idea?

4/ It works

I tested one of our projects and the UI seems to work correctly.

I had to add these lines in my settings.xml but it's what we have to do when we don't use the default database so nothing specific:
<settings>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<!-- EXAMPLE FOR MYSQL -->
<sonar.jdbc.url>
jdbc:postgresql://localhost/sonar
</sonar.jdbc.url>
<sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>

<!-- SERVER ON A REMOTE HOST -->
<sonar.host.url>http://localhost:9000</sonar.host.url>
</properties>
</profile>
</profiles>
</settings>

–
Guillaume

I attached 2 files so that people can test easily PostgreSQL support:

• support_postgresql_java.diff is a patch to change the name of the sequences - you need to recompile sonar-commons and copy the new jar to war/sonar-web/WEB-INF/lib/. I can attach the one I compiled if people needs it.
• support_postgresql_rails.diff makes the modifications to the rails configuration files and the database creations scripts.

As stated above, you also need to copy the PostgreSQL driver to: extensions/jdbc-driver/postgre/ (postgre not postgres).

I'm working on a patch to fix the sequence problem in a more elegant way. I'd appreciate comments on how to fix the rails one.

Thanks.

–
Guillaume

Here is another set of patch which solves most of the problems in a clean way:

• I implemented a custom PostgreSQL hibernate dialect which solves the sequence convention naming problem and the type problem;
• I cleant up environment.rb from erroneous lines for PostgreSQL;
• I added the PostgreSQL JDBC driver.

And that's all, apart from the configuration example to make it work.

The only problem left that I don't understand is why I need to define the driver in database.yml. Does anybody have an idea about that?

The ~/.m2/settings.xml should be like that now:
<settings>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<!-- EXAMPLE FOR POSTGRESQL -->
<sonar.jdbc.url>
jdbc:postgresql://localhost/sonar
</sonar.jdbc.url>
<sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
<sonar.jdbc.dialectClass>org.sonar.commons.database.dialect.PostgreSQLWithDecimalDialect</sonar.jdbc.dialectClass>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>

<!-- SERVER ON A REMOTE HOST -->
<sonar.host.url>http://localhost:9000</sonar.host.url>
</properties>
</profile>
</profiles>
</settings>

After the experiments of these last days, here is a real patch against SVN: postgresql_support_final_patch.diff.

This patch makes PostgreSQL a first class citizen in Sonar world without changing the behaviour for other databases so it's safe to apply.

It fixes all the remaining problems in a clean way except the fact that you still need to define the driver explicitely in database.yml (see the end of this message for more details).

• Summary of what the patch does *

After applying this patch:

• the driver is correctly installed where it should be using the Maven dependencies,
• the wrapper conf is ok,
• the types are ok,
• the sequence naming convention is fixed too without any manipulation,
• there's no specific configuration to do except that you need to define explicitely the driver in the database.yml file (see below for more details).

• How to use it *

To use this patch:

• create a sonar database and a sonar user (the default password is sonar)
• apply the patch to your Sonar source tree
• build sonar
• install it
• edit your conf/sonar.properties to comment the Derby lines and uncomment the 3 PostgreSQL lines
• edit your war/sonar-web/WEB-INF/config/database.yml and add the line "driver: org.postgresql.Driver" for each connection
• then start Sonar and it should work.

The .m2/settings.xml should be like this:
<settings>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<!-- EXAMPLE FOR POSTGRESQL -->
<sonar.jdbc.url>
jdbc:postgresql://localhost/sonar
</sonar.jdbc.url>
<sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>

<!-- SERVER ON A REMOTE HOST -->
<sonar.host.url>http://localhost:9000</sonar.host.url>
</properties>
</profile>
</profiles>
</settings>

• License *

The code is compatible with the Sonar license:

• the code contributed is under the LGPLv3 and later like the rest of Sonar and was written by myself for the company I work for (Open Wide)
• the PostgreSQL JDBC driver is BSD licensed

• Remaining problem with the JDBC adapter *

About the remaining problem which makes necessary to define explicitely the driver in database.yml, I think it's a bug in the JDBC adapter. I posted a patch on rubyforge:
http://rubyforge.org/tracker/index.php?func=detail&aid=25631&group_id=2014&atid=7857

I tested it with Derby, MySQL and PostgreSQL and it fixes the problem. It might be interesting if someone could also test it with SQL Server and Oracle: you just need to change a line in your jdbc_adapter.rb and just check if it still works.

I don't know if the Sonar team wants to patch the JDBC adapter shipped with Sonar so I kept this patch separated.

Comments and tests welcome.

–
Guillaume

Thank you Guillaume for the hard work. I'll have a look at your patch very soon (I hope tomorrow).

Thanks Simon.

Feel free to ping me if you have any question. The patch is based on 1.8 (I wanted to be sure the bugs were mine and not due to a development version) but I think it should apply to trunk without too much problem as it doesn't touch any sensitive area. If it doesn't, just tell me and I'll port the patch to trunk.

Note that it might be interesting to implement an OracleSequenceGenerator using the same principles I used for PostgreSQL: you won't have to add @SequenceGenerator with the name of the sequence for each entity.
As the sequence names are generated automatically by Rails from the table metadata, it's IMHO better to have the same logic in the Java code instead of maintaining them manually.

–
Guillaume

The patch works like a charm ! I've added the unit test PostgreSQLSequenceGeneratorTest and fixed the driver limitation in database.yml :

driver: <%= ENV_JAVA['sonar.jdbc.driverClassName'] || 'org.apache.derby.jdbc.ClientDriver' %>'

It works because properties are injected by Java into the Rails application.

Do you confirm that the SequenceGenerator is exactly the same for Oracle ? If I understand, its goal is just to follow Rails conventions when naming sequences. We could rename it "RailsSequenceGenerator" and use it in both Oracle and Postgre dialects.

I have now to setup our integration tests environment before closing the issue.

Thanks again for the work, and sorry for not helping you sooner.

It works because properties are injected by Java into the Rails application.

Oh yeah, I should have thought of it. Stupid me. That said, I still think there's something weird going on in the JDBC adapter.

Do you confirm that the SequenceGenerator is exactly the same for Oracle ? If I understand, its goal is just to follow Rails conventions when naming sequences. We could rename it "RailsSequenceGenerator" and use it in both Oracle and Postgre dialects.

No. The principle is the same but the naming conventions are different. One of my problem was that Oracle and PostgreSQL don't have the same convention for sequence naming so the @SequenceGenerator with a named sequence wasn't acceptable.

The OracleSequenceGenerator should output: TABLENAME_SEQ as it's currently defined in your @SequenceGenerator. I'll provide a draft patch tomorrow in a separate JIRA issue. I can't test it as I don't have any Oracle server here but it will show you what I have in mind.

I have now to setup our integration tests environment before closing the issue.

Yeah, sorry about not writing the tests, I was waiting for a validation of the general principle of the patch before doing so.

Thanks again for the work, and sorry for not helping you sooner.

No problem at all. It was really interesting to dig into Sonar and JRuby. Nice piece of work by the way.

How to install Sonar mode standalone and database postgresql in Centos Server:
I have problems installed!.