The Server Administration link lets you perform various tasks relating to administration of the overall portal server, as opposed to administering re- sources in the portal. Clicking the link makes this abundantly clear: you're immediately presented with a graph showing the resources available in the JVM.
Resources
The first tab is called Resources . This tab contains the aforementioned graph plus several server wide actions that an administrator can execute. These are:
Garbage collection: You can send in a request to the JVM to begin the
garbage collection task.
Clearing VM caches: You can send in a request to the JVM to clear a
single VM cache.
Clearing caches across the cluster: You can send in a request to the
JVM to clear content cached across the entire cluster.
Clearing database caches: You can send in a request to the JVM to clear
the database cache.
Reindex all search indexes: You can send in a request to regenerate all
search indexes. If you are not using a Solr search server (see Chapter 7 for further information). This will impact portal performance, so try not to do this except at non-peak times.
Generate Thread Dump: If you are performance testing, you can gener-
ate a thread dump which can be examined later to determine if there are any deadlocks and where they might be.
Verify database tables of all plugins: Checks all tables against their in-
dexes for accuracy of data retrieval.
Log Levels
Here you can dynamically modify the log levels for any class hierarchy in the portal. If you have custom code that you have deployed which isn't in the list, you can use the Add Category tab to add it. If you change the log level near the top of the class hierarchy (such as at com.liferay), all the classes under
that hierarchy will have their log levels changed. If you are testing something specific, it is much better to be as specific as you can when you change log levels. Modifying them too high in the hierarchy generates a lot more log messages than you need.
Properties
Liferay and the JVM contain many settings which are defined as proper- ties. There are two tabs here: one showing system properties and one show- ing portal properties.
The system properties tab shows an exhaustive list of system properties for the JVM, as well as many Liferay system properties. This information can be used for debugging purposes or to check the configuration of the cur- rently running portal.
The portal properties tab tab shows an exhaustive list of the portal prop- erties. These properties can be customized, as will be seen in the next chapter. If you need to check the current value of a particular property, it can be viewed from this screen without having to shut down the portal or open any properties files.
Captcha
By default, Liferay ships with its own simple captcha service which is de- signed to thwart bots from registering for accounts on sites powered by Liferay. If you want to instead use Google's reCaptcha service, you can do that.
Simply check the Enable ReCaptcha box and enter your public and private keys into the text fields provided, and then click Save. Liferay Portal will then use reCaptcha instead of simple captcha.
Data Migration
If you are upgrading from a previous release of Liferay Portal or if you need to migrate your data from one system to another, this section helps you to do that without your developers having to write custom scripts.
The first section lets you copy your entire Liferay database from the cur- rent database under which it is running to the database you specify in this set of fields. You'll need to enter the driver class name (and the driver will need to be on Liferay's classpath), the JDBC URL of the database to which you'll be copying your data, and a user name and password that has access to that database. Once you have all of this information entered, click Execute to copy the data.
The next section helps you migrate your documents. If you want to move off of the Jackrabbit JSR-170 repository to the file system, or to the Jackrabbit repository from the file system, or to any of the other repositories supported by the document library, you can do this very easily. Make sure you have already set up your portal-ext.properties file so that the hook is properly
that represents where you want your documents migrated, and click Execute. Your documents will be migrated to the new repository, and you can then shut down Liferay, make the new repository the default in the portal-ext.- properties file, and then restart.
Similarly, you can migrate images from the Image Gallery in the same manner.
File Uploads
Since Liferay allows users to upload files in various places, you may want to lock down the type of files and the size of files users are allowed to upload. Here, you can set the overall maximum file size and then override that size for specific applications within Liferay. You can limit the allowed file exten- sions generally or by application. You have a lot of flexibility as to how you want files to be managed within your portal.
Rather than using the portal-ext.properties file as we did in the in-
stallation chapter, you can configure a mail server here. If the portal is to re- ceive mail (see the Message Boards portlet in Chapter 5), you can connect a POP mail server. And of course, if the portal is to send mail—which it needs to do in order to send notifications to users—you can connect an SMTP server here as well, and this is highly recommended.
Note that if you add your mail server settings here, they will override anything that is in your portal-ext.properties file.
OpenOffice
Liferay Portal enables users to add content in many formats: web con- tent, images, and files. This is done using the Web Content Management Sys- tem, the Image Gallery, the Document Library, and in other portlets, both built-in and custom written. Sometimes, it is helpful to convert this content from whatever format it is in to a format that is more convenient for the user browsing the content. Liferay Portal allows users to do this by integrating with OpenOffice.org.
OpenOffice.org is an open source office suite which is normally run in graphical mode to create documents, but it can be run in “server” mode. When run in server mode, OpenOffice.org can be used to convert documents to and from all of the file types it supports. Liferay can then make use of this feature to automatically convert content on the fly.
Use this tab to tell Liferay how to connect to your running instance of OpenOffice.org. You can install OpenOffice.org on the same server upon
which Liferay is running. Once you have it installed, you can start OpenOffice.org in server mode with the following command:
soffice -headless -accept="socket,host=127.0.0.1,port=8100;urp;" -nofirststartwizard
As you can see, the command above specifies that OpenOffice.org will run on port 8100, which is the default port in the Control Panel . If you can use this port, all you need to do is check the Enabled box, and Liferay will be integrated with OpenOffice.org.
If you have something else running on this port, find a port that is open and specify it both in the command above and on the Control Panel's OpenOffice.org con figuration page. When you are finished, click Save.
Script
Liferay includes a scripting console which lets administrators execute migration or management code instantly. Several scripting languages are supported, including JavaScript, Groovy, Python, Ruby, and Beanshell. For further information about Liferay's APIs, see the JavaDoc, the Liferay Wiki (http:// wiki .liferay.com), or Liferay in Action.
Shutdown
If you ever need to shut down your Liferay Portal server while users are logged in, you can use the Shutdown tab to inform your logged-in users of the impending shutdown. You can define the number of minutes until the shutdown and a custom message that will be displayed.
Users will see your message at the top of their portal pages for the dura- tion of time you specified. When the time expires, all portal pages will display a message saying the portal has been shut down. At this point, the server will need to be restarted to restore access.