robert crowther

Ranch Hand
+ Follow
since Oct 19, 2013
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by robert crowther

You're probably fixed by now but for DB insertion:

Dig round in the bugfix version on Google (*not* the original code). Read the lower posts here,

Goto the appropriate subfolder of /config/database for your database. There you will find scripts which pre-populate (and can tear down) JForum databases e.g. for MySql try,


the mysql_db_struct.sql script builds tables, we're not interested in that. But the mysql_db_data_dup.sql script populates tables, so we are interested (!). Here's the script used to create the demo category/forum,

Should be roughly the same form for the original JForum code.

If you tried something similar, then the problem is not there.. This script code suggests that, so long as there is an initial setup defining roles and the like, it's that simple - but I would still heed the warning in the post above.
8 years ago
There is much information on this in a later post - if setup configuration is of interest, please see here,
8 years ago
Note: most of this post refers to the bugfix version posted on Google code. The version is 2.3.4 (at the time of writing 2.3.5 is released)

To make this point a little clearer, the post will continually refer to JForum2, but this does not mean the original JForum (now on a version 2) - it means the Goole Code bugfix versions. This is important, as in the area of configuration, the bugfix version has reworked the original code.

There are scenarios in JForum2 usage where custom configuration options may be desirable. For example, the standard for Java Servlet deployment is very flexible. The author found himself unable to use the same configuration on local and host servers. This is possibly the most obvious reason, but there may be others, such as custom additions to source (a hack), special staged deployment, etc.

JForum2 has unusual and extensive configuration options, which have a small and general writeup here,

This post will consider ways of getting JForum2 to take custom options.

Using server functionality - Tomcat
Other servers (Jetty/Glassfish etc.) are likely to have similar functionality - please see their documentation.

In Tomcat, server-wide variables can be added to the server file, like this,

This has the format of a standard Java property file. Values can be recovered with code like this,

Values are server-wide, so it is good form to namespace them heavily.

The downsides of this approach is that, like global variable, these variable don't announce (by spec) their inclusion in code, and are outside the scope of the code, and don't use conventional error handling. Move the codebase, forget to change them, and code may crash with few warnings. They could be protected a little. On the other hand, they are not true globals, the action is not unlike adding parameters (but unannounced) to a class. They are also fast to set up.

Modifying JForum2 property loading
This can only be done with source compiling, not with .jar installations.

Add new keys to, e.g.

Then add the new property to /WebContent/WEB-INF/config/,

That's it. The property can be retrieved anywhere in JForum2 code using code like,

Downsides are that this mingles custom variables with jForum setup so may interfere with upgrading. Upsides are that all config is in one place, so easier if rolling modifications onwards, and it uses the stock JForum config (so, for example, variables are live updated)

Supplementing JForum2 property loading
This method mimics JForum2 property loading. I can be used inside source-based sites, or a supplementary code to both source and .jar based sites.

JForum2 property loading is a set of classes separated from the main body of code. This separation is not clear from source, as the classes, and particularly their initialization and usage, are scattered across the codebase.

Some snippets of code are added below. This code strips out the logging, the default property file backups, property saving, and the file listener. These are helpful to JForum2, but not essential to, say, a simple supplementary site. If the code is changed in this way, it becomes very clean, so also serves as an illustration of how the system works.

JForum2 has achieved a tidy separation of the preference code by using a Servlet listener. This loads all property files, and initializes them.

Duplicate the Servlet Listener
Copy, and put in a new package where the new configuration code will be gathered, e.g. copy to,

There is now a choice. If the listening code is to be included, several extra classes will need to be copied across to this new package. If not, the code reduces to very little. Here's the stripped version,

This is also a good place to do other code-wide work (JForum tears down the DriverManager here, but that's left to the reader).

Add a new web.xml element
In /WebContent/WEB-INF/web.xml, insert a new element, probably below the other listeners,

Duplicate the configLoader into the new package
A class of static methods which interfaces to the system.

Copy, and put in the new package. The original includes methods for loading specialised configurations, starting caches, properties file listeners, and more. Here's the stripped version,

Another class of static methods, which interfaces to the preferences.

Copy, and put in the new package. Here's the relevant methods for the stripped version (most of the methods are for typed setting/getting of properties. These should be retained, but are not shown here),

Move other relevant files from net.jforum.utils.preferences
These files,

These files (as I recall) do not need altering.

Set the config
Put a new file into the package, e.g.

Create the new Properties file, with the code above this would be /WebContent/WEB-INF/config/, and populate,

That's it. No more is needed, as the ServletListener triggers the structure.

The above is of no use if JForum2 is embedded in a site. If systematic upgrading of source is required, it may be helpful to have custom properties in a separate file. If a support site is built in parallel to JForum2, the above additions (however done) may contribute a great deal to staging and maintainability.
8 years ago
Note: most of this post refers to the bugfix version posted on Google code. To make this point a little clearer, the post will continually refer to JForum2, but this does not mean the original JForum (now on a version 2) - it means the Google Code bugfix versions. Specifically, 2.3.4. This is important, as in the area of configuration, the bugfix version has reworked the original code.

JForum2 has a rather splendid system for loading configuration. Out of curiosity it's possible users may wish to know about the system. More practically, much time in configuration can be saved if the abilities of the system are known beforehand.

JForum2 uses several properties files, located in /WebContent/WEB-INF/config. Some of these provide SQL queries, etc. The most interesting to a usr is Some of these values can be overridden from the Admin interface, but not all.

Features of the configuration system
JForum2 does not use a simple 'properties file' loader. There are several classes handing configuration loading. Here is a list of features,

  • The properties are written to system variables.
  • Ok, this means they become global, and there are many arguments about global variables, but this means the variables are available, through a defined API, for use throughout code.
  • Backup storage
  • By simple methods, a configuration can be stored.
  • Transient values and object map also available.
  • Using the same API, transient (not stored) values, and ObjectValues, a map of whole Objects, can be stored.
  • Default configurations are provided, and configurations can be appended.
  • The system uses classes packed with static methods and fields.
  • Not singletons, but classes of static calls carrying instances of themselves. It means the loading is consistent and available across servlets. Considering the threaded nature of Servlets, this is cool.
  • The system heavily namespaces all the variables
  • Which removes some/many arguments against the implementation style described above.
  • The variables are cross-checked
  • Variables must match the entries in the file net.jforum.utils.preferences.ConfigKeys. This means that the properties are specified and tightly controlled. This is probably a good thing, and a note in the file says it also triggers Eclipse autofills (on the other hand, it makes extensions difficult).
  • The system listens to the state of variables
  • A feature with zero publicity, but plainly of great interest. Change a variable, and there is no need to recompile, or even redeploy. The variable becomes active within a second or so.

    If you are glancing down this post before configuration, note in particular that the JForum2 configuration system listens and reacts to changes in files.
    8 years ago
    Yes, I should have done. The reference is to JForum, as available at the time of writing, from the original site - 2.1.9. Other versions differ, and it's clear that JForum2 has adapted slightly different internal structure and publishing for the code resource.
    8 years ago
    On using binary/.jars,

  • Code updates will still need work. JForum and JForum2 have gone to some lengths to make this easy, but it is still unlikely that .jar replacement will be a seamless update.

  • Pros
  • Easy, yet configurable. JForum (and JForum2) are built like a small CMS. If templating and configuration are all that is needed, this is the way to go.

  • So, even if downloads will bundle as a .war for deployment, how can this structure be imported to an IDE like Eclipse?


    Getting the code
    - JForum2
    Is available as a .war,

    If the .war is extracted, there is no source, but a jforum-x.x.x.jar will be found in,
    WEB-INF/lib. As far as I can see, there are no build facilities.

    - JForum
    Is available as a .zip,

    If .zip is extracted, there is no source, the classes are precompiled into,
    WEB-INF/classes/net/jforum. There is a Maven .pom file in /META-INF/maven/net.jforum/jforum/pom.xml.

    Import into Eclipse
    - JForum2
    Is a .war. In Eclipse,
    File > import > Web > War File > Next ...
    Ignore import "WAR Import: Web libraries". These are all stock for JForum2, and should work as expected.

    - JForum
    None of the Eclipse "File > Import" options will work. The handy looking "Install" imports seem to be for importing code from existing projects. Likewise, in the "General" section, the options "Archive File" and "File System".

    However, the project can be imported using a stock Java approach by making a .war (which will work because the folders are configured to be a .war),

    cd into the folder then make a .war,
    jar -cvf jforum-x.x.x.war *

    In Eclipse,
    File > import > Web > War File > Next ...

    Browse for the .war, name the project (optional), then "Finish"

    Adding Maven
    If Maven control is desired (for adding additional functionality in an agreeable way), well, what you have depends on the version of JForum used. JForum2 has a .pom file, deep inside folders, META-INF/maven/net.jforum/jforum. JForum 2.1.9 has nothing.

    The JForum2 .pom file is not, as far as I know, reusable. It is a relic from when the JForum2 structure was built. For example, all the filepaths are wrong, referring to non-existent source folders (this wouldn't be the case for a source download, which would rely on the .pom). And JForum2 can not be imported as a Maven project, because the support folder structure is required.

    In either case, as far as I know, if the binary project would be helped by Maven, then another .pom is needed. Fortunately, Eclipse can fix this. In the left panel,

    Right click on the project then,
    Configure > Convert to Maven Project

    Unless any modifications are needed immediately, agree to the stock setup. The result will be a .pom file, sited in the top level of the project.

    To use this, Eclipse needs a run configuration,
    Run > Run As > Maven Build

    Then set,
    Goal = "package"
    And tick "Skip tests".

    Now, that run configuration can be applied and run, either immediately or by selecting from the menus under "Run > Run As".

    This Maven build will only cover additions to JForum, not the original or a full build, but that should be enough.
    8 years ago
    At roughly the same time (a few days earlier) than I posted a hack method of using JForum with Eclipse on CodeRanch, the maintainer of JForum2 posted his own guide on the JForum2 site.

    Some work has been done on the site (either by Google or the maintainer), which has for a while made it hard to source these links. The install directions are in a JForum2 site attached to the side of whatever is currently running as the main site (*not* on the wiki). This link currently leads to the board itself, and the posts are sticky at the top,

    You need the "JForum2 Developer Quick-Start Guide",

    This is fairly awe-inspiring piece of work, screenshots into a .docx. You may prefer to follow that, or the below, or swap between them if there are any unclear points,

  • Hassle in setup. Requires gear installed on the host computer, in Eclipse, some outside commandlines, and more.

  • Pros
  • Cannonical method of getting JForum running repeatable, and buildable in most circumstances.

  • This method should (I've not tried...) be able to check out any revision, but then the hack method (see below) may be as useful or better.This method is likely best for those wanting to contribute to source, or have formal requirements for coding process.

    For those wanting to hack, have a look at the hack method too. The hack method flattens the folder layout, separating out the webapp/ and src/ folders. This may be your preference, or not...


    Install a JRE
    The JForum2 instructions have several steps for importing a JRE. However, JForum is known to run on modern JREs, including OpenJDK, and most installs of Eclipse will include either a JRE and/or full JDK, so those instructions are skipped here. If you have problems, or simply need Java installed, refer to the JForum2 instructions.

    Install Maven/Java in the environment
    Maven/Java is needed on the host computer. Up-to-date packaging will likely be ok (I understand JForum, even Jforum2, has not much need of the cutting edge).

    Get an ojdbc-14 .jar
    This setup requires the database driver. This is presumably not published in Maven repositories, so needs individual downloading,
    Aggravatingly, not only is this .jar not in repositories, but it is protected by "Sign up!" notices. It might be sourced elsewhere (I did)?

    As Maven will be looking for this code, this needs to go in the Maven repository. Use the following commandline,
    > mvn install:install-file -Dfile=ojdbc14.jar -DartifactId=ojdbc14 -Dversion= -Dpackaging=jar

    If Eclipse doesn't have one, install a subversion plugin
    There are two,
  • Subclipse
  • Subversive

  • SubEclipse comes from the subversion coders and is reputedly stable, Subversive is more advanced but reputedly less stable. That's all I can tell you. I tried SubEclipse,
    Help > Marketplace

    Search for "subeclipse" or "maven", Press the little 'install' button.

    (For SvnEclipse) Add native support for svn and Java
    Subversion must be installed on the host environment, not just internally in Eclipse. Also, SubEclipse uses native libraries via an adaptor. If you use packaging, you may be in luck. For example, apt-get distros have,

    You can just hunt for JavaHL, that should find required packaging.

    If Eclipse doesn't have one, install a Maven plugin

    Most Eclipse version - Eclipse Java EE IDE - comes with one. Check under,
    Help > About

    If not, follow the instructions above and get,

    Help > Marketplace.

    Import source via SVN and the Eclipse plugin
    File > Import > Checkout Projects from SVN

    Leave the next panel with the radio checked as,
    "Create a new repository location"

    On the following panel, set the URL for download. The URL use depends on your needs for JForum?...

    The panel following that should show automatically the folder tree of the subversion download,

    Select the root folder and click "Finish"

    Now the source code tree should be imported into Eclipse.

    Make Maven build from .pom locally
    In Eclipse, on the left panel, should be the newly created project,

    Right click the 'jforum2' entry, then,
    Preferences > JavaEE Integration > Enable Project Specific Preferences

    Set a runtime launch for Maven
    Run > Run As > Maven Build

    Then set,
    Goal = "package"

    And untick "Skip tests",

    Now, that run configuration can be applied and run, either immediately or by selecting from the menus under "Run".

    8 years ago
    Recent dicussion on the type of database to use,

    Upshot: HSQLDB is marvellous for a trial, as you need nothing installed, barely any Java setup at all (not words you will hear too often). But is not recommended for production.

    I do appreciate the trouble in setting up a database, from scratch, for non-professionals and others without help behind them, I do. It's a grind. But if you feel from the start you will be using JForum, you may as well do it now. JForum can work with any DB having Java connectors, (Derby, Postgre, MySQL...). I really recommend biting the bullet and finding instructions for your OS and environment. Do the job thoroughly, because JForum has both an installer, and it's manual setup through proprty files is about as good as it gets.

    Extra thouught - if you have no overwhelming inclination towards one database or another, consider how you might be deploying the forum. I know it's a long way in the future, but consider which databases are are supported by the deployment method. Otherwise, you might wind up having to migrate data from one DB to anotther...

    8 years ago
    Mostly, I havn't mentioned theming, because JForum is an excellent piece of work.

    A lot can be done with CSS, especially now the content pseudo-elements 'before:' and 'after:' are standard. If you can rely on newish browsers, using a JForum binary and CSS will save time and look good. The page structural changes seem on JavaRanch will not be possible, though.

    To change page structure, the Freemarker templating will need altering (even for commenting out - see below). Aside from Java inconsistency, FreeMarker is very nice. Look at the Freemarker site, and it's exceptional (a real standout in the Java arena) documentation,

    and start work.

    Below are notes on more substancial theming.

    Try convert a PHPBB2 template
    JForum is, as API and database structure, based on PHPBB2. The default theme is, I read, a conversion of the 'silver' theme. So a conversion of a PHPBB2 theme, of which there are many, may be possible.I've not tried this, and assume there will be grunt work involved in converting to FreeMarker markup.

    Don't be mislead by the two source scripts,


    These are for importing PHPBB2 databases into JForum, not converting templates.

    Earlier post on this,

    Some notes on more substantial Freemarker hacking
    I would have liked to know these...

    Freemarker templates should usually be commented out using Freemarker comments
    Sounds obvious, but surrounding a snippet with HTML escapes,

    will have little effect. This will remain operative Freemarker code, and the result will show in final output - only the end-user browser will ignore it (which may have uses in some debugging operations, but not many).

    Whereas commenting using Freemarker comment code,

    is not acted upon as operative code, and is never sent from the server as HTML.

    Freemarker 'includes' addressing either relative to the template, or absolute to whatever is declared as the template folder in the setup of Freemarker in the servlet. In JForum, that means an absolute address like,

    <#import "/macros/" as imageUtils/>

    looks for in,


    not mySite/WebContent/WEB-INF/.

    Freemarker 'includes' are alive to variables in scope
    If "subtemplate.htm" is included into "post_show.htm",

    ..."subtemplate.htm" can include code referring to "post_show.htm" variables like this ,

    Macros don't work directly, they need namespacing and assigning
    As someone who has used macro languages, this had me beating through documentation. The below example should illustrate all,

    For more direct work, use '<#includes ...>'.

    If you remove active code from forms, cascading issues with support code can be patched using hidden elements
    Maybe this is not a great idea in the long run. However, I, for example did not need ratings ('karma', in JForum). Other sites may wish to deprecate features such as private messages, HTML messages, etc. Sometimes there is no big switch to turn everything off (though changes can often be can be done using group permissions, and even an SQL script. Since I like to retain a degree of forward compatibility, that's my preferred route).

    Anyhow, trying to deprecate a feature can be difficult in the first instance - it keeps appearing again and distracting from overall theming. And, in the end, the template code is unnecessary, particularly in forms.

    Simply removing the templating and code is not trivial, as the code which receives the form will expect the data on, say, 'karma' to be there. This can be solved, at least temporarily, by supplying the code in a hidden element.

    For example, let's say a user can never make a choice on using HTML, they must always use plain text. In 'user_form.htm' comment out the option,

    Now, somewhere close to the comment, add an extra line to supply the missing data, set to '0', to say HTML is never allowed,

    Now the user never sees the option, but all code summoned on the server side should work correctly.
    8 years ago
    If you're ok, you're ok. Otherwise,

    Email errors
    Many are possible e.g.

    Exception in thread "pool-1-thread-3" net.jforum.exceptions.MailException: com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first. ll10sm31874440wic.9 - gsmtp

    Unless you know what these mean, and quickly, I suggest you ignore them and concentrate on accurate configuration (I don't know everything about Java Mail anyhow).

    First Step
    If this is your error,

    Error while sending the email:
    net.jforum.exceptions.MailException: javax.mail.AuthenticationFailedException: xx.xx.xx <...

    Then .jar removal may be the change needed. If present, remove this .jar from the webApp,


    The following post names Jetty. I gathered this .jar in an Eclipse Dynamic Web project also, so I assume this is a likely problem in many setups,

    What we will be doing
    Informing Java Mail how to send messages from JForum. Private messages are not covered here.

    To send mail, Java Mail needs to be configured with details about an SMTP server. Most normal email accounts (with an ISP, a firm, an independent provider, Yahoo, etc.) will have a SMTP server. Even now, some email providers may be difficult about giving up the data. Try a web-search.

    In the simple setup talked about here, no email will be sent to the SMTP account. JForum uses the server to distribute across the web (initially, to whatever address is in the test button).

    Email troubleshooting is easier if you have two or three email addresses to play with ( one to configure in, and at least one for testing).

    Where to configure
    There are two places,

    appBase > WEB-INF > config >

    and the web-based admin panel.

    I have no idea about the interaction between the two. They duplicate settings, with the text config file having more control. If they behave like the rest of JForum, the panel will be a simple override of the settings. What I did find was that clearing the boxes on the admin panel results in a setup that does nothing, so presumably it reflects the configuration of the properties.

    How to test - the test button
    If you logon to admin panel, there is a "Send a Test Email" button.

    Initially I ignored this. With a stream of errors and exceptions, I needed registration to work. But.. read on. And... use the test button.

    The test button takes an email address (this had me fooled, I thought it took a body, which action throws an error).

    SSL, or not
    Secure Socket Layer. Means emails are encrypted.

    As a newcomer I thought emails probably should be encrypted. After all, they have passwords. How big a risk having emails sniffed is for real, I don't know. Maybe we do the web a favour by not cascading information bleed? What I can say is that external host providers don't always see it that way. It's only a call and response to verify a reality. Either the other end is encrypted or not. So, the choice is likely determined by the final hosting environment of the forum. If you are using an external host, you should check with your provider, see what they provide. While asking, ask them about their provision for mail transports (MTA) and so forth - if they have none, then the JForum -> Java Mail feature will not work anyhow (Java Mail uses the local mail transport).

    Use of a SMTP provider
    Some email banlists will ban an webApp automatically if they discover automated, or suspected automated email was sourced from moving, or otherwise unverified, IP addresses. This is almost bound to happen if the webApp is hosted on someone else's server.

    One way round this is not to use any old SMTP server, but an external service. These SMPT services use addresses unlikely to be banned, with issues rapidly adressed if they are. In return they expect good behaviour. Try

  • <a href="">Mailjet<a>
  • <a href="">Mandrill<a>
  • <a href="">Sendgrid<a>

  • Example Configurations for

    GMail SSL
    First, GMail can be configured for two-step authentication. If this is the situation, the protection layer must be enabled to allow access from the working JForum app.

    After that,
    mail.sender =
    mail.smtp.auth = true =
    # Non-SSL default port is 25. If SSL, the default port is 465.
    mail.smtp.port = 465
    mail.smtp.username =
    mail.smtp.password = someSmtpPassword
    # the period in milliseconds JForum waits before sending next mail to SMTP server.
    # Some SMTP server will response 421 if you send a lot of mails in a very short time.
    # set it to 0 (zero) to disable it completely
    mail.smtp.delay = 2000

    # SSL support for SMTP. Set it to "true" if your
    # host requires that (GMail does). Don't forget
    # to change the mail.smtp.port too
    mail.smtp.ssl = true

    # If set to true, the POP3 TOP command will not be used to fetch message headers.
    # This is useful for POP3 servers that don't properly implement the TOP command,
    # or that provide incorrect information in the TOP command results.
    mail.pop3.disabletop = true

    # If the cannot be resolved, JavaMail sends a HELO
    # without a hostname - which is a violation of the SMTP protocol
    # You can set this property to force the hostname
    mail.smtp.localhost =

    Other SSL
    mail.sender = someEmailAddress
    mail.smtp.auth = true = someServerName (e.g.
    # Non-SSL default port is 25. If SSL, the default port is 465.
    mail.smtp.port = 465
    mail.smtp.username = (e.g. more than likely, an email address)
    mail.smtp.password = (e.g. more than likely, the passwordd usually used for an email account)
    # the period in milliseconds JForum waits before sending next mail to SMTP server.
    # Some SMTP server will response 421 if you send a lot of mails in a very short time.
    # set it to 0 (zero) to disable it completely
    mail.smtp.delay = 2000

    # SSL support for SMTP. Set it to "true" if your
    # host requires that (GMail does). Don't forget
    # to change the mail.smtp.port too
    mail.smtp.ssl = true

    # If set to true, the POP3 TOP command will not be used to fetch message headers.
    # This is useful for POP3 servers that don't properly implement the TOP command,
    # or that provide incorrect information in the TOP command results.
    mail.pop3.disabletop = true

    # If the cannot be resolved, JavaMail sends a HELO
    # without a hostname - which is a violation of the SMTP protocol
    # You can set this property to force the hostname
    mail.smtp.localhost =

    Non SSL
    mail.sender = someEmailAddress
    mail.smtp.auth = true = someServerName (e.g.
    # Non-SSL default port is 25. If SSL, the default port is 465.
    mail.smtp.port = 25
    mail.smtp.username = (e.g. more than likely, an email address)
    mail.smtp.password = (e.g. more than likely, the passwordd usually used for an email account)
    # the period in milliseconds JForum waits before sending next mail to SMTP server.
    # Some SMTP server will response 421 if you send a lot of mails in a very short time.
    # set it to 0 (zero) to disable it completely
    mail.smtp.delay = 2000

    # SSL support for SMTP. Set it to "true" if your
    # host requires that (GMail does). Don't forget
    # to change the mail.smtp.port too
    mail.smtp.ssl = false

    # If set to true, the POP3 TOP command will not be used to fetch message headers.
    # This is useful for POP3 servers that don't properly implement the TOP command,
    # or that provide incorrect information in the TOP command results.
    mail.pop3.disabletop = true

    # If the cannot be resolved, JavaMail sends a HELO
    # without a hostname - which is a violation of the SMTP protocol
    # You can set this property to force the hostname
    mail.smtp.localhost =

    I don't know the circumstances for needing the mail.smtp.localhost option, but duplicating in the value of may be of use.

    Needing a true value for authentication is common now.

    Simple Testing
    Logon as admin, go to the admin panel, find the email test button. Type in an email address, preferably one somewhere else to the email account configured for serving. Press 'send'.

    Hopefully you won't get an error, but a popup saying the email was sent successfully. Bear in mind sucessful sending is not sucessful recieving. If there are problems, double check you are using a working Mail Transport, and check the 'Junk'/'Trash' bins in the targeted account.

    Complex testing
    Testing JForum registration, likely. It may be a useful to enable/disable,


    ...depending on your needs.

    Jforum doesn't forget users, or allow duplicate user email addresses. Probably good security. If users wish to re-register, this (incidental to this thread, but anyhow) likely means database editing will be needed.

    Anyhow, a third email address will be helpful. Otherwise, access to the database is needed to edit out new users when they are tried.

    Testing will be easier and more comprehensive online ...if getting online is feasible. JForum registration does allow for manual "goto page and enter supplied details" registration, so that may be possible on a local development setup.

    Uncomplex Gmail settings,

    If you run into trouble, try this,

    Takes a domain name and returns information about CNAMES, banlists, original hosts and more,
    8 years ago
    Not many people will be interested in this. Or should be interested. The arguments on the web are plenty, and the general conclusion is that the best way to store files is on the system, in subfolders, with the database storing relevant filepaths and necessary meta-information. This is how JForum ihandles attachments.

    Sane, but expressive, discussion,

    Let's say, for my use-case,. I've heeded the warnings, yet database storage makes sense. How easy is this to do in JForum? Well, it must be done with source code, of course, not a binary. It is also difficult if the structure of JForum is not understood (or, like me, you are not aware of Java idioms).

    That said, this post may be interesting for the insight into JForum's structure as much as any other reason.

    Install and run a Mongodb database
    Instructions on the Mongodb site are very good.

    Get the Java driver, its a downloadable .jar, and add into your website library (WebcContent/WEB-INF/lib).

    Load some preferences by a methods roughly parallel to that of JForum
    Create this file,


    and populate, keeping the properties namespaced. No doubt this can be done smarter (but less clearly) by creating Mongodb properties then loading the config for two databases. But a separated config avoids difficulties in modding JForum's config file loading.

    A Mongodb database definition is not as SQL. It has no need of pooling or concurrency, which is handled by the DB connection, which is multithreaded.
    It can be run by default without authentication. It also has a special url string (I've broken this string to stop breakout on the forum, but it should be one continuous line).


    You may be wondering, can Mongodb's lifesaving anonymous login default be used with blank username and password entries? Or will the code fail on the residual ":@"? Answer: the code will fail.

    Add host, port, username, password, max pool size and timeout preferences. That's all that is needed.

    During preload, JForum converts preferences into classes carrying those preferences. This code action is also used to select appropriate database settings (via properties in The new Mongodb settings can be used as JForum uses them by altering,


    adding extra property mappings,

    Unless the coder is dead-set on getting a close match to the SQL mechanism, this is all that is necessary.

    Though attachment data and code could easily be hardcoded, as it is an append to existing code, I added extra overall config. Maybe it will help jog my memory sometime in the future. So to,


    I added,

    Start the database


    in startApplication(),

    Now all the setup is in place to load basic preferences.

    Build a new connection class
    This is substantially different to SQL, and cannot use JForum's highly refined abstractions.

    I settled for a whole new class, not part of JForum structure,


    This roughly mimics the current file. As this is for Mongodb, it can be considerably simpler than the usual connection (integrating Mongodb into JForum's file would require some strategic thinking (more than I was prepared to give to this).

    Note there is no init(), a raw disconnect, and no connection instance return - that's Mongodb for you. 'databaseUp' is preserved in case some function like 'ping' is re-enabled. And it is a real class, not abstract, as it is for Mongodb only. Also note that it returns a Mongo.DB, not the MongoClient (this is a rough analogy to the behaviour of a SQL db connection).

    I'm sure other can do better than this. But I am not in a position to really know if the new Enumerated Singleton's would be a better bet, or have data on other ways of coding, so here's mine,

    Get the connection up and running
    The DB connection work is done in the class JForum, not JForumBaseServlet. So, in,


    in init() add,

    This needs a new version of ForumStartupException. Code tests the connection return for truth (JForum's SQL connections catch while attaching to the ExecutionContext). Then add this to destroy(),

    The references in the code should all be familiar from earlier.

    After this, JForum loads a reference to the main DBConnection onto the ExecutionContext. I suppose this may be a preferred way to move a reference round, but if the DB is known to be Mongodb, there is no need.

    Well, that's that, it's up and running. Now let's do something with it.

    Modifying attachment handling
    Uploaded files are handled by an Apache class. Since we want to stream the file data into a database, something other than what is provided is needed. For JForum's interface to the Apache code, goto,


    Don't delete saveUploadedFile() because it is also used for avatars, etc.
    I added a method returning an InputStream from the uploaded FileItems.

    Using the connection for attachments
    There's plenty of abstractions in JForum to get lost in, but the only classes to study are

    which does physical movement of files into the web application, and the class tree,

  • attachmentDAO
  • GenericAttachmentDAO

  • Which write meta-information on attachments into the database. A reference to an instance of a DB-particularised instance of this is carried in AttachmentCommon instances.

    Either set of code can be modified, depending which is view taken (does AttachmentCommon 'handle' the attachments, or is the import a 'database write'?). I went for AttachmentCommon.

    Either way, the file copying must be removed from AttachmentCommon. I added some custom image crushing/thumb-creation code too.

    To use AttachmentCommon, replace the file transfer code. In insertAttachments(),

    'baos' is a reference to a ByteArrayOutputStream used to output from the FileItems. Then in editAttachments(), replace all delete code with,

    Note: the ids from the SQL database records are reused. Mongo does't care much if ids are continuous.

    That's all. Not much trouble, for covering all attachment CRUD.

    Tidy up
    You may wish to remove the now pointless column data from the SQL table 'jforum_attach_desc_seq'. These two columns are redundant,

  • physical_filename VARCHAR(255) NOT NULL,
  • real_filename VARCHAR(255) NOT NULL,

  • Though tidier, this cascades consequences. The generic SQL queries will need modifying, and some template code.

    Write a servlet for the upload
    Little title, long work. Sorry. It's a stock servlet, though. The web.xml item could look like this,

    The servlet might initialise, in init(),

    Then in doGet(), grab a URL, check for digits, then do something like,

    My images are guaranteed small. If the images may exceed, say, 256k, use GridFS code, not the above, and stream out (but in that scenario you must work much harder to justify database storage over JForum's built-in solution).
    8 years ago
    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.

    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).

    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,



    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 file in JForum. Either one of them, yes, but both, no. So the paths need to be hard coded.


    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,


    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



    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.

    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)

    Stackoverflow question on configuring folders for URL access,

    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.
    8 years ago
    I ran into that sort of problem too. Can't give you a full answer but,

    First, have you read the post on the differences between the original JForum and the bugfix version on Google code? Hunt it down. It helps for those answering to know which code you are referring to. Yes, especially for this.

    If you are using the bugfix version, I put a very full post on this forum about how to hack out the operative code from the bugfix version into a .war which can be imported into Eclipse, by using a precompiled version to effectively pre-configure Eclipse. It sounds hacky, but is efficient,and has few steps,

    If you're taking another route, I can't offer so much help. Bear in mind, you will need the infrastructure that a 'Dynamic Web Project' offers. There may be a way to pre-configure the project using Maven, but I didn't take that route.
    8 years ago
    Tom, people here will need a little help with the many possibilities you may be asking for.

    Do you have a server running? The most obvious server choice with this combination is Tomcat, but any servlet-handling server can be configured, e.g. Jetty, Glassfish.

    If this is the problem, then this is the best beginner setup tutorial I found,

    but I'm only guessing at the most liikely missing element in your scenario.

    Getting Eclipse running with a server and code is not a simple pre-configuration. Servers must be declared to Eclipse, then allocated to projects.
    8 years ago
    I think saw some earlier posts on problems with email which may have been related to this...
    8 years ago