Notes:
If you deploy to your own server, this post is unlikely to be of interest.
This post does not cover Avatar/Smiley folders, though the techniques are the same
On the deployment server, you must have access to manipulating both the filesystem and also the server configuration.
Background
When JForum is deployed, uploaded attachments are copied to a folder (in detail, to generated subfolders of that folder) named /upload. For various reasons, this is the commonly approved method for the storage of uploaded files.
This technique causes a difficulty in deployment, particularly for
testing. If deployment is made to some other server, then the upload/ folder is simply a part of the file structure, and so is overwritten. Note that the database would not be overwritten, as it is viewed as a service the application connects to.
While this can be seen as inconsistent, it is no worse than most/all other languages, and
Java at least provides file interfaces which treat filesystem access consistently.
With a caveat I'll mention lower, there is a way of persisting the folder's contents across deployments. The changes are intricate but simple and easily reversible (so could be used only for a testing/development stage, for example).
Strategy
You may be thinking this can be done by a change of configuration. No, can't be done. You see, JForum configuration is flexible enough to both write and read images from a folder outside the application context. But how is the server to deliver the images? Folders external to a web app have URLs deliberately locked out as security policy.
The attachment URL is constructed in the template,
/templates/default/post_show_attachments_inc.htm
by
So the thumbpath is always constructed from the contextpath. The URLs, relative to the contextPath, can not recover the images.
So you may be thinking we'll use Context tags in server.xml, and the "alias" attribute or something. Answer, no. They use absolute paths. If they used relative paths, we'd be away. Another dead end.
Then there is the plan to make a new
Servlet. This is a clean distinction between data resource and code. However, it clones the problem - how is a context-relative URL going to address the stored images? Plus, a supplementary servlet is extra and unnecessary overhead.
Here are the issues,
The URL must be caught and rerouted to an external folder.Tomcat, perhaps for consistent structure or security, likes paths to match folder structure.The URL is relative to the context.
Well, Tomcat reference documentation says this,
"Locate the WAR and/or directory outside of the Host's appBase and use a context.xml file with a docBase attribute to define it."
To add to the general awkwardness, as far as I know there is no way to carry a centralised config to both Tomcat's server.xml file and the SystemGlobals.properties file in JForum. Either one of them, yes, but both, no. So the paths need to be hard coded.
Steps
New upload folders
Create a new folder. The folder must be outside the webapps folder, specifically outside wherever the <host> defines as "docBase". Server root is ok, So create some folder similar to,
.../tomcat/uploads
Release permissions on the folder.
Configure Tomcat to read the folder by URLs.
I got it down to this, which must be in server.xml, in the same <host> element as the site.
docBase = Where the folder is to be found. Must be outside the webapps directory.
path = the
string Tomcat will attempt to match for URLs. As this path is longer than the base URL, Tomcat will attempt to route to this by preference (i.e. when it sees the element "/upload/" in the URL, it will use that path, not the base path of the app).
Why `catalina.home'? Because some sort of relative addressing helps in relocating the webapp and making it portable. Why `home'? Because home is the heart of Tomcat.
Note for Eclipse users: Eclipse uses a virtual server, i.e. it moves Tomcat configuration and deployment to folders deeply nested in Eclipse workspaces. Use `catalina.base', for example, and the /upload folder will continue to vanish and reappear as the server is rebuilt.
Configure JForum to manage data in the folder
In,
WEB-INF/config/systemGlobals.properties
change this property. The folder is now outside the web-app, so this should be a hard-coded path (both for a local or remote-deployed folder),
Unless the path targets above were redefined, leave this as is,
Now attachments will be routed to the folder, both by JForum management and via the web. Lump JForum .war deployment will preserve both database and uploads, and the links between them.
Caveat
Moving and accessing data/state outside of the deployed app could cause problems with future server reconfiguration. I'm thinking here of, say, caching, clustering, or security issues. I don't have the experience to comment. That said, it may be that your JForum application, as mine, is unlikely to meet such issues.
Tomcat 7 live configuration documentation (warning- lacks an overview)
https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html
Stackoverflow question on configuring folders for URL access,
http://stackoverflow.com/questions/11138701/difference-between-tomcats-extraresourcepaths-and-aliases-to-access-an-external
Any better information on these configurations and topologies is welcome, especially anything security related.
Last warning: Further information on the web is fragmentary and elusive.
