PHP, PERL, C++, TCL, Python

Server Side Includes (SSI)

Бързи сървъри

Без такса за регистрация

SMTP, IMAP, POP3

Mailing Lists

Статистики на сайта

Webmail

Email Forwards

Email Auto Responders

logicaldoc хостинг Описание

LogicalDOC is a free document management system that is designed to handle and share documents within an organization.

LogicalDOC is a content repository, with Lucene indexing, Activiti workflow, and a set of automatic import procedures. The system was developed using Java technology.

logicaldoc хостинг Свързани статии

Hosting plans, subscriptions and add-ons with Tomcat support

In order to deploy Tomcat web apps your subscription(webspace) must support it. Subscriptions have hosting plans and the hosting plans can allow deployment of certain number of Tomcat web apps. If a plan does not include Tomcat web apps you can buy an add-on ( if available ).

Our Java environment

We run Tomcat application server on Oracle JVM. Tomcat is run behind Apache HTTPd front-end so we could support additional environments - e.g. PHP.

We offer shared Tomcat hosting only. That is - one Tomcat running in one Java JVM hosts multiple web applications.

In order to provide isolation between applications of different customers Tomcat is started with its security manager enabled.

Tomcat calls the root directory of a domain or subdomain "application base" (appBase config option). Apache HTTPd calls it "document root" (DocumentRoot config option). In our environment Tomcat and Apache HTTPd virtual hosts are pointed to the same directory so DocumentRoot and appBase are the same thing.

Which domains and subdomains can have Tomcat web apps

A domain or subdomain can have Tomcat web apps deployed if it:

has hosting enabled

is active, e.g. not suspended or disabled

Additionally, the domain or subdomain DocumentRoot must be pointed to a directory which is directly under the subscription home directory. E.g.

"/test" - (correct)

"/httpdocs/test" - (NOT correct)

Before requesting deployment

It is important to test your Tomcat web apps locally before requesting their deployment. The tests have to be done with Tomcat's security manager enabled. To enable the security manager locally open a terminal window and run:

WAR files

WAR files must be extracted in order to be deployed. E.g. the contents of test.war should be placed in a directory named test.

WAR stands for Web application Archive .

Requesting web app deployment

To request a deployment go to the "Websites & Domains" section, find the domain/subdomain that should serve the web app and click its Tomcat button.

You will find a "Deployment request form" on the opened page.This form contains:

A list of deployable contexts

A checkbox to request manual review of the web app META-INF/context.xml

A text area where you can add additional information to the person who will process your request

The list of deployable contexts is generated by scanning the DocumentRoot. An entry in the list is created for:

directories placed directly in the DocumentRoot and

containing a subdirectory WEB-INF and

having names which can be valid context path

META-INF/context.xml will be ignored even if it exists unless you check the checkbox. Please do so if you have custom Resource/Realm/etc definitions there. It will be reviewed and you will be able to see how it has been applied in the "Support reply" .

Start, Stop and Reload of Tomcat web apps

To Start/Stop/Reload web apps go to the "Websites & Domains" section, find the domain/subdomain containing the web app and click its Tomcat button. You will see the list in the "Deployed web applications" section. Started web apps can be stopped and stopped ones can be started. To reload a web app stop it first and then start it.

Our hosting servers are configured for production use. The automatic reloads which are usually enabled in the default Tomcat configuration are disabled. No automatic checks for JSP, class, JAR, web.xml, etc modifications are performed.

You need to manually reload your web apps after doing modifications.

Tomcat log files

Tomcat logs can be found in the /logs-tomcat directory which is placed in the subscription's home. The logs are rotated when they reach 1 MB and 10 old log files are preserved.

The STDOUT and STDERR streams of each application are redirected to these logs so e.g. System.out.println(..) and System.err.println(..) go there.

Servlet/filter mappings

In order your mappings to work as expected two things must be done:

As usual they have to be defined in WEB-INF/web.xml

Apache HTTPd frontend has to be configured to pass them to the Tomcat backend.

The second step is done via .htaccess files. Here's an example. Let's say you have the following context:

Or you can even forward all requests for this subdomain to the Tomcat backend:

RewriteEngine On
RewriteRule ^(.*)$ ajp://127.0.0.1:8009/$1 [NE,P,L]

Security policy

Tomcat's security policy is defined in the file $TOMCAT_HOME/conf/catalina.policy.

Our policy grants all the permissions in the default catalina.policy distributed with Tomcat. It also grants several additional permissions commonly required by web apps. Some of them are:

Each of your applications is granted read/write/delete permissions for all files and dirs under subscription's home dir

Read permission is granted to all system properties

New Socket connections are allowed

Some additional package access is granted as well as Reflection permissions

If you find that a permission is required by your web app but it is not granted by our policy you could request it via the HelpDesk. Our administrators will review your request and grant the permission if it is appropriate.

Please note that requests for permissions that might affect the application isolation or the security of the other users' web apps will be denied.

Read/Write/Delete files on the file system

The Tomcat security policy grants web apps read/write/delete permissions for all the files and dirs under the subscription home.

The file system permissions must also allow the system user "tomcat" to do the respective operation.

E.g. to create a directory which is writable by "tomcat" you can login via FTP and do:

mkdir docs/app1/store1
chmod a+rwx docs/app1/store1

You can also create dirs and manage permissions via Plesk File Manager .

You should be extra carefull when using relative paths. They can be relative to something different than what you expect. In order to check a relative path you can place a code like this in e.g. test.jsp:

The MySQL driver is pre-installed in $TOMCAT_HOME/lib so you don't need to put it in your web app's WEB-INF/lib .

PostgreSQL drivers are not pre-installed. Neither are SQLite and HSQLDB drivers.

Database connection pooling

We do not recommend using connection pooling in our environment since the connection establishment to the DB is lightweight process. Just close the DB connections when you're finished with them and reopen them when needed.

A request scope is an excellent lifespan for a DB connection.

Be especially careful when reusing pooled connections since the RDBMS might be configured to timeout inactive connections and you might encounter: