Re: Starting DSpace: Tomcat can't start DSpace
hurray! Finally I got it. You were right with the assumption of the
dspace tables. After removing them by 'dropdb -U dspace dspace' I got an
successful build with ant. Many thanks to Your detailed help!
Now I will contribute to the Wiki and then going further with the
configuration of DSpace.
Christian Voelker schrieb:
> Am 31.10.2007 um 17:07 schrieb Robert Roggenbuck:
>>> Then, the unix
>>> user under which tomcat runs will write into your dspace
>>> directory. It is obvious with the assetstore subdirectory,
>>> but is also true e.g. with the history subdirectory and
>>> others. Once running, you will see by file-dates which
>>> are written during operation. The short solution is that
>>> you run your ant tasks under the unix user which is
>>> tomcat-55 in your case. For consistency, I would make
>>> it a habit, but it is actually required only during the
>> You really mean I should say
>> $sudo -u tomcat55 ant fresh_install
>> instead of
>> $sudo -u dspace ant fresh_install
> Yes, I would probably do so.
>> If this is true, the Wiki page should be corrected at this point. There
>> it is said to execute
>> $sudo chown dspace /var/lib/tomcat5/webapps/*.war
>> This makes no sense if the change of ownership is gone after the
>> unpacking of the *.war files. But if I understand it right the setting
>> of 'TOMCAT5_USER=dspace' in /etc/default/tomcat5.5 prevent this change...
> No, the wiki page just chooses the opposite solution. They
> change the setting mentioned (I did not know this option)
> and then go on using the user dspace. From my point of view,
> they pay twice, but it is consistent within the scheme and
> an absolutely valid solution; you have to choose one of them,
> then follow the track consistently. As the wiki page is more
> elaborate, I would suggest, you follow the wiki.
>> [java] 2007-10-31 16:46:06,811 INFO
>> org.dspace.storage.rdbms.InitializeDatabase <at> Initializing Database
>> BUILD FAILED
>> /opt/dspace-1.4.2-source/build.xml:333: Java returned: 1
>> Total time: 14 seconds
>> As far as I see, according to the line 333 in build.xml, it fails on
>> looking up the class org.dspace.administer.RegistryLoader . Is there a
>> connection to the warnings in the beginning, the notes from javac? Could
>> it be that my CLASSPATH setting is wrong?
> No, I dont think (but might be mistaken as well). I would stick
> with the very last error encountered and hope that everything
> runs smoothly the next time I try if I am capable to solve this
> particular issue. What I wonder about is, that the build only
> complains during the load_registries target but not yet at the
> setup_database target. Did you remove the database before this
> attempt? I mean not uninstall postgres but drop the dspace db
> and preparing the very same situation that was there before
> the first install?
> fresh_install expects the user dspace to exist in the db and
> the db to be accessible by this user and the password confi-
> gured in the config file. It then sets up all tables required
> and finally fills them with some basic data called the regis-
> tries. If the database already contained all tables required,
> then I would expect the target setup_database to fail already.
> No matter what, it is clear that the registry-data was in your
> database already which made the load_registries target fail.
> It may be annoying, to start over once again but I feel you
> are pretty close to success. Just leave it for today and give
> it another try tomorrow.
> Bye, Christian
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/