Hello, 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 >> fresh-install. > 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. > setup_database: > [java] 2007-10-31 16:46:06,811 INFO > org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database > > load_registries: > > 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/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
