JamesR wrote:
Could you explain a little more what you mean by using cross context dispatchers?
Part of the standard (that is optional but supported by most app engines like
Tomcat,
JBoss, etc...) is to have a mechanism that allows one webapp context talk to another. Generally, this has to be explicitly turned on. E.g., in Tomcat, the webapp context xml has to have an attribute set to true (crosscontext=true or something like that).
If two contexts have this enabled, you can write code like:
This will cause the "/myCode/someServletOrJsp" code in the "anotherWebapp" to be run IN THAT WEBAPP's CONTEXT and the results returned to the calling context. All of the attributes and other information in both the request and response objects are sent and returned. So this can be used to pass info back and forth.
Note that this isn't a redirect, all the information is passed back and forth within the servlet container.
In my case, I add some code to my jForum web context that where called by admin code in my main app to add forums, etc. The code in the jForum context was basically a slightly modified version of jForum's main action methods. It just translated stuff from my passed info into what jForum needed at the code level.
JamesR wrote:
Re HTTPClient, do you mean interacting with JForum by issuing HTTP requests to jforum, i.e. the main web app pretends to be filling in one of the form pages in jforum, so would have to simulate login etc.?
Yes, sort of a poor man's Restfull API. Apache's HTTPClient makes this fairly easy.
JamesR wrote:
In my test environment I already have a jforum webapp using the ROOT webapp SiteMesh decorators (i.e. cross-context). However the main webapp has a large API behind it with its own persistence (and caching). What I had in mind was that the persistence layer for the main webapp would make API calls into jforum to replicate changes to users etc.
Perhaps I should explain a little of the background: my existing site already has users who have profiles etc. There's a forum, an image gallery, store etc almost all of which is bespoke. I'm hoping to use jforum so that I can do away with the bespoke forum. However I am also trying to avoid merging the two applications and instead keep jforum in its own "jforum" web context independently of "ROOT". I would prefer to avoid merging the projects, but perhaps that would be the best approach and then I can achieve exactly what I want, admittedly at the expense of not being able to upgrade jforum easily?
If I merge jforum into my main webapp, I will end up modifying jforum so that the jforum servlet is mapped to /jforum/* and not to /*.page - doing this keeps jforum neatly separated from the rest of the application. (I'll also end up moving all its folders into a WEB-INF/jforum/ so they don't conflict or get muddled up with folders already in the application.). But it would be shame to do all that when it's probably not of interest to anyone else!
Any advice or suggestions would be most gratefully received!
I had about the same situation. There are a lot of way to do this. What I ended up doing was:
Keeping jForum in it's own webapp (easier to upgrade/maintain)
Implimented an SSO system with my existing app security.
Created a modified UserDAO implimentation that populated jForum's user objects with applicable data from my apps tables and stuff from jForum's user tables (that I didn't have/need in my app). FWIW, I was lucky enough that my apps "groups" would map nicely into jForum's syntax... but it was still a struggle to find and fix all the various DAO parts for this...
I modified the jforum templates to just return the "content" info (e.g., the white part of this page).
Then I used IFrames with Javascript resizing to integrate it with my existing apps look and feel.
I also used the cross context calls to create the subset of admin functions in my main app that I needed (and simplified it for my admins by limiting choices, etc.).
The "trickiest" part of this was when I had to deal with jForum's permissions to populate group security rules...(stutters at memory)..
IMHO, the nice part of this is that the jForum code is basically the same as the distro and I don't have a lot of code that needs to be updated each time a new version comes out.
[originally posted on jforum.net by monroe]