org.opencms.main

There are 3 main ways to access resources in an OpenCms System:

1. Using the {@link org.opencms.main.OpenCmsServlet}. This is the default usage of the OpenCms system.
2. Using the {@link org.opencms.main.CmsShell}. This is done for specific reasons, usually related to system configuration or setup.
3. Using the {@link org.opencms.main.OpenCms#initCmsObject(String)} from an application to obtain an initialized OpenCms user context.

@version $Revision: 1.10 $ @since 6.0.0 @see org.opencms.main.OpenCmsServlet @see org.opencms.main.CmsShell @see org.opencms.main.OpenCms

The OpenCms logging mechanism is based on Apache Commons Logging.

This is provided so that the user can see a full picuture of all the issues that have been caused in an operation, rather then only one (usually the first) issue.

This object is used to provide information about all authenticated users in the system with the org.opencms.main.CmsSessionManager .

This object is available for all authenticated users after login. If a user has not logged in, he may have a session on the servlet engine, but he will have no session info object attached.

For each authenticated OpenCms user, a org.opencms.main.CmsSessionInfo object holds the information about the users status.

When a user session is invalidated, the user info will be removed. This happens when a user log out, or when his session times out.

Please Note: The current implementation does not provide any permission checking, so all users can access the methods of this manager.

The CmsShell has direct access to all methods in the "command objects". Currently the following classes are used as command objects: org.opencms.main.CmsShellCommands , org.opencms.file.CmsRequestContext and org.opencms.file.CmsObject .

Only public methods in the command objects that use supported data types as parameters can be called from the shell.

Such additional commands can access OpenCms functions not available on "regular" OpenCms classes.

Regarding the naming conventions used, this comes straight from the Servlet Spec v2.4:

SRV.3.1 Introduction to the ServletContext Interface
[...] A ServletContext is rooted at a known path within a web server.

This thread executes all 60 seconds and checks if report threads are still active. A report thread usually waits for a user to get the contents written to the report. However, if the user does not request the reports content (e.g.

In order to receive system events, your class must register with the OpenCms event mechanism.

Request handlers are used for special requests to OpenCms that should NOT be mapped to a VFS resource. A request handler URI always start with /handle and then one or more possible handler names as defined with the I_CmsRequestHandler.getHandlerNames() method.

For example, if a registerd request handler has the name "MyName", any request (in a simple setup) to /opencms/opencms/handlerMyName... will directly be transfered to the I_CmsRequestHandler.handle(HttpServletRequest,HttpServletResponse,String) method of this handler.

In essence, the request handlers are like simplified mini-servlets that run inside OpenCms.

This Object provides singleton access to the initialized OpenCms runtime system. Some methods are for internal or advanced use only, but others are of also of interest for general OpenCms development.

For example, to generate a new instance of org.opencms.file.CmsObject class in your application, use org.opencms.main.OpenCms.initCmsObject(String) .

All access to this class must be done through the public static methods of the org.opencms.main.OpenCms object. Under no circumstances should you ever try to access this class directly.

This class is so OpenCms internal you should not even be reading this documentation ;-)

Any request to the org.opencms.main.OpenCmsServlet will be forwarded to this core class. The core will then try to map the request to a VFS (Virtual File System) URI, that is a org.opencms.file.CmsResource in the OpenCms database.

From here, all operations that are results of HTTP requests are invoked. Any incoming request is handled in multiple steps:

1. The requesting org.opencms.file.CmsUser is authenticated and a org.opencms.file.CmsObject with this users context information is created.

This almost 1:1 extends the "standard" org.opencms.main.OpenCmsServlet . By default, all errors are handled by this servlet, which is controlled by the setting in the shipped web.xml.

This servlet is required because certain servlet containers (eg.