Ury Marshak <[email protected]> writes: > This is a slight rework of the way weblocks handles default > application. > Motivations for the change are as follows: > > 1. Hunchentoot 1.2 does not support *DEFAULT-HANDLER* - needs the > update [text snipped]
> I'm also posting these changes with some other bugfixes and updates > for Hunchentoot 1.2 in my clone of weblocks here: > https://github.com/ury-marshak/weblocks-dev/tree/updates and here is > the diff (for this change): > [diff removed] Unfortunately this patch does not work for me at all. The reference to hunchentoot:*default-handler* is still there in server.lisp. What works as a temporary solution for me is removing the following code from server.lisp ;; Redirect to default app if all other handlers fail (setf hunchentoot:*default-handler* (lambda () (if (null (tokenize-uri (script-name*) nil)) (progn (unless (get-webapp 'weblocks-default nil) (start-webapp 'weblocks-default)) (redirect "/weblocks-default")) (setf (return-code*) +http-not-found+)))) The effect is that the default-app does not work but my own weblock-apps keep working as before. Obviously this is not a complete fix but as a short stopgap solution this works. In addition I noticed that the log-message function does not exist anymore in the hunchentoot package so the message in weblocks-dispatcher (server.lisp) will trigger a backtrace. Now this is probably well know, I just put it here just in case somehow is looking for a quick fix. Kind regards, Wim Oudshoorn. -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
