WARNING: you are not looking at the live version but at a more recent version.

xReporter v1.2.1

xReporter 1.2.2 is not yet released.

This document describes how to install xReporter and get it up and running.

The installation involves these steps

download & extract the xreporter package
install the Java 1.4 SDK
install Avalon Phoenix (= simply extracting a downloaded package)
create an xReporter configuration directory and customise it
install Tomcat and Cocoon, and adjust their configuration
deploy the created configuration on the Phoenix and Cocoon installation.

Although the installation instructions may seem long, they are quite straightforward. The installation is currently quite "manual", but that has the advantage that you'll have a good understanding of what's going on.

Since xReporter is all about database reporting, it is assumed that you already have some database system running, and that you know how to create databases and tables on that system. You should also have a JDBC driver for this database system (unless it is MySQL, whose driver is included with xReporter) and have some documentation on it, like what the format of the connection URL is. Furthermore you should feel comfortable with installing Java applications and editing XML files.

Obtaining the xReporter codebase

provide decent download links when version is available.

Download an xReporter distribution:

xreporter-1_2_1.zip (Windows)
xreporter-1_2_1.tgz (Unix)

After downloading this file, extract it. This will create three directories: xreporter, xreporter-cocoon and testconf. In the remainder of this documentation, we'll refer to these directories as /home/jef/xreporter, /h ome/jef/xreporter-cocoon, /home/jef/testconf (jef will be our imaginary user).

Alternatively, you can retrieve the latest xReporter code by either using (read-only) SVN or downloading a nightly prepared tarball, see here for instructions.

xReporter installation

xReporter requires Java 1.4. If that's not installed yet on your system, do it now (in Sun terminology: you should install the J2SE SDK, not the JRE). Check that it really is version 1.4 (or higher) by typing "java -version" at a command prompt. Also check that the environment variable JAVA_HOME is set correctly.

xReporter runs inside Avalon Phoenix. Download version 4.0.4 from here (xReporter has been tested and is compatible with versions 4.0.1 and up). Unzip or untar the downloaded file. This will create a directory called "phoenix-4.0.4". From now on we will refer to this directory as /home/jef/phoenix.

If you intend to run your Phoenix container in a 1.4 VM, you're finished with the Phoenix install. If, however, you need to run Java 1.5... you have a little more work to do (thanks to Jan Hoskens for reporting this issue to the xReporter community and to Simon Goldsmith for providing the patch to the LOOM community):

1. Download the patch provided by Simon Goldsmith from here
2. Unpack its contents to /home/jef/phoenix/bin (replacing both phoenix-loader.jar and lib/phoenix-engine.jar)
3. Download updated mx4j libraries from here (tested with 3.0.1)
4. Extract mx4j-3.0.1/lib/*.jar to /home/jef/phoenix/bin/lib (replacing the existing mx4j libraries and adding some new ones in the same location)
5. Set a PHOENIX_JVM_OPTS environment variable causing the JVM with a javax.management.builder.initial property

Windows:
set PHOENIX_JVM_OPTS="-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder"

Unix:
export PHOENIX_JVM_OPTS="-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder"

And that oughtta do it.

Now add the bin directories of xreporter and xreporter-cocoon to your PATH (it is not required to do this, you can also enter absolute references to the scripts in there):

For Windows: set PATH=%PATH%;c:\home\jef\xreporter\bin;c:\home\jef\xreporter-cocoon\bin
For Unix: export PATH=$PATH:/home/jef/xreporter/bin:/home/jef/xreporter-cocoon/bin

The remainder of the xReporter installation depends on what you would like to do. You can either:

start with a new configuration: choose this if you want to start using xReporter to create reports on you own data.
use the testdata and testreports: choose this if you'd like to try out the test reports of xReporter. For this option it is highly recommended that you have a MySQL database running, since all the scripts to upload the data are sp ecific to MySQL.

This isn't a permanent choice of course: you can always come back later and make a second configuration.

Start with a new configuration

If you'd like to try out the test reports, then skip this section entirely.

We'll start with creating some administrative tables. These tables will contain things like users and access rights.

Create some database for this purpose (our standard name for this is xreporteradmin), and then execute the dbschema-create script in {XREPORTER_HOME}/src/resources/schema/dbschema/xreporteradmin_create.mysql

$ cd $XREPORTER_HOME
$ mysql -uroot -pYourSecretPassword -Dxreporteradmin
mysql > \. src/resources/schema/dbschema/xreporteradmin_create.mysql

(or the equivalent of that if you're not running on mysql)

In this schema you will need to introduce various administrative records like this:

insert into users values('jef', 'bigsecret')
insert into customers values('jef','jeftechnologies')
insert into roles values('jef', 'chief')
insert into authcodes values('jef', 'sample-auth-code')
insert into accesscontrol values('firstreport', 'chief')

What we basically did with the insert statements is create a user called jef who has the password bigsecret and the role chief and belongs to a company identified by "jeftechnologies". We assigned the data source authorisation code sample-auth-code to jef (this code will determine to what data sources jef has access). We also gave all users having the role of chief the right to access the report with id firstreport.

Ideally, the tables that xReporter modifies (userentrystore, reportstore, reportstore_detail) should be located on a database supporting transactions. For example, the reportstore and reportstore_detail tables are used for storing report instances. One report instance will require mulitple inserts on these tables, which should be considered as one atomic operation. It could also be that a report is being read (= multiple selects) while it is being removed by another request (since these reports are associated with one user, chances are pretty low, but still...).

Now we are going to create the configuration files for xReporter.

First, create some directory where you'd like to store the configuration files. This directory should be empty. In the rest of the explanation, we'll take as example /home/jef/xreporterdata.

Go to this newly created directory (/home/jef/xreporterdata), and enter the following command:

xreporter seed

This will create some files and directories within the directory /home/jef/xreporterdata. (it will also trigger a compile of the source code but ignore that for now).

Now open the file /home/jef/xreporterdata/sarconf/config.xml in your favourite text editor. Search for a part that looks like this:

<connection-params>
  <url>jdbc:mysql://localhost/xreporteradmin</url>
  <user>xreporteradmin</user>
  <password>xreporteradmin</password>
</connection-params>

This actually occurs four times in that file. Change both occurrences with the correct parameters to connect to the database in which you created the tables earlier. Don't forget: you should do all this four times. Then save this file.

If you are not using MySQL but some other database, you'll have to put the JDBC driver for that database somewhere. A good location would be /home/jef/xreporterdata/lib. Then edit the config.xml file again, and look for the element <drivers-to-load>. Within that element, insert a tag like this (with the correct values in the class and location attributes of course):

<driver class="mydb.Driver" location="@conf.home@/lib/mydb.jar"/>

Note how we used @conf.home@ in the location attribute. This will be substituted at deployment-time with the actual location of the configuration directory (in our example thus /home/jef/xreporterdata). This makes it easy to move configuration directories to other locations, i.e. for deployment on other systems.

Now we're going to create a first, simple report, but before that we'll configure the datasource for that report. For this, open the file /home/ jef/xreporterdata/conf/datasources.xml. There you'll see again a < connection-params> element. Edit its content to point to some database on which you'd like to create a report. If this database would need a different JDBC driver, then add that one also to the same config.xml as above.

Now open the file /home/jef/xreporterdata/reports/firstreport.xml. This file is what is called a "report definition". Look for the following element and change the select statement to something that makes sense for your data:

<literal>select field1, field2 from mytable</literal>

Also, change the <column> elements in that file (and add new ones as necessary) for each field that you want to retrieve from the result set.

At this time, don't change any of the other items, especially not the id attribute (or if you do so, insert an extra record in the accesscontrol table) or the required-datasource-type (or if you do so, also update the 'supported-types' in the datasources.xml file).

Now skip the next section and continue with the section "Phoenix deployment" .

Configuration using the testdata and testreports

When extracting the xreporter download, a directory /home/jef/testconf was created. That directory contains an xReporter test configuration with some sample reports. The only thing we need to do to get this working is upload the testdata in a database, and possibly adjust some database connection parameters (if your server is not running on localhost or you are using different users than the ones we used -- but we'll get to that later).

We assume you will be using MySQL. The database-creation scripts will create three databases (one with administrative data like users and access rights, and two with demo-data). By default we use the following database users (but you can use any you like):

Database	Username	Password
xreporteradmin	xreporteradmin	xreporteradmin
presidents	xreporter	xreporter
variousdata	xreporter	xreporter

These users can be created as follows: first login to MySQL using the root user:

mysql -uroot -pYourSecretPassword

On some MySQL installations, the root user has no password, in that case drop the -p parameter.

Then grant the necessary access rights using the following commands: (this will automatically create the users)

GRANT ALL ON xreporteradmin.* TO xreporteradmin@"%" IDENTIFIED BY "xreporteradmin";
GRANT ALL ON xreporteradmin.* TO xreporteradmin@localhost IDENTIFIED BY "xreporteradmin";

GRANT ALL ON presidents.* TO xreporter@"%" IDENTIFIED BY "xreporter";
GRANT ALL ON presidents.* TO xreporter@localhost IDENTIFIED BY "xreporter";

GRANT ALL ON variousdata.* TO xreporter@"%" IDENTIFIED BY "xreporter";
GRANT ALL ON variousdata.* TO xreporter@localhost IDENTIFIED BY "xreporter";

The localhost entries are necessary because otherwise the default access rights for anonymous users @localhost will take precedence. Then flush the privileges by executing the following command (at the operating system command prompt, not inside the MySQL client):

mysqladmin -uroot -pYourSecretPassword flush-privileges

Now we will first create the necessary databases. Open a command prompt and go to the directory /home/jef/xreporter. Then issue the following command:

xreporter fixtestdata

This will make sure that the datafiles use Unix line endings, which is required by MySQL (even on Windows). Next go to the directory /home/jef/xreporter/src/testcases/data, and start the MySQL client as usual w ith:

mysql -uroot -pYourSecretPassword

Enter the following commands in the MySQL client:

\. createPresidentsDatabase.mysql
\. createVariousData.mysql
\. createXRepAdminDatabase.mysql

The first two scripts start with trying to drop previously created databases, the third one does not out of precaution. Drop that one manually if you're sure about what you are doing. But on first-time install non of the previous applies of course.

During this action the following error might occur: "ERROR 1148: The used command is not allowed with this MySQL version ". This is because load local is disabled by default as a security measure. To allow this command start the MySQL client with the --local-infile option and all should be well.

The scripts executed above should have created three databases: "presidents" , "variousdata" and "xreporteradmin". You could verify now that you can actually access the tables by doing a testquery:

mysql -Dpresidents -uxreporter -pxreporter
(inside MySQL client)
select * from president;
(this should show some data)

Now edit the file /home/jef/testconf/sarconf/config.xml and look for this part (which occurs four times):

<connection-params>
  <url>jdbc:mysql://localhost/xreporteradmin</url>
  <user>xreporteradmin</user>
  <password>xreporteradmin</password>
</connection-params>

If necessary, adjust the url, user and password (if you're running MySQL on the same machine as xReporter and you used the default users created above, you don't need to change anything). You need to do this four times in this file.

Now do the same in the file /home/jef/testconf/conf/datasources.xml, where you need to adjust the following two connection-params elements (again not necessary if blah blah...):

<connection-params>
  <url>jdbc:mysql://localhost/presidents</url>
  <user>xreporter</user>
  <password>xreporter</password>
</connection-params>
  
<connection-params>
  <url>jdbc:mysql://localhost/variousdata</url>
  <user>xreporter</user>
  <password>xreporter</password>
</connection-params>

Now continue with the section "Phoenix deployment". If you see the path /home/jef/xreporterdata mentioned, then substitute that for /home/jef/testconf.

Phoenix deployment (applies to both the new configuration and the testdata configuration)

Now everything should be configured. The next step is to deploy xReporter onto Phoenix. This involves building a file called "xreporter.sar" and copying into Phoenix's apps subdirectory, but all of this is hidden by the deploy script. Go to the directory /home/jef/xreporterdata (or /home/jef/testconf if you're using the testdata). There you'll find a file called build.properties.sample. Copy that file to build.properties, and edit the value of the phoenix.home property.

In property files, backslashes ("\") have a special meaning. To insert a normal backslash, you need to enter it twice ("\\"). So on Windows, a path could look like c:\\programs\\xreporter.

Now you can deploy xReporter simply by executing the following command (still in the directory /home/jef/xreporterdata):

xreporter deploy

A little bit of background information: each time you change one of the files in /home/jef/xreporterdata/sarconf, you will need to re-execute the above deploy command. If you change any of the other XML configuration files (those in the conf subdirectory) you do NOT need to redeploy, but you do need to restart Phoenix. But more on all this in the deploy document.

Now you may start Phoenix. Open a command prompt and go to the directory /home/jef/phoenix/bin and enter "./run.sh" or "run.bat". After a few seconds you should see this message: xReporter HTTP server started.

Note that the xReporter HTTP server listens on port 8888, if that is a problem on your system, you can change it to something else in the config.xml (and remember, after changing that file execute "xreporter deploy" again).

To be able to access xReporter from your web browser, continue with the section titled "Tomcat/Cocoon installation".

If you encountered problems so far, do not hesitate to subscribe to the xReporter mailing list and let us know about them.

Tomcat/Cocoon installation

xReporter's Cocoon-based presentation layer is not a stand-alone web application, but a set of Cocoon components (Java classes), a sub-sitemap, XSL's and other resources which can be reused for building your own web application. We made a default configuration however, that you can deploy on a default Cocoon 2.1 distribution.

Prerequisites:

A working copy of Tomcat 4.1 (running on Java 1.4)
A working copy of Cocoon 2.1 installed on this Tomcat. You should be able to surf to http://localhost:8080/cocoon (or equivalent) and see the welcome page of Cocoon.

In case you don't know how to install this: here are the "short" installation instructions, which should normally lead to immediate success:

Download Tomcat 4.1.x by following the links from here (take the most recent stable version, and take the one with LE-jdk14 in the name). Then extract this file. Try that tomcat works by going to its bin subdirectory and executing the startup.sh script (for Unix) or startup.bat (for Windows) (and wait a few seconds to give it the time to start up). Now open a browser window and surf to http://localhost:8080. This should show a default Tomcat page. You can now stop Tomcat, by executing the shutdown.sh script (for Unix) or the shutdown.bat script (for Windows).
Download Cocoon 2.1 from here. Extract the downloaded file, this will create a directory which we'll call "cocoondist" from here on. To tailor the build to your needs (read: make it faster) you should copy the block.properties to local.block.properties and exclude all blocks you don't need. (or use this sample local.build.properties (application/binary, 6.7 kB, info) which builds a Cocoon with only those blocks required by xReporter) Execute "build" in the cocoondist directory. After the build has finished, copy the directory cocoondist/build/webapp to jakarta-tomcat-4.1.x-LE-jdk14/webapps/ . Rename the "webapp" directory to " cocoon", so that you get jakarta-tomcat-4.1.x-LE-jdk14/webapps/cocoon.
Copy the files in cocoondist/lib/endorsed to jakarat-tomcat/common/endorsed
Now start Tomcat again as done in the first step.
Surf to http://localhost:8080/cocoon, this should show Cocoon's welcome page (this can take a while the first time).
That's it, you can now shutdown Tomcat again for now.

Tomcat configuration

As briefly explained above xReporter knows about users, and their access to datasources and reports, and xReporter will perform the required authorization on requests coming in. xReporter however does not do any authentication. That is left to the servlet container who will then transfer the authenticated user-id over to xReporter. Additionally the XReporterClient that performs that transfer can be setup to connect to the xReporter service with one fixed fall-back user-id for all not authenticated end-users. Most of the time, it is recommended to use authentication.

If you'd like to use authentication, then a "realm" needs to be configured at the level of the servlet container. (i.e. inside Tomcat's server.xml.) We assume here that the server.xml is still in its default configuration.

Look in the jakarta-tomcat/conf/server.xml for the element <Engine name=" standalone" [...] />. Put inside this element the following Realm element:

<Realm className="org.apache.catalina.realm.JDBCRealm"
  connectionName="xreporteradmin" connectionPassword="xreporteradmin"
  connectionURL="jdbc:mysql://localhost/xreporteradmin"
  driverName="org.gjt.mm.mysql.Driver"
  userTable="users" userNameCol="username" userCredCol="password"
  userRoleTable="roles" roleNameCol="role"/>

Change the values of the attributes of this realm element as necessary. You will likely need to change the connectionName, the connectionPassword and the connectionURL, and possibly the driverName. The users-table was created as part of the xReporter installation.

Check that there's no other Realm element active, otherwise authentication will not work! Normally there is a default one like this, which you should remove (or comment out):

<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
    debug="0" resourceName="UserDatabase"/>

To make the database driver available to Tomcat, put the driver jar in the directory jakarta-tomcat/server/lib. For MySQL you'll find it in /home/jef/xreporter/lib/core/mm.mysql-2.0.14-bin.jar.

Cocoon configuration

For form based authentication

The steps in this section are only required if you want the servlet container to authenticate your end-users. Do this if you also created the realm above.

The security constraints should be configured in Cocoon's web.xml, which can usually be found jakarta-tomcat/webapps/cocoon/WEB-INF/web.xml. Add the following in that file (before the close tag of the web-app element):

<security-constraint>
  <web-resource-collection>
    <web-resource-name>XReporter</web-resource-name>
    <url-pattern>/xreporter/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>*</role-name>
  </auth-constraint>
</security-constraint>

<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>XReporter protected area</realm-name>
  <form-login-config>
    <form-login-page>/xreporter-login</form-login-page>
    <form-error-page>/xreporter-loginfailed</form-error-page>
  </form-login-config>
</login-config>

The login and logout pages should be located outside the xReporter sitemap, since all resources contained therein are protected. Therefore, we'll add them to Cocoon's root sitemap. Edit the file jakarta-tomcat/webapps/cocoon/sitemap.xmap and add the following pipeline (as a child of the <map:pipelines> element, before the other < map:pipeline > elements):

<!-- xReporter login pipelines. These should be put outside the protected area, since the login
     pages themselves obviously should not be protected. -->
<map:pipeline>
  <map:match pattern="xreporter-login">
    <map:read
      src="xreporter/resources/skins/{xreporterdefaults:skin}/html/login.html"
      mime-type="text/html"/>
  </map:match>

  <map:match pattern="xreporter-loginfailed">
    <map:read
      src="xreporter/resources/skins/{xreporterdefaults:skin}/html/loginfailed.html"
      mime-type="text/html"/>
  </map:match>

  <!-- matcher to point to skin-specific images. Note that this circumvents the security,
       but for skin files this normally doesn't matter -->
  <map:match pattern="xreporter-login/images/*.gif">
    <map:read
      src="xreporter/resources/skins/{xreporterdefaults:skin}/images/{1}.gif"
      mime-type="image/gif"/>
  </map:match>

  <map:match pattern="xreporter-login/images/*.png">
    <map:read
      src="xreporter/resources/skins/{xreporterdefaults:skin}/images/{1}.png"
      mime-type="image/png"/>
  </map:match>

  <!-- matcher to point to skin-specific css files. Note that this circumvents the security,
       but for skin files this normally doesn't matter -->
  <map:match pattern="xreporter-login/css/*.css">
    <map:read
      src="xreporter/resources/skins/{xreporterdefaults:skin}/css/{1}.css"
      mime-type="text/css"/>
  </map:match>

  <!-- The logout matcher is also put outside the protected area, to prevent an
       endless login loop: suppose the authentication-session has expired, and then
       the user follows the logout link; this would then cause the login page to be
       shown, and after login the user would be redirected to the logout page, which
       would again cause the login page to be shown, etc -->
  <map:match pattern="xreporter-logout">
    <map:act type="session-invalidate"/>
    <map:act type="request">
      <map:parameter name="parameters" value="true"/>
      <map:redirect-to uri="{goto}"/>
    </map:act>
  </map:match>
</map:pipeline>

The session-invalidate action used in the logout is not declared by default, so add the following element within the <map:actions> element of the sitemap:

<map:action logger="sitemap.action"
    name="session-invalidate"
    src="org.apache.cocoon.acting.SessionInvalidatorAction"/>

For connecting to XReporter

Edit the file jakarta-tomcat/webapps/cocoon/WEB-INF/cocoon.xconf, and add the following element in there (as a child of the <cocoon> (= root) element, position shouldn't really matter -- add it e.g. at the bottom):

<component role="org.outerj.xreporter.client.XReporterClient"
    class="org.outerj.xreporter.client.XReporterClientImpl">
  <host>localhost</host>
  <port>8888</port>
  <user>jef</user>
</component>

The above declares the component that does the communication between Cocoon and xReporter. The host and port elements specify where the HTTP server of xReporter listens. Normally the defaults are OK, but adjust this if needed.

The <user> element specifies the user-id to connect to XReporter in case the servlet container did not authenticate one. So if you have set up the servlet-authentication for the whole xreporter request-space (as explained in the previous section), then the <user> element is not required and will serve no purpose. If you have chosen not to use servlet-authentication then the user you specify here will be the one performing all xreporter requests (and can thus not be ommitted)

Also in the cocoon.xconf, look for the element <input-modules> and add the following as child of that element (next to the other elements that are already there -- order does not matter):

<component-instance name="xreporterdefaults"  
   class="org.apache.cocoon.components.modules.input.DefaultsModule">
  <values>
    <skin>outerthought</skin>
  </values>
</component-instance>

The only thing left now is building and deploying the code and resources. Go to the directory /home/jef/xreporterdata, and edit the file build.properties (again). Now adjust the value of the property cocoon.home. Once that's done, you can deploy the xReporter presentation layer to Cocoon by executing the following command:

xreporter-cocoon deploy

Each time you execute the above command, the contents of the directory {cocoon.home}/xreporter will be erased.

Now start (or restart) Tomcat. Also check that you still have Phoenix running, or start it if necessary. Now open a browser and go to the following URL:

http://localhost:8080/cocoon/xreporter/en-US/datasources
or if you're speaking dutch:
http://localhost:8080/cocoon/xreporter/nl-BE/datasources

If everything went well you should now (dependent on your authentication choice)

In the case of servlet authentication ON:see a login page. Try to log in with user "jef" and password "bigsecret".In the case of NO servlet authentication immidiately get the list of available datasources.

Further tuning

By default, caching of compiled XSLT stylesheets is disabled in Cocoon 2.1. To improve performance, it's best to enable this (this can make a big difference, factor 2-3 times faster). To do this, edit the file jakarta-tomcat/webapps/cocoon/WEB-INF/cocoon.xconf, and look for the following part:

  <component class="org.apache.excalibur.xml.xslt.XSLTProcessorImpl"
         logger="core.xslt-processor"
         role="org.apache.excalibur.xml.xslt.XSLTProcessor/xalan">
     <parameter name="use-store" value="false"/>
     <parameter name="incremental-processing" value="false"/>
     <parameter name="transformer-factory"
            value="org.apache.xalan.processor.TransformerFactoryImpl"/>
  </component>

Change the value of the use-store parameter to true. You have to restart Cocoon (thus Tomcat) in order for this change to take effect.

Common problems...

Sympton: you followed the "start with a new configuration" installation. After logging in and selecting the data source, you get the page to select a report but no reports are shown.

Solution: there are multiple possible causes:

there is an error in the report definition file. Check the log file /home/jef/phoenix/apps/xreporter/logs/xreporter-{date}.log. You should see an error message there.
the report should be "compatible" with the datasource, i.e. the content of the tag <required-datasource-type> in the report definition should match the value of the supported-types/type tag in the datasources.xml file. (should be OK if you didn't touch those things)
the user has no access rights to any reports, for this (at least) one of the roles of the user must provide access to the report by inserting a record into the table "accesscontrol". (should be OK if you didn't change the id attribute on the report tag)

Sympton: when logging in on the web application, you always get the "login failed" page even though you're sure you entered the correct username and password.

Solution: this behaviour can occur if the Realm in Tomcat's server.xml is configured incorrectly. Double check that all parameters are correct.

Sympton: You get errors connecting to the database. You'd like to connect to your database without specifying a username and/or password.

Solution: in the datasources.xml and config.xml, remove the <password> and/or <user> tags completely from the connection parameters.

Sympton: if you experience one of the following:

exceptions when there are more than 50 rows in the resultset
a "java.lang.AbstractMethodError: COM.ibm.db2.jdbc.app.DB2Connection.prepareStatement(Ljava/lang /String;II)Ljava/sql/PreparedStatement;" when using DB2 (this error is logged in the "httpstack" log file)
possibly others... (reported to give problems with Informix and MS SQL as well, depending on the JDBC driver)

Solution: edit the file xreporterdata/sarconf/config.xml, and change the content of the element <resultset-navigation-strategy> to "looping" (without the quotes of course). After changing this, you'll need to redeploy to Phoenix (execute "xreporter deploy").

Authorisation problems: If after logging in you see no datasources or no reports and you can't find out what's wrong, you might want to lower the log level of the authorisation manager. This is done by editing the file /home/jef/xreporterdata/sarconf/environment.xml and look there for the following:

            <category name="authorisationmanager" log-level="INFO">
                <log-target id-ref="authorisation-target"/>
            </category>

Change the log-level attribute from INFO to DEBUG. After make this change you will need to redeploy to Phoenix (using the "xreporter deploy" command from your configuration directory), and restart xReporter. You should now see detailed information about authorisation in the log file /home/jef/phoenix/apps/xreporter/logs/authorisation-{date}.log.

Comments (1)