On 11/15/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > After looking at the RequestFilter more carefully, is there any reason we > even need that filter anymore? > > >From the code it appears this filter does 3 things ... > > 1. pre-emptively create a RollerRequest object > 2. create a login cookie for users that want it > 3. set the update time in the request !? > > I think we can easily scratch 1 & 3 off as items that should be done by > whatever servlet or struts action is handling the request. We shouldn't need > to do that work ahead of time. > > Then if we move #2 somewhere else we should be fine. I also think that step > 2 will probably be going away when we switch to Acegi security.
Yes, most of the logic in this class is removed by the Acegi integration. I can upgrade my patch to Acegi 0.9.0 if there's enough interest. Matt > > Anyone opposed to the removal of the RequestFilter? This would be a Roller > 2.1 change. > > -- Allen > > > On Tue, 2005-11-15 at 04:39, Matthew P. Schmidt wrote: > > The request filter may not be dispatched for forwards. We had to do > > that for some filters. > > > > -Matt > > > > Allen Gilliland wrote: > > > > > > > > > > > Dave Johnson wrote: > > > > > >> > > >> On Nov 14, 2005, at 11:10 AM, Matthew Schmidt wrote: > > >> > > >>> Just a followup, it could be that the frontpage lists old entries > > >>> because it can only find one user with a handle and so is only > > >>> listing those users. If you hit it in the next hour or so, > > >>> http://rr.javalobby.org:20900 should be up for testing. It also > > >>> appears that hitting the site from 'links' on linux redirects > > >>> properly, while firefox does not. As I said, a hard redirect to > > >>> main.do is probably not a good thing and unless I changed Jroller > > >>> from the default, I don't think 1.2 did that :) > > >>> > > >>>> Hey guys. We're in the process of trying to migrate to Roller 2.0 > > >>>> and also ran into some of the indices problems. Easily resolved, > > >>>> but there are other issues. > > >>>> > > >>>> 1) Just visiting / doesn't appear to redirect to main.do or forward > > >>>> to main.jsp like it used to. We'd like to not have a hard redirect > > >>>> to main.do as that would screw with our page ranks and indexing > > >>>> with the various search engines. > > >>>> 2) If I do go to /, I get the following error: > > >>> > > >>> > > >> > > >> The main pages need the RequestFilter and since your front page has > > >> no *.do extension, you'll have to map /* to the RequestFilter. That's > > >> sub-optimal because some pages don't need the overhead of the request > > >> filter (e.g. the RSS feeds). > > >> > > >> We want the main pages to go in the page cache, so we map planet.do > > >> and main.do to the PageCacheFilter. Since you arrive at the front > > >> page without main.do in your URL, you won't get any of the normal > > >> caching. > > >> > > >> I don't have a good solution for this problem and we've been running > > >> with the redirect and the *.do URLs for over six months now, so I'm > > >> against changing it for 2.0. Perhaps it could be addressed in the > > >> cache rewrite coming in 2.1. > > > > > > > > > > > > So, it definitely looks like the RequestFilter should be changed to be > > > the last filter in line. It should certainly be behind the caches > > > since we are trying not to hit the db when we are using cached pages. > > > I can try testing this in my dev environment tomorrow. > > > > > > I had also noticed that when you hit the front page via "/" rather > > > than "/main.do" it doesn't seem to get cached. We currently use a jsp > > > forward to servlet dispatch the request from /index.jsp -> /main.do > > > and I would think that would go through the filters, but for some > > > reason it isn't :/ I'll have to play with this a bit to see if there > > > is a reason why, otherwise the only other alternative is the alter the > > > filter mappings. > > > > > > -- Allen > > > > > >> > > >> > > >>>> 3) Hitting main.do gives me a bunch of old entries, back to 2003. > > >>>> > > >>>> 4) The hot blogs list has all blogs listed with a /page as the > > >>>> url, no handle. It appears that none of the blogs have a handle > > >>>> after the upgrade. There also doesn't appear to be anything in the > > >>>> upgrade script that generates them. > > >>> > > >>> > > >> > > >> This is troubling. Has anybody else run into this problem of the > > >> upgrade script not creating handles? > > >> > > >> > > >>>> 5) If I login as one of the users, it doesn't think I have any > > >>>> weblogs, when I clearly did before. > > >>> > > >>> > > >> > > >> And not creating weblog-user relationships? > > >> > > >> That looks like an upgrade problem too, but it's going to be > > >> difficult to diagnose if we can't reproduce. You do have a customized > > >> Roller 1.2 installation. How close was your old database to the stock > > >> Roller 1.2? > > >> > > >> - Dave > > >> > >
