jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Hendriks <marti...@gx.nl>
Subject RE: Jackrabbit fails to start if database user is not schema owner
Date Thu, 12 Mar 2009 13:40:43 GMT
The tables already existed. The testcase is this:
* Start Jackrabbit the regular way which you describe (Jackrabbit autocreates the tables).
* Stop Jackrabbit
* Change the user credentials in the repository.xml to those of a user with only data manipulation
rights.
* Start Jackrabbit again -> this does not work.

The check whether the tables exist in the checkSchema method in this case finds that the schema
does not yet exist and it tries to create it which fails.

Best regards,
Martijn

> -----Original Message-----
> From: Alexander Klimetschek [mailto:aklimets@day.com]
> Sent: Thursday, March 12, 2009 2:30 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: Jackrabbit fails to start if database user is not schema
> owner
> 
> On Thu, Mar 12, 2009 at 2:23 PM, Martijn Hendriks <martijnh@gx.nl>
> wrote:
> > Hi,
> >
> > One of our customers has strict rules for DB access: the application
> can only do data manipulation, which means that the database user
> configured in Jackrabbit's repository.xml is not the schema owner. Of
> course, Jackrabbit can then only start if the schema is already present
> in the DB. The DatabaseFileSystem.checkSchema method, however, fails to
> detect that situation:
> >
> > Mar 3, 2009 4:00:53 PM
> org.apache.jackrabbit.core.fs.db.DatabaseFileSystem init
> > SEVERE: failed to initialize file system
> > java.sql.SQLException: CREATE TABLE permission denied in database
> 'wm98nute'.
> >        at
> net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.jav
> a:368)
> >        at
> net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2816)
> >        at
> net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2254)
> >        at
> net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:631)
> >        at
> net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.ja
> va:584)
> >        at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:5
> 46)
> >        at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeImpl(JtdsStatement.java:
> 723)
> >        at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.jav
> a:1163)
> >        at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeUpdate(JtdsStatement.jav
> a:1116)
> >        at
> org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.checkSchema(Databas
> eFileSystem.java:1169)
> >        at
> org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSy
> stem.java:184)
> >        at
> org.apache.jackrabbit.core.config.FileSystemConfig.createFileSystem(Fil
> eSystemConfig.java:47)
> >        at
> org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:24
> 4)
> >        at
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:55
> 7)
> >
> > This is a stacktrace for an MSSQL DB, but I guess that the problem
> exists elsewhere too (at least on Oracle). In order to fix this it
> seems necessary to fix all "checkSchema" methods (DB file systems,
> (bundle) persistence managers, db datastore, db journal). Wat do you
> think?
> 
> In this case you have to manually create the tables beforehand and
> give the Jackrabbit user access rights to them. The checkSchema()
> method simply looks if the required table is present, and if not
> (which is the case above), tries to create the table using the
> appropriate .ddl file from the jar resources.
> 
> Jackrabbit works this way as it is in most cases simpler if the tables
> are auto-created and because of the dynamic aspect of workspace
> creation, which triggers the creation of an according database table
> if database file systems or persistence managers are used.
> 
> Regards,
> Alex
> 
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

Mime
View raw message