[hunchentoot-devel] developing in hunchentoot

Eric Abrahamsen girzel at gmail.com
Tue Mar 10 13:35:24 UTC 2009


On Mar 10, 2009, at 6:58 PM, Edi Weitz wrote:

> On Tue, Mar 10, 2009 at 11:04 AM, Vsevolod <vseloved at gmail.com> wrote:
>
>> Maybe he is referring to the fact, that after redefining the  
>> DISPATCHER, the
>> running server's dispatch table remains unchanged.
>
> I don't think so.  He said that each time he redefines an easy handler
> a new entry is added.

Sorry, nothing mysterious is happening. My stupid helper macro  
includes a create-prefix-dispatcher call and a push to *dispatch- 
table*, so obviously it pushes something new to the *dispatch-table*  
every time I call it. Using a plain old defun to redefine an existing  
handler does exactly what it should – my problem was a confusion about  
how lisp works, not about how hunchentoot works, and I apologize for  
the noise.

Back to mucking about,
Eric


>
>> In the sense, that the
>> server continues to use the dispatcher closures, created at the  
>> time of the
>> server start. At least for me it works this way (in old  
>> Hunchentoot): when I
>> redefine a dispatcher, I need to modify the dispatch table (or  
>> plainly
>> restart the server) for the change to take effect.
>>
>> To clarify, I'd like to add, that I refer to the handler functions  
>> as per
>> the docs (e.g. html-generation functions). They take no arguments  
>> and are
>> responsible for forming the reply object. If you redefine them, it  
>> has
>> immediate effect. Dispatchers are the closures in the dispatch- 
>> table, that
>> take 1 argument -- request. If you redefine the dispatcher (for  
>> example,
>> with define-easy-handler, or manually), somehow, it doesn't effect  
>> the
>> running server's dispatch-table.
>
> That shouldn't be the case with the 1.0.0 version.  See how
> list-request-dispatcher works.
>
> Edi.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel





More information about the Tbnl-devel mailing list