Hunchentoot 1.2, *DEFAULT-HANDLER* and suggested rework of default

[Ury Marshak]

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
2. There's a need in production to have a different default
application than weblocks' standard. Hence the variable *WEBLOCKS-
DEFAULT-APP-NAME*. Set it to the symbol naming your weblocks app to
make it default.
3. It might be necessary to make default application depend on the
situation (for example the name of the virtual host to which the
request is made). So there's a variable *WEBLOCKS-DEFAULT-APP-NAME-
FN*, that can be set to a function taking request object and returning
symbol naming an application.

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 --git a/src/acceptor.lisp b/src/acceptor.lisp
index 347222d..9f96940 100644
--- a/src/acceptor.lisp
+++ b/src/acceptor.lisp
@@ -1,7 +1,7 @@

(in-package :weblocks)

-(export '(weblocks-acceptor))
+(export '(weblocks-acceptor *weblocks-default-app-name* *weblocks-
default-app-name-fn*))

(defclass weblocks-acceptor (#.(if (find-class 'easy-acceptor nil)
'easy-acceptor
@@ -22,3 +22,25 @@
(let ((*print-readably* nil))
(call-next-method)))

+(defvar *weblocks-default-app-name* 'weblocks-default)
+
+(defvar *weblocks-default-app-name-fn* (lambda (request)
+ (declare (ignore request))
+ *weblocks-default-app-
name*))
+
+
+(defmethod acceptor-dispatch-request ((acceptor weblocks-acceptor)
request)
+ "Like easy-acceptor's method, but in the end call/start our default
app"
+ (loop for dispatcher in *dispatch-table*
+ for action = (funcall dispatcher request)
+ when action return (funcall action)
+ finally
+ (if (null (tokenize-uri (script-name*) nil))
+ (let* ((webapp-name (funcall *weblocks-default-app-
name-fn* request))
+ (webapp (or (get-webapp webapp-name nil)
+ (start-webapp webapp-name))))
+ (redirect (weblocks-webapp-prefix webapp)))
+ (call-next-method))))
+
+
+

[Daniel Borchmann]

Hi Ury,

thanks for this! But I do not know whether we should care about
backwards compatibility with Hunchentoot 1.1.0? Your code wouldn't work
with it.

Best,
Daniel

--
Daniel Borchmann http://daniel.kxpq.de
GPG (Mail) 04A9 66A1 A17C C91E 39B5 8722 69B0 E96D A109 8F58

[Leslie P. Polzer]

On Dec 5, 8:11 am, Daniel Borchmann <daniel.borchm...@mailbox.tu-

dresden.de> wrote:
> Hi Ury,
>
> thanks for this!  But I do not know whether we should care about
> backwards compatibility with Hunchentoot 1.1.0?  Your code wouldn't work
> with it.

Backwards compatibility is nice to have and will save a lot of
headaches,
but a backwards incompatible patch is acceptable to start with.

Leslie

[Willem Rein Oudshoorn]

Ury Marshak <ury.m...@gmail.com>
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.

[Leslie P. Polzer]

Added this patch with some minor reformatting.

On Jan 4, 9:39 pm, Willem Rein Oudshoorn <wouds...@xs4all.nl> wrote:
> Ury Marshak <ury.mars...@gmail.com>

> 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/updatesand here is