Pieter wrote:Hello Rafael, have you had time yet to reflect on this approach? I will need to finish a working implementation in about a month, so time is starting to become an issue.
So do you mind if I commit my changes in the main source tree?
I will adhere to the following rules:
- I will signal my changes by clear comments to facilitate a possible rollback in a later stage
- I will make all changes depend on configuration option(s) so the semantics of the "normal" situation are left completely intact.
- I will try to implement most changes in separate classes/interfaces to avoid clutter in the main source tree.
If a player is logged in our game platform, it should only require the push of a button to enter the forum without the need to enter a name or password again.
Members will be able to change their name in our user database and the forum should pick up these name changes transparently.
Rafael Steil wrote:
Another point was that they didn't want to use the jfourm's login system, but they own. This one resulted on a more elaborated patch, because, in order to use jforum's DataAccessDriver, it is necessary to have the ThreadLocal data ( connection, request and response ) correctly set. So, at JForum.java, we put a public method named configureThreadLocal(Conneciton, HttpServletRequest, HttpServletResponse), so then they use this method *before* accessing jforum's stuff. Probably I'll put this method in the cvs too.
Anonymous wrote: Why didn't JForum rely upon the servlet containers authorization mechanisms? It would make JForum much more usefull as an add on option to existing sites.
We don't have time for this. We've gotta save the moon! Or check this out:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton