The Solution (my hack)
To get around this problem, I located the login.jsp in the Web Content folder of the Web project and pulled it up in edit, as in Figure B.

FIGURE B


Bring up the login.jsp file in the editor. Roll over picture for a larger image.

I replaced the existing action parameter on the form statement with "j_security_check", see Figure C, saved the file, and gave it a go.

FIGURE C


The login.jsp file after the correction. Roll over picture for a larger image.

This time, when I entered my LDAP (Lightweight Directory Access Protocol) credentials, instead of the blank screen I found myself looking at the Edit Weblog data entry panel you see in Figure D.

FIGURE D


Success at last (well, sort of). Roll over picture for a larger image.

So far, so good. However, just like with the removal of the session listener from the TLD, I have no idea what functionality I broke by essentially bypassing the Roller component that performed pre-processing before invoking the security servlet.

Something important may have been going on during that process, but once I set up the form to post directly to j_security_check, whatever that something might have been was no longer in the loop. Maybe it would work; maybe it wouldn't.

Since I found myself on the Edit Weblog page, I decided to go ahead and enter some test data and try to post to the database. After all, just because I got the screen to finally come up doesn't necessarily mean that it would actually work.

I entered a title and a couple of lines of text and submitted the form -- and it worked. You can see the results in Figure E.

FIGURE E


Posting a blog entry works. Roll over picture for a larger image.

I was starting to feel pretty good again, and more than a little adventurous, so I started clicking on the tabs and menu options, just to see what kinds of features and functions this product contained. That was going pretty well and I was just about to proclaim victory over the whole process when I made the mistake of clicking on just one more option.

The next thing I knew, I was looking at yet another error screen, shown in Figure F.

FIGURE F


OK, so not everything is working just yet. Roll over picture for a larger image.

Here We Go Again!
As what was fast becoming the norm with this project, there were no telltale signs of the source of the error. No error message, no stack trace, no exception, no log messages -- nothing. I just hate it when that happens!

My first thought, of course, was that bypassing the Roller component during the authentication process probably disabled some critical element that was only used for a few functions, but was absolutely necessary for those functions to operate. OK, my very first thought was to step out into the backyard and beat myself over the head with a 2x4 for ever starting this project, but that only lasted a few seconds, and it wasn't going to solve the problem, so I don't really count that one.

I won't bother to get into all of the things that I tried in an effort to get that original Roller process back in the loop, particularly since it turned out that it had absolutely nothing to do with the problem.

Eventually, I ended up clicking around in the application and discovered there was more than one option that resulted in this error. I went back out to the Roller site, pulled some more code out of CVS, and and began throwing in debug statements to see if I could nail down the source of the problem.