On tomcat -eclpse problem : followed step in email : The problem has been bugging me so I've been fiddling with Tomcat and Eclipse since I got home.. and learned quite a lot since. I believe it was Morris who said that breaking things can sometimes be good, eh ;-) Though I was not the one to delete those files, I think the reason was that they are different for everyone due to project setups, and they accidentally got committed once in a while. Which is very annoying when you update your code, and see your build suddenly broken. So they are now ignored from SVN, meaning you have to set it up once, and be done for life. Anyway, I found out that the really important files when it comes to developing with Tomcat via Eclipse are: .settings/org.eclipse.wst.common.component = Mapping of classpath source folders to /WEB-INF/classes, /WebContent to /, and imported projects (molgenis) to a generated JAR in /WEB-INF/lib .classpath = Also annotates which JARs (including those from imported projects) are to be exported in /WEB-INF/lib (next to the regular classpath source folders etc) And now the useful part, how to setup your Tomcat build just right: 1. Run the 'update-eclipse' function of your projects 'build_X.xml' Ant script (Run as -> Ant build... "update-eclipse" -> Run), this will setup your project classpath source folders. 2. Go 'Build Path -> Configure Build Path...' and 2.1 under Source: verify your source folders, e.g. modules / generated stuff / the app. 2.2 under Projects: import 'molgenis' here 2.3 under Libraries: import the minimal set of libraries here from both molgenis and molgenis_apps. (some are duplicate and Tomcat will not start up) As a suggestion you could start with the ones in this list: http://www.molgenis.org/svn/molgenis_apps/trunk/xqtl_jar.xml plus commons-lang-2.5.jar (required for Tomcat logger) Also make sure you have selected: Apache Tomcat vX.X, EAR Libraries, JRE System Library, Web App Libraries. 2.4 under Order and Export: Select All. Press OK and let it refresh / build etc. 3. Go again to 'Build Path -> Configure Build Path...', select Deployment Assembly. Here you should see 4 kinds of things going on: 3.1 All of your source folders (modules and apps) are mapped to WEB-INF/classes 3.2. /WebContent is mapped to / 3.3 All of the libraries you selected in your build path are mapped to WEB-INF/lib 3.4 The molgenis project is mapped to /WEB-INF/lib/molgenis.jar If not, fix it. Next: 4. Make your WEB-INF/web.xml like so: FrontController app.servlet.FrontController FrontController /* 5. Save, refresh, clean, build, and deploy on Tomcat. It should work. The thing I have not figured out yet is how to change the deployname when running directly from the molgenis_apps project. It seems you must use 'molgenis_apps' as your application URL. This works fine until you e.g. try out the R API, which uses your configured application name (e.g. animaldb, xqtl, lifelinescatalogue, etc) to call back, which will fail. Another tiny thing is that you must map to /* in web.xml, which means you cannot call the application with http://localhost:8080/molgenis_apps - you must add a trailing slash or Tomcat doesn't get it, like so: http://localhost:8080/molgenis_apps/ Sorry for the massive email, I hope it helps.. comments/questions always welcome :) have a nice weekend, Best regards, Joeri NEW error coming out : . {{{ javax.servlet.ServletException: Error instantiating servlet class app.servlet.FrontController org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) java.lang.Thread.run(Thread.java:680) }}} Giving up for today .... Trying to update from svn : problem with locked up dir!!! http://sherk.wordpress.com/2008/09/15/svn-error-on-eclipse-orgtigrissubversionjavahlclientexception-attempted-to-lock-an-already-locked-dir/