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.