API for external access

[Migrated From Jforum.net]

Hi everybody,

I'm new to JForum and I'm wondering if there is any feature which ease
the integration with other softwares.

For example, is there any webservice, XML-RP, RMI or anything else
which permits to create forum, create thread, etc... from outside
JForum ?

We are looking for a forum engine which permits to manage the forum
from outside the forum webapplication, preferably written in Java.
If JForum doesn't permit that, do you know other forum engines
providing those features ?

Thanks in advance for the feedback.

Best regards,
Christophe
[originally posted on jforum.net by chris-katsuo]

[Migrated From Jforum.net]

The current version of JForum does not have an official public api. What people usually do is to send http requests to the actions they want - for example, using Jakarta's common-httpclient

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Is there a central catalog of actions?

We're evaluating forum software, and would like to do something similar. Specifically, we need to be able to create topics, users, edit user settings, and modify permissions all remotely.
[originally posted on jforum.net by cowboyd]

[Migrated From Jforum.net]

The general syntax of a request is:

<app context>/module/action[/param...].page

Modules are mapped to class in the modulesMapping.properties file.

Actions are public no argument methods in the classes

Parameters are defined in the urlPattern.properties file. This basically maps names to Parameter location. E.g.:

forums.show.2 = start, forum_id

means that in the URL /jforum/forums/show/15/3.page the 15 is the index in the topic list to start showing and 3 is the id of the forum.

FWIW, there is an older method of calling Jforum that goes thru a common Servlet that looks like:

/jforum/jforum?module=...&action=..¶m1=..¶m2=...

e.g. /jforum/jforum?module=forums&action=show&start=15&forum_id=3

As to submitting forms via code control, just use HTTPClient ( apache commons) with an SSO method. Just look at the HTML code for form that a human sees and map the fields needed into the code.

Or a more complex alternative is to merge some of the action module code into your own code (but it must run in the same webapp so the repository (cache) objects can be updated too.


[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

I notice on The Execution Context Documentation Page you provide a snippet for setting up a context. Does this work for invoking JForum code from another application, or only for customization of the JForum package?
[originally posted on jforum.net by msernatinger]

[Migrated From Jforum.net]

Well that's basically a way to manually build what the Jforum Servlet does for a request. You can use it to create a "fake" request and then call the standard jForum actions. But making sure you've got all the settings and context info setup properly can be a pain. (as opposed to just going thru the jForum servlet...)

As to invoking from another app... if you mean making a call from a separate web-app to a jForum web-app, then this won't help much. For performance reasons, a lot of jForum information is stored in memory cache's (Repository code). If you call jForum actions in a different context (class loader set), the cache objects will be different there than the jForum context. So, even though you can modify the Database info this way, it may not show up until jForum is restarted and rebuilds the cache objects.


[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

Hmm, I was musing on this and thought of the following "gee whiz" possiblity:

It would be fairly simple to have an second version of the Jforum servlet the used a different template set. Basically, extend jForum to override the template name defined by ControllerUtils.prepareTemplateContext.

Map this servlet to an extension like .rest.
Make this server use a set of templates that return XML.
Modify your web app security settings to use basic html security for .rest calls.
Add in SSO support to use request.getPrincipal() which will be set via basic html security.

Now you have the basics for a RestFul API than a remote app can call.
[originally posted on jforum.net by monroe]