Initial Author's note: There are a lot of tidbits scattered around the documentation, but I'm finding it difficult to find all the places to configure things so that manifold will run on my development desktop (where the DB get's used for lots of things, and it can't have the whole thing, and I want it to play in the user/schema I define). I'm going to collect some of the scattered bits I have found and hope that someone else who actually knows where the all the handles are can edit this and make it authoritative. Until then, UAYOR/YMMV.
Database Connection Properties
Properties are set in the xml properties file that configures manifold.
The following properties are used to create a database instance in the Quick-Start and Multiprocess examples, and thus must have database super-user abilities:
<property name="org.apache.manifoldcf.dbsuperusername" value="postgres"/> <property name="org.apache.manifoldcf.dbsuperuserpassword" value="*******"/>
These properties are not used anywhere else; if you are using commands to initialize the database you would supply similar credentials to the DBCreate command.
Actual access to an already-created instance uses the following properties:
<property name="org.apache.manifoldcf.database.username" value="myuser"/> <property name="org.apache.manifoldcf.database.password" value="secret"/> <property name="org.apache.manifoldcf.database.name" value="dbname"/>
When the database instance is created through whatever means described above, the values in the second set of properties are what are used to initialize the user meant to access the instance.
To use PostgreSQL you will need to set the following property
<property name="org.apache.manifoldcf.databaseimplementationclass" value="org.apache.manifoldcf.core.database.DBInterfacePostgreSQL"/>
If you create the database and user ahead of time and set the user as the database owner, then you can use the same user for dbsuperusername with no additional privileges.
<property name="org.apache.manifoldcf.databaseimplementationclass" value="org.apache.manifoldcf.core.database.DBInterfaceDerby"/>
The recommended way to create the database is to run start.jar. There is no separate script. Since start.jar requires jetty, several other properties are required:
<property name="org.apache.manifoldcf.crawleruiwarpath" value="../web/war/mcf-crawler-ui.war"/> <property name="org.apache.manifoldcf.authorityservicewarpath" value="../web/war/mcf-authority-service.war"/> <property name="org.apache.manifoldcf.apiservicewarpath" value="../web/war/mcf-api-service.war"/> <property name="org.apache.manifoldcf.usejettyparentclassloader" value="true"/> <property name="org.apache.manifoldcf.jettyport" value="8345"/>
These are not required for your final deployment if you are not running on jetty, so in that case you probably want to create a separate copy of your properties file and add them to that replacing the properties.xml in the examples directory.
$ java -jar start.jar Configuration file successfully read Successfully unregistered all output connectors Successfully unregistered all authority connectors Successfully unregistered all repository connectors Starting jetty... 2012-05-03 19:54:02.547:INFO::Logging to STDERR via org.mortbay.log.StdErrLog 2012-05-03 19:54:02.591:INFO::jetty-6.1.26 2012-05-03 19:54:02.797:INFO::Started SocketConnector@0.0.0.0:8345 Jetty started. Starting crawler... ^C
Other DB Related Notes
Not sure if I've missed something in setting things up, or this is a side effect of not having created the db properly yet, but possibly there's a connection closing issue (based on this log trace). If I find that a missing/outdated jar is to blame, I'll put it here. If it's still around when I get everything else working I'll log an issue (if it doesn't already exist).
INFO: Stopping ProtocolHandler ["http-bio-8088"] May 03, 2012 7:02:29 PM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler ["ajp-bio-8018"] May 03, 2012 7:02:29 PM org.apache.coyote.AbstractProtocol destroy INFO: Destroying ProtocolHandler ["http-bio-8088"] May 03, 2012 7:02:29 PM org.apache.coyote.AbstractProtocol destroy INFO: Destroying ProtocolHandler ["ajp-bio-8018"] Exception in thread "Database connection release thread" java.lang.NoClassDefFoundError: org/apache/manifoldcf/core/database/ConnectionFactory$ConnectionCloseThread at org.apache.manifoldcf.core.database.ConnectionFactory$PoolManager.releaseAll(ConnectionFactory.java:267) at org.apache.manifoldcf.core.database.ConnectionFactory.releaseAll(ConnectionFactory.java:130) at org.apache.manifoldcf.core.system.ManifoldCF$DatabaseConnectionReleaseThread.run(ManifoldCF.java:1342) Caused by: java.lang.ClassNotFoundException: org.apache.manifoldcf.core.database.ConnectionFactory$ConnectionCloseThread at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1533) ... 3 more
What I wish I could find in the docs is the location of an SQL script to run to create the database, and a property to set the name of the database, so I can install it into the database of my choice (with a name of my choosing). I'd really rather not let code I can't see loose on my db with super-user privileges.
You can set the database name also via a parameter. If you create your own user with privs for table creation in the database you want it to use, then running the Initialize, Register, and RegisterConnector/RegisterAuthority/RegisterOutput commands will do the appropriate database and index creation for you.
We in general discourage the idea that you can set up a schema through a SQL script, because individual connectors (which can be registered or deregistered) also own database tables, which they need to create and destroy accordingly.
Thx for the quick reply found the property for db name, and added it above. Seems that in the future folks will likely want control over tablespaces, which partition various tables are on and things like that (I'm not a db guru, but it's due to hearing things like that from the DBA's I've come to expect/produce scripts). I'll give it a whirl with the user I defined and see what privs I need to give it (if any) and note that above.
The exception you included is harmless; it's a bit amusing too because it results from the fact that Tomcat is unloading a class before it has invoked the shutdown hook for the web application (which shuts down the thread that's still running when the webapp is unloaded).
If you create a ticket for the problem please include what version of Tomcat this is.
Ah, yet another tomcat shutdown quirk... FWIW this was tomcat 7.0.23