Hi Edi,
I'm on Linux/Ubuntu 9.10 i386-64. The problem occurred while trying to get weblocks-demo up and running. That is, this specific problem seems to occur (most consistently) when I purposely request a non-existing URL after having loaded and started weblocks-demo.
After haveing tweaked hunchentoot slightly to expose the problem more, I'm seeing the call-stack below. #P"/home/frode/cvs/lib/asdf/weblocks/pub/" is indeed an existing directory. And, funnily enough:
TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") (pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) NIL NIL
..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way?
#P"/home/frode/cvs/lib/asdf/weblocks/pub/" is supposed to denote a directory. :UNSPECIFIC :UNSPECIFIC [Condition of type HUNCHENTOOT:PARAMETER-ERROR]
Restarts: 0: [ABORT] Quit process.
Backtrace: 0: (SUBFUNCTION 2 (METHOD HUNCHENTOOT:PROCESS-REQUEST (T))) (#<HUNCHENTOOT:PARAMETER-ERROR 40500858AB>) 1: SIGNAL (#<HUNCHENTOOT:PARAMETER-ERROR 40500858AB> &REST NIL) 2: CONDITIONS::CONDITIONS-ERROR (:INVISIBLEP ..) 3: ERROR (HUNCHENTOOT:PARAMETER-ERROR &REST (:FORMAT-CONTROL "~S is supposed to denote a directory. ~S ~S" :FORMAT-ARGUMENTS (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC))) 4: HUNCHENTOOT:PARAMETER-ERROR ("~S is supposed to denote a directory. ~S ~S" &REST (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC)) 5: HUNCHENTOOT:CREATE-FOLDER-DISPATCHER-AND-HANDLER ("/weblocks-common/pub/" #P"/home/frode/cvs/lib/asdf/weblocks/pub/" &OPTIONAL NIL) 6: WEBLOCKS::WEBLOCKS-DISPATCHER (#<HUNCHENTOOT:REQUEST 405007DED3>) 7: HUNCHENTOOT::LIST-REQUEST-DISPATCHER (#<HUNCHENTOOT:REQUEST 405007DED3>) 8: (METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) (#<HUNCHENTOOT:REQUEST 405007DED3>) 9: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 10: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) ..) 11: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 12: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 13: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) ..) 14: (METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) (#<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 8080)> 8) 15: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 16: (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) (:DONT-KNOW) 17: SYSTEM::%%FIRST-CALL-TO-STACK NIL
Thanks, Frode
Edi Weitz edi@agharta.de writes:
What OS are you on? I just checked and this seems to work as expected on my machine with LWW and LWL.
Also, how exactly did you specify/generate the value for base-path?
Cheers, Edi.
On Mon, Nov 9, 2009 at 3:48 PM, Frode V. Fjeld frode@netfonds.no wrote:
Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me.
It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory.
TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2"
Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned.
-- Frode V. Fjeld
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel