Is this your complete labkey.log (from /tomcat/logs)? I would expect to see exceptions before this one -- it looks like one or more modules failed to load, which should result in something getting logged before this NPE. Root problem may be database related or some other problem -- difficult to tell without the previous error.

This is a new install of LabKey, correct?

This is indeed a new install of LabKey. There was another version installed previously, but Tomcat has been complete removed and reinstalled and the database removed before installing this latest version of Labkey. I am confident no traces remain of the previous LabKey version.

As for the log file, I have now attached the full log, instead of the part I thought was responsible.

-Aschwin

It seems some files were missing concerning struts, the directory '/opt/labkeyhome/labkeywebapp/WEB-INF/classes/_pageflow/' and its content didn't exist at all, so I copied it over from the 2.2 version I still had on backup .

After this the software complained about not finding 'server-config.wsdd', which I copied from the included 'server-config-original.wsdd' file.

The next problem was about a bunch of other missing files or wrong permissions, which I all copied from the 2.2 version.
labkeywebapp/WEB-INF/jsp/announcements_jsp.jar
labkeywebapp/WEB-INF/jsp/cabig_jsp.jar
labkeywebapp/WEB-INF/classes/_pageflow/struts-config--org-labkey-core-global.xml
labkeywebapp/_images/gray.gif

Now I am stuck with the same error I had last time I tried to install cpas/labkey:
    java.lang.NoClassDefFoundError: org/apache/tomcat/dbcp/dbcp/BasicDataSource

This class is present in /usr/share/tomcat5.5/common/lib/commons-dbcp.jar as 'org/apache/commons/dbcp/BasicDataSource.class'

Do you know any solution to this problem besides recompiling labkey with some modifications?

-Aschwin

The first error in the full log clearly indicates there's a permissions problem -- looks like the tomcat user does not have write permissions to the specified directory (and probably others). That is likely the root problem here and the reason why files are missing. You should NEVER copy files from one version to another -- that will cause big problems.

A few options here:

- Fix the permissions problem, get back to a clean installation of 2.3 (remove all the files you copied from 2.2 or do a new manual installation from scratch), and try to restart the server
- Switch to the Windows graphical installer, which is a much easier way to evaluate LabKey Server
- Contact LabKey Software if you'd like our help getting you up and running on your Debian system

Adam

After a complete reinstall of both Labkey and Tomcat (purged the package first), and setting the proper permission I didn't see any errors concerning missing files and such.
Unfortunately, the DBCP problems persists.

After some further research it becomes clear debian doesn't use the dbcp included with the Apache Tomcat distribution, but instead uses the commons-dbcp. This means that 'org/apache/tomcat/dbcp/dbcp/BasicDataSource' is available as 'org/apache/commons/dbcp/BasicDataSource.class'. I read some hints in some posting that other distributions of Tomcat are doing the same or something similar.

This change happened in the 5.5.15 version of the debian package:
  https://lists.ubuntu.com/archives/edgy-changes/2006-August/004578.html

More information is available from the Ubuntu bug report:
  https://bugs.launchpad.net/ubuntu/+source/tomcat5.5/+bug/74781


Simply installing the missing naming-factory-dbcp.jar from the apache-tomcat binary file, as suggested in the bug-report, didn't work for some reason. It failed with a java.lang.ClassCastException.

Defining the DataSource factory to be used by Labkey didn't work either:
    <Resource name="jdbc/labkeyDataSource" auth="Container"
        type="javax.sql.DataSource"
        factory="org.apache.commons.dbcp.BasicDataSourceFactory"
        username="labkey"
        password="lkcpas91"
        driverClassName="org.postgresql.Driver"
        url="jdbc:postgresql://localhost/labkey"
        maxActive="20"
        maxIdle="10" accessToUnderlyingConnectionAllowed="true"/>

It seems Labkey isn't using the factory configuration, which a quick search through the source code confirms.
Labkey is linking the library directly as is this example:
   http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/doc/BasicDataSourceExample.java?view=markup

I'd say it should be possible to generalise access to the DataSource by using the factory definition in the config-file if it is defined. The linked example does seem to hint at it but doesn't provide a solution.

Next step is to figure out how this is done. But that will be a task for tomorrow, or perhaps you (adamr) have some ideas about that already.

Thanks for your help so far,

-Aschwin

ps. In case you are interested, I attached the log file as well.

Aschwin,

When installing LabKey Server on linux, we recommend NOT using the Tomcat server installed with the Linux distribution, but to download Tomcat from the Apache Tomcat site. We decided to do this to ensure we used the same Tomcat distribution across all platforms (Solaris, Windows, Linux(Debian, Fedora, etc), etc). This decision, simplified our testing and allowed us to release a single binary release.

My recommendation is to remove the Tomcat packages installed with your distribution and follow installation instructions for tomcat located at

- See the section titled "Install the Apache Tomcat Web Server, version 5.5.x"
https://www.labkey.org/wiki/home/Documentation/page.view?name=installComponents

- Also there is a step by step example of installing the LabKey Server on linux at
https://www.labkey.org/wiki/home/Documentation/page.view?name=installCpasLinux
(Eventhough, this is for installing on a Fedora distribution, the section titled "Install the Tomcat Server" should still be relevant for the Debian distribution.

Longer term, we are interested in eliminating LabKey's assumption about the Tomcat connection pool and BasicDataSource; we would like to run against the standard Debian install and other connection pool setups. Our use of BasicDataSource is very limited, but important. On first startup we create the DataSource if it doesn't already exist. The DataSource interface does not provide access to key properties we need to create a new database -- namely: driver class, url, user id, and password -- hence our casting to BasicDataSource. We deliberately avoid using the connection pool until after verifying the DataSources because we don't want invalid connections ending up in the pool. After verifying we can connect we only use standard connection mechanisms.

We are open to any patches or suggestions that will make us more generic while maintaining the ability to bootstrap (automatically create the database) transparently. A couple directions we could try:

- Use reflection to pull the properties we need. Should work as long as all implementations expose the properties using the standard getters.
- Detect other DataSource implementations and simply do a generic connect for non-BasicDataSource. This means we would bootstrap only if the Tomcat connection pool is used but others would work as long as the database was created manually.

Adam

I compiled Labkey (without using InteliJ) and was really impressed. I had to install subversion to get rid of some warnings, and the 'ant-optional' package to provide ant-junit.jar, but the build completely successfully after this. When I last tried this about a year ago I had loads of trouble getting it to compile in the first place. In other words, you have done a wonderful job getting this working more smoothly on Linux (Debian).

As it was the easiest to just change the references to the right DataSource class for my installation, I did that first. I've attached the patch for it in case anybody is interested in it.

As I now have a working setup, I am not sure if I will have time to help generalise use of the dbcp library. But I do hope I will find some time to work on that too though.

Thanks for your support,

Aschwin

In the 8.2 release, we removed references to Tomcat-specific DataSource and DelegatingConnection implementation classes, using reflection instead. Aschwin verified that this approach works on his Debian system. More details here: https://www.labkey.org/issues/home/Developer/issues/details.view?issueId=5762