CKFinder 2.x/Developers Guide/Java/Configuration/baseURL and baseDir - Revision history

J.swiderski at 20:54, 29 November 2015

2015-11-29T20:54:06Z

J.swiderski at 08:23, 4 November 2015

2015-11-04T08:23:23Z

J.swiderski at 22:44, 3 November 2015

2015-11-03T22:44:36Z

J.swiderski at 22:25, 3 November 2015

2015-11-03T22:25:50Z

J.swiderski at 21:45, 3 November 2015

2015-11-03T21:45:54Z

J.swiderski at 09:43, 21 January 2015

2015-01-21T09:43:09Z

Anna: Orphan tag removed

2011-08-09T11:10:06Z

Orphan </note> tag removed

Wiktor: Removed -X.Y

2011-05-02T19:32:53Z

Removed -X.Y

Anna: Minor text restructuring

2011-04-27T07:43:24Z

Minor text restructuring

Anna: Article contents added

2011-04-26T16:40:08Z

Article contents added

New page

{{#CUSTOMTITLE:baseDir and baseURL Parameters Explained}}
__TOC__
Both <code>baseDir</code> and <code>baseURL</code> should point to the same location on the server — the <code>userfiles</code> directory that contains all user files uploaded with CKFinder. The difference between them is as follows:
* <code>baseURL</code> gives a full URL to the <code>userfiles</code> directory or a path that is ''relative'' to the domain. For example:
*; <source lang="xml"><baseURL>http://example.com/CKFinderJava-X.Y/userfiles/</baseURL></source>
*; <source lang="xml"><baseURL>/CKFinderJava-X.Y/userfiles/</baseURL></source>
* <code>baseDir</code> gives an ''absolute'' path to the directory on the server (a physical machine). For example:
*; <source lang="xml"><baseDir>/usr/tomcat/webapps/CKFinderJava-X.Y/userfiles/</baseDir></source>
*; <source lang="xml"><baseDir>C:\tomcat\webapps\CKFinderJava-X.Y\userfiles\</baseDir></source>

<note>Note that <code>''X.Y''</code> in the code above denotes a CKFinder version, like <code>2.0</code>.
</note>

You may ask: why use two paths to point to one location?

The <code>baseURL</code> parameter represents the path that is used by HTTP clients. It is employed for example when CKFinder returns the URL addresses of the files. CKFinder itself is not an HTTP client, but an application that operates on the server-based files that needs absolute paths to these files to operate correctly.

A specific server configuration may sometimes lead to problems with setting the absolute path based on the <code>baseURL</code> parameter, which leads to the malfunctioning of the application. This is where the <code>baseDir</code> parameter that contains the direct path to the <code>userfiles</code> directory may help.

== Misconfiguration of baseURL and baseDir ==
Since setting the parameters may sometimes seem counter-intuitive, especially for the beginners, here are a couple of examples of CKFinder misconfiguration, i.e. the situation where the <code>baseURL</code> and <code>baseDir</code> settings were wrong.

=== Example 1: Using a Relative Path for baseDir ===
<source lang="xml">

<baseDir>/userfiles/</baseDir>
<baseURL>/CKFinderJava-X.Y/userfiles/</baseURL>
</source>

In this example the <code>baseDir</code> parameter contains the relative (and not absolute) path to the <code>userfiles</code> directory. In a Windows system with this configuration the <code>userfiles</code> directory will be created on the same partition that hosts the server (for example, <code>C:\userfiles</code>). On a Linux machine the system will try to create a <code>/userfiles/</code> directory which will probably fail due to missing server permissions to create new directories in <code>/</code>.

=== Example 2: Incoherent Directory Paths ===
<source lang="xml">

<baseDir>C:\userfiles</baseDir>
<baseURL>/CKFinderJava-X.Y/userfiles/</baseURL>
</source>

In this example <code>baseDir</code> is set to an absolute path, but the parameter points to a different location than <code>baseURL</code> that is set relative to the application root.

=== Result: CKFinder Misconfiguration ===
In both examples the parameters point to different server directories. As a result, some CKFinder features may not work correctly. The '''View''' function, for example, will be one of them.

Why is that so?

As mentioned above, CKFinder works on files and for this it uses the <code>baseDir</code> parameter value. All uploaded files will thus be placed in the location that is set in this parameter. HTTP clients, on the other hand, will use the <code>baseURL</code> value, but in both examples presented above this parameter will point to a non-existent location which in some cases may lead to a lack of access to files.

== More on baseURL ==
As stated above, if the <code>baseDir</code> parameter is empty, CKFinder will try to deduce the <code>userfile</code> path based on the <code>baseURL</code> parameter value.
<source lang="xml">
<baseURL>/userfiles/</baseURL>
<baseDir></baseDir>
</source>

If the server hosts more applications for one domain (like <code>localhost</code> or <code>www.example.com</code>), the code above will not work for most of them. To be exact, it will work only for the application that is set as the default one for the domain.

This may sound a bit enigmatic, but here is the explanation.

If the server hosts multiple applications in one domain, the users usually call them in the following way (note this does not pertain to the default application):

<code><nowiki>http://localhost:8080/CKFinderJava-X.Y/</nowiki><br />
<nowiki>http://www.example.com/CKFinderJava-X.Y/</nowiki></code>

or the following way, where <code>filemanager</code> is the ''context path'' for the <code>CKFinderJava-''X.Y''</code> application:

<code><nowiki>http://localhost:8080/filemanager/</nowiki><br />
<nowiki>http://www.example.com/filemanager/</nowiki></code>

These applications are (physically) located in one directory (like <code>webapps</code> for Tomcat or Jetty) and to differentiate between them, the user needs to include the name or alias (context path) of the called application in its URL.
When the <code>baseURL</code> parameter is set to point directly to the <code>userfiles</code> folder, CKFinder will create this folder in the application directory (like <code> CKFinderJava-''X.Y''/userfiles/</code>). On the other hand, when the user will want to use the '''View''' option, the browser will search for the image in the <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> directory (<code><nowiki>http://hostName/baseURL/</nowiki></code>) instead of <code><nowiki>http://localhost:8080/CKFinderJava-X.Y/userfiles/</nowiki></code>.

The first address points to the <code>userfiles</code> directory placed in the root of the web applications directory. Since the CKFinder <code>userfiles</code> directory is located elsewhere, the image will not be found and the browser will display the "404 — Not found" error.

It is worth noting that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava-''X.Y''</code> application folder and display the image.

@@ Line 73: / Line 73: @@
 One solution is using [https://en.wikipedia.org/wiki/Symbolic_link symlinks]. The <code>userfiles</code> folder located inside application context can be a symbolic link to some other directory on the disk. With that simple approach <code>/CKFinderJava/userfiles/</code> can point to folder of your choice. One downside of this technique is that you have to recreate the symbolic link with every application redeploy as the symlink gets removed on redeployment.
-Another solution is using server features. Most of the servers provide "virtual directory" mechanism. A "Virtual Directory" allows accessing through <code><strong>HTTP</strong></code> a folder which can be located even outside of the server. In Tomcat 7-8 this can be done through <strong>aliases</strong>, in Tomcat 6 by <strong>adding another context to <code>server.xml</code></strong>, in GlassFish through <strong>alternate docroots</strong>, in Jetty by <strong>adding another context to <code>jetty.xml</code></strong> and In Weblogic through <strong>virtual directories</strong>. <br />
+Another solution is using server features. Most of the servers provide "virtual directory" mechanism. A "Virtual Directory" allows accessing through <code><strong>HTTP</strong></code> a folder which can be located even outside of the server. In Tomcat 7-8 this can be done through <strong>aliases</strong>, in Tomcat 6 by <strong>adding another context to <code>server.xml</code></strong>, in GlassFish through <strong>alternate docroots</strong>, in Jetty by <strong>adding another context to <code>jetty.xml</code></strong>, in Weblogic through <strong>virtual directories</strong>, in WildFly by <strong>adding extra entries to <code>urn:jboss:domain:undertow</code> <code>subsystem</code> element</strong> in one of configuration files e.g.  standalone.xml  and in JBOSS EAP by <strong>allowing symlinks</strong> for particular external folder in <code>jboss-web.xml</code> file and then <strong>making that symlink</strong>.<br />
 Let’s have a look at an example for Apache Tomcat 8. The server is installed in <code>C:/Apache-Tomcat-8/</code> directory, CKFinderJava is installed in <code>C:/Apache-Tomcat-8/CKFinderJava</code>, we want to have our <code>userfiles</code> folder located directly on <code>C</code> drive and we want that folder to be called <code>"myimages"</code>. Here are the settings that will allow having all CKFinder features working, and <code>userfiles</code> folder not being removed with every redeployment of the application:

@@ Line 44: / Line 44: @@
 == BaseDir and BaseUrl best practice ==
-<note>It is always recommended to set <strong>both</strong> <code>baseUrl</code> and <code>baseDir</code> so that they point to same location which is outside of application directory.</note>
+<note>It is always recommended to set <strong>both</strong> <code>baseUrl</code> and <code>baseDir</code> so that they point to same location which is outside of an application directory.</note>
-In previous section, we have seen what problems we may get when these two properties are misconfigured but what will happen when only <code>baseUrl</code> is set? CKFinder needs both, <code>baseUrl</code> and <code>baseDir</code> to work correctly and if <code>baseDir</code> is missing, CKFinder will try to determine its value based on  <code>baseUrl</code>.  You must know however that CKFinder has limited capabilities in this case. To be more precise, CKFinder is mainly limited to application context (application main directory).
+In previous section, we have seen what problems we may get when these two properties are misconfigured but what will happen when only <code>baseUrl</code> is set? CKFinder needs both, <code>baseUrl</code> and <code>baseDir</code> to work correctly and if <code>baseDir</code> is missing, CKFinder will try to determine its value based on  the <code>baseUrl</code> property.  You must know however that CKFinder has limited capabilities in this case. To be more precise, CKFinder is mainly limited to application context (application main directory).
 Let’s have a look at few examples:
 <source lang="xml">
@@ Line 57: / Line 57: @@
 </source>
-In both above cases the <code>userfiles</code> folder points to server’s main applications directory. When multiple applications are kept on server they are accessible like <code><nowiki>http://example.com/CKFinderJava-2.5</nowiki></code> or <code><nowiki>http://example.com/CKFinderJava-2.4</nowiki></code>. As you can probably see the <code>userfiles</code> folder should be created on same level as applications in order to be accessible through HTTP. The problem is that applications folder is not accessible from the web. There are however two servers which have general accessible folders and to which CKFinder can get. These servers are Apache Tomcat and Oracle GlassFish. Having configuration like presented above, <strong>starting from CKFinder 2.5.1</strong>,  CKFinder will create <code>userfiles</code> folder in <code>TOMCAT_HOME/webapps/ROOT</code> directory for Apache Tomcat and <code>GLASSFISH_HOME/glassfish/domains/domain_name/docroot </code> directory for Oracle GlassFish. Everything will work as expected in this case. For other supported servers, CKFinder will use fallback approach and create <code>userfiles</code> folder inside <code>CKFinderJava</code>application directory. As you probably know, this will unfortunately result in <strong>View</strong> option not working properly.
+In both above cases the <code>userfiles</code> folder points to server’s main applications directory. When multiple applications are kept on server they are accessible like <code><nowiki>http://example.com/CKFinderJava-2.5</nowiki></code> or <code><nowiki>http://example.com/CKFinderJava-2.4</nowiki></code>. As you can probably see the <code>userfiles</code> folder should be created on same level as applications in order to be accessible through HTTP. The problem is that applications folder is not accessible from the web. There are however two servers which have general accessible folders and to which CKFinder can get. These servers are Apache Tomcat and Oracle GlassFish. Having configuration like presented above, <strong>starting from CKFinder 2.5.1</strong>,  CKFinder will create <code>userfiles</code> folder in <code>TOMCAT_HOME/webapps/ROOT</code> directory for Apache Tomcat and <code>GLASSFISH_HOME/glassfish/domains/domain_name/docroot </code> directory for Oracle GlassFish. Everything will work as expected in this case. For other supported servers, CKFinder will use fallback approach and create <code>userfiles</code> folder inside <code>CKFinderJava</code> application directory. As you probably know, this will unfortunately result in <strong>View</strong> option not working properly.
 Let’s take a look at another example:
@@ Line 73: / Line 73: @@
 One solution is using [https://en.wikipedia.org/wiki/Symbolic_link symlinks]. The <code>userfiles</code> folder located inside application context can be a symbolic link to some other directory on the disk. With that simple approach <code>/CKFinderJava/userfiles/</code> can point to folder of your choice. One downside of this technique is that you have to recreate the symbolic link with every application redeploy as the symlink gets removed on redeployment.
-Another and better one solution is using server features. Most of the servers provide "virtual directory" mechanism. A "Virtual Directory" allows accessing folder which can be located even outside of the server, through <code><strong>HTTP</strong></code>. In Tomcat 7-8 this can be done through <strong>aliases</strong>, in Tomcat 6 by <strong>adding another context to <code>server.xml</code></strong>, in GlassFish through <strong>alternate docroots</strong>, in Jetty by <strong>adding another context to <code>jetty.xml</code></strong> and In Weblogic through <strong>virtual directories</strong>. <br />
+Another solution is using server features. Most of the servers provide "virtual directory" mechanism. A "Virtual Directory" allows accessing through <code><strong>HTTP</strong></code> a folder which can be located even outside of the server. In Tomcat 7-8 this can be done through <strong>aliases</strong>, in Tomcat 6 by <strong>adding another context to <code>server.xml</code></strong>, in GlassFish through <strong>alternate docroots</strong>, in Jetty by <strong>adding another context to <code>jetty.xml</code></strong> and In Weblogic through <strong>virtual directories</strong>. <br />
 Let’s have a look at an example for Apache Tomcat 8. The server is installed in <code>C:/Apache-Tomcat-8/</code> directory, CKFinderJava is installed in <code>C:/Apache-Tomcat-8/CKFinderJava</code>, we want to have our <code>userfiles</code> folder located directly on <code>C</code> drive and we want that folder to be called <code>"myimages"</code>. Here are the settings that will allow having all CKFinder features working, and <code>userfiles</code> folder not being removed with every redeployment of the application:

← Older revision		Revision as of 22:44, 3 November 2015
Line 92:		Line 92:
	</Context>		</Context>
	</source>		</source>
		+	With the help of the server and two configuration changes, you can have your files being saved to <code>C:/myimages</code> folder. It’s also worth mentioning that <code>myimages</code> directory is invisible to end user and Tomcat serves files as if they really were located inside <code> CKFinderJava/userfiles/</code>.

@@ Line 66: / Line 66: @@
 Above setting will create <code>userfiles</code> inside <code>CKFinderJava</code> application directory. Although such configuration will work on every server there is a caveat to that approach. It isn’t recommended to put folder for uploaded files into deployed application folder because with every redeployment (e.g. when upgrading <code>war</code> to new version) of the application, the upload folder will be removed.
-<strong>So, what should be done to set <code>baseUrl</code> and <code>baseDir</code> correctly? </strong> <br />
+<strong>So, what should be done to set <code>baseUrl</code> and <code>baseDir</code> correctly? </strong>
-Let’s have a look at an example for Tomcat 8 server. The server is installed in <code>C:/Apache-Tomcat-8/</code> folder, CKFinderJava is installed in <code>C:/Apache-Tomcat-8/CKFinderJava</code>, we want to have our <code>userfiles</code> folder located directly on <code>C</code> drive and we want that folder to be called <code>"myimages"</code>. Here are the settings that will allow having all CKFinder features working, and <code>userfiles</code> folder not being removed with every redeployment of the application:
+<note>
 CKFinder config.xml settings:

@@ Line 43: / Line 43: @@
 As mentioned above, CKFinder works on files and for this it uses the <code>baseDir</code> parameter value. All uploaded files will thus be placed in the location that is set in this parameter. HTTP clients, on the other hand, will use the <code>baseURL</code> value, but in both examples presented above this parameter will point to a non-existent location which in some cases may lead to a lack of access to files.
-== More on baseURL ==
+== BaseDir and BaseUrl best practice ==
-As stated above, if the <code>baseDir</code> parameter is empty, CKFinder will try to deduce the <code>userfile</code> path based on the <code>baseURL</code> parameter value.
+<note>It is always recommended to set <strong>both</strong> <code>baseUrl</code> and <code>baseDir</code> so that they point to same location which is outside of application directory.</note>
 <source lang="xml">
 <baseURL>/userfiles/</baseURL>
 <baseDir></baseDir>
 </source>
-If the server hosts more applications for one domain (like <code>localhost</code> or <code>www.example.com</code>), the code above will not work for most of them. To be exact, it will work only for the application that is set as the default one for the domain.
+In both above cases the <code>userfiles</code> folder points to server’s main applications directory. When multiple applications are kept on server they are accessible like <code><nowiki>http://example.com/CKFinderJava-2.5</nowiki></code> or <code><nowiki>http://example.com/CKFinderJava-2.4</nowiki></code>. As you can probably see the <code>userfiles</code> folder should be created on same level as applications in order to be accessible through HTTP. The problem is that applications folder is not accessible from the web. There are however two servers which have general accessible folders and to which CKFinder can get. These servers are Apache Tomcat and Oracle GlassFish. Having configuration like presented above, <strong>starting from CKFinder 2.5.1</strong>,  CKFinder will create <code>userfiles</code> folder in <code>TOMCAT_HOME/webapps/ROOT</code> directory for Apache Tomcat and <code>GLASSFISH_HOME/glassfish/domains/domain_name/docroot </code> directory for Oracle GlassFish. Everything will work as expected in this case. For other supported servers, CKFinder will use fallback approach and create <code>userfiles</code> folder inside <code>CKFinderJava</code>application directory. As you probably know, this will unfortunately result in <strong>View</strong> option not working properly.
-This may sound a bit enigmatic, but here is the explanation.
+Let’s take a look at another example:
-If the server hosts multiple applications in one domain, the users usually call them in the following way (note this does not pertain to the default application):
+Above setting will create <code>userfiles</code> inside <code>CKFinderJava</code> application directory. Although such configuration will work on every server there is a caveat to that approach. It isn’t recommended to put folder for uploaded files into deployed application folder because with every redeployment (e.g. when upgrading <code>war</code> to new version) of the application, the upload folder will be removed.
-<code><nowiki>http://localhost:8080/CKFinderJava/</nowiki><br />
+Let’s have a look at an example for Tomcat 8 server. The server is installed in <code>C:/Apache-Tomcat-8/</code> folder, CKFinderJava is installed in <code>C:/Apache-Tomcat-8/CKFinderJava</code>, we want to have our <code>userfiles</code> folder located directly on <code>C</code> drive and we want that folder to be called <code>"myimages"</code>. Here are the settings that will allow having all CKFinder features working, and <code>userfiles</code> folder not being removed with every redeployment of the application:
-or the following way, where <code>filemanager</code> is the ''context path'' for the <code>CKFinderJava</code> application:
+CKFinder config.xml settings:
-<code><nowiki>http://localhost:8080/filemanager/</nowiki><br />
+CKFinderJava/META-INF/context.xaml settings:
-<nowiki>http://www.example.com/filemanager/</nowiki></code>
+<source lang="xml">
+<Context antiJARLocking="true" path="/CKFinderJava" reloadable="true" >
-These applications are (physically) located in one directory (like <code>webapps</code> for Tomcat or Jetty) and to differentiate between them, the user needs to include the name or alias (context path) of the called application in its URL.
+    <Resources>
-When the <code>baseURL</code> parameter is set to point directly to the <code>userfiles</code> folder, CKFinder will create this folder in the application directory (like <code> CKFinderJava/userfiles/</code>). On the other hand, when the user will want to use the '''View''' option, the browser will search for the image in the <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> directory (<code><nowiki>http://hostName/baseURL/</nowiki></code>) instead of <code><nowiki>http://localhost:8080/CKFinderJava/userfiles/</nowiki></code>.
+       <PreResources base="C://myimages" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/userfiles" />
+   </Resources>
-The first address points to the <code>userfiles</code> directory placed in the root of the web applications directory. Since the CKFinder <code>userfiles</code> directory is located elsewhere, the image will not be found and the browser will display the "404 &mdash; Not found" error.
+   <Valve className="org.apache.catalina.valves.RemoteAddrValve"  allow=".*" />
+</Context>
-It is worth mentioning that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava</code> application folder and display the image.
+</source>

← Older revision		Revision as of 09:43, 21 January 2015
Line 69:		Line 69:
	The first address points to the <code>userfiles</code> directory placed in the root of the web applications directory. Since the CKFinder <code>userfiles</code> directory is located elsewhere, the image will not be found and the browser will display the "404 — Not found" error.		The first address points to the <code>userfiles</code> directory placed in the root of the web applications directory. Since the CKFinder <code>userfiles</code> directory is located elsewhere, the image will not be found and the browser will display the "404 — Not found" error.

−	It is worth ~~noting~~ that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava</code> application folder and display the image.	+	It is worth mentioning that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava</code> application folder and display the image.

@@ Line 8: / Line 8: @@
 *; <source lang="xml"><baseDir>/usr/tomcat/webapps/CKFinderJava/userfiles/</baseDir></source>
 *; <source lang="xml"><baseDir>C:\tomcat\webapps\CKFinderJava\userfiles\</baseDir></source>
 You may ask: why use two paths to point to one location?

@@ Line 3: / Line 3: @@
 Both <code>baseDir</code> and <code>baseURL</code> should point to the same location on the server &mdash; the <code>userfiles</code> directory that contains all user files uploaded with CKFinder. The difference between them is as follows:
 * <code>baseURL</code> gives a full URL to the <code>userfiles</code> directory or a path that is ''relative'' to the domain. For example:
-*; <source lang="xml"><baseURL>http://example.com/CKFinderJava-X.Y/userfiles/</baseURL></source>
+*; <source lang="xml"><baseURL>http://example.com/CKFinderJava/userfiles/</baseURL></source>
-*; <source lang="xml"><baseURL>/CKFinderJava-X.Y/userfiles/</baseURL></source>
+*; <source lang="xml"><baseURL>/CKFinderJava/userfiles/</baseURL></source>
 * <code>baseDir</code> gives an ''absolute'' path to the directory on the server (a physical machine). For example:
-*; <source lang="xml"><baseDir>/usr/tomcat/webapps/CKFinderJava-X.Y/userfiles/</baseDir></source>
+*; <source lang="xml"><baseDir>/usr/tomcat/webapps/CKFinderJava/userfiles/</baseDir></source>
-*; <source lang="xml"><baseDir>C:\tomcat\webapps\CKFinderJava-X.Y\userfiles\</baseDir></source>
+*; <source lang="xml"><baseDir>C:\tomcat\webapps\CKFinderJava\userfiles\</baseDir></source>
 </note>
@@ Line 26: / Line 24: @@
 <!-- This configuration is wrong. -->
 <baseDir>/userfiles/</baseDir>
-<baseURL>/CKFinderJava-X.Y/userfiles/</baseURL>
+<baseURL>/CKFinderJava/userfiles/</baseURL>
 </source>
@@ Line 35: / Line 33: @@
 <!-- This configuration is wrong. -->
 <baseDir>C:\userfiles</baseDir>
-<baseURL>/CKFinderJava-X.Y/userfiles/</baseURL>
+<baseURL>/CKFinderJava/userfiles/</baseURL>
 </source>
@@ Line 60: / Line 58: @@
 If the server hosts multiple applications in one domain, the users usually call them in the following way (note this does not pertain to the default application):
-<code><nowiki>http://localhost:8080/CKFinderJava-X.Y/</nowiki><br />
+<code><nowiki>http://localhost:8080/CKFinderJava/</nowiki><br />
-<nowiki>http://www.example.com/CKFinderJava-X.Y/</nowiki></code>
+<nowiki>http://www.example.com/CKFinderJava/</nowiki></code>
-or the following way, where <code>filemanager</code> is the ''context path'' for the <code>CKFinderJava-''X.Y''</code> application:
+or the following way, where <code>filemanager</code> is the ''context path'' for the <code>CKFinderJava</code> application:
 <code><nowiki>http://localhost:8080/filemanager/</nowiki><br />
@@ Line 69: / Line 67: @@
 These applications are (physically) located in one directory (like <code>webapps</code> for Tomcat or Jetty) and to differentiate between them, the user needs to include the name or alias (context path) of the called application in its URL.
-When the <code>baseURL</code> parameter is set to point directly to the <code>userfiles</code> folder, CKFinder will create this folder in the application directory (like <code> CKFinderJava-''X.Y''/userfiles/</code>). On the other hand, when the user will want to use the '''View''' option, the browser will search for the image in the <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> directory (<code><nowiki>http://hostName/baseURL/</nowiki></code>) instead of <code><nowiki>http://localhost:8080/CKFinderJava-X.Y/userfiles/</nowiki></code>.
+When the <code>baseURL</code> parameter is set to point directly to the <code>userfiles</code> folder, CKFinder will create this folder in the application directory (like <code> CKFinderJava/userfiles/</code>). On the other hand, when the user will want to use the '''View''' option, the browser will search for the image in the <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> directory (<code><nowiki>http://hostName/baseURL/</nowiki></code>) instead of <code><nowiki>http://localhost:8080/CKFinderJava/userfiles/</nowiki></code>.
 The first address points to the <code>userfiles</code> directory placed in the root of the web applications directory. Since the CKFinder <code>userfiles</code> directory is located elsewhere, the image will not be found and the browser will display the "404 &mdash; Not found" error.
-It is worth noting that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava-''X.Y''</code> application folder and display the image.
+It is worth noting that the example above will work if you set one of the applications as a default for a domain (for example by using virtual hosting). Do remember, though, that this is only possible for one application per domain. With this configuration in place the <code>userfiles</code> directory will be created in the application root, but by default the application root is associated with the domain name, so calling <code><nowiki>http://localhost:8080/userfiles/</nowiki></code> will let you search in the <code>CKFinderJava</code> application folder and display the image.

@@ Line 15: / Line 15: @@
 You may ask: why use two paths to point to one location?
-The <code>baseURL</code> parameter represents the path that is used by HTTP clients. It is employed for example when CKFinder returns the URL addresses of the files. CKFinder itself is not an HTTP client, but an application that operates on the server-based files that needs absolute paths to these files to operate correctly.
+The <code>baseURL</code> parameter represents the path that is used by HTTP clients. It is employed for example when CKFinder returns the URL addresses of the files.
-A specific server configuration may sometimes lead to problems with setting the absolute path based on the <code>baseURL</code> parameter, which leads to the malfunctioning of the application. This is where the <code>baseDir</code> parameter that contains the direct path to the <code>userfiles</code> directory may help.
+CKFinder itself is not an HTTP client, but an application that operates on server-based files that needs absolute paths to these files to operate correctly. A specific server configuration may sometimes lead to problems with setting the absolute path based on the <code>baseURL</code> parameter, which leads to the malfunctioning of the application. This is where the <code>baseDir</code> parameter that contains the direct path to the <code>userfiles</code> directory may help.
 == Misconfiguration of baseURL and baseDir ==