This is just *strange*. I'm working on converting a servlet that has
hardwired vectors of values to read those values from a
database. Given that this is simple, I'm using clojure.contrib.sql and
an sqlite plugin. Those vectors get walked in the init code to create
the hashmap that drives page rendering and any actions the servlet takes.
The code change plan is:
1a) Convert vector of vector of strings to vector of hashmaps from
keyword to strings.
1b) Tweak processing function in walk call to use :keys to destructure
instead of vector destructuring.
2) Test and commit these changes.
3) Replace reference to hardwired vectors with call to
with-query-results to read in essentially the same data.
4) Test and commit these changes.
Ok, I started with a working servlet. I started seeing oddball
tracebacks after after doing steps 1a & 1b - no new libraries
involved. I can reproducibly but get tracebacks, but some parts of the
servlet work fine. The tracebacks look like:
java.lang.RuntimeException: java.lang.NullPointerException
at clojure.lang.LazySeq.sval(LazySeq.java:47)
at clojure.lang.LazySeq.seq(LazySeq.java:56)
at clojure.lang.RT.seq(RT.java:450)
at clojure.core$seq.invoke(core.clj:122)
at clojure.core$r.invoke(core.clj:793)
at clojure.core$reverse.invoke(core.clj:806)
at clj_stacktrace.core$trim_redundant.invoke(core.clj:86)
at clj_stacktrace.core$parse_cause_exception.invoke(core.clj:104)
at clj_stacktrace.core$parse_exception.invoke(core.clj:122)
at ring.middleware.stacktrace$html_ex_view.invoke(stacktrace.clj:25)
at ring.middleware.stacktrace$html_ex_response.invoke(stacktrace.clj:40)
at ring.middleware.stacktrace$ex_response.invoke(stacktrace.clj:51)
at
ring.middleware.stacktrace$wrap_stacktrace$fn__1571.invoke(stacktrace.clj:61)
at
ring.util.servlet$make_service_method$fn__1842.invoke(servlet.clj:117)
at x10.war$_service.invoke(war.clj:19)
at x10.war.service(Unknown Source)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
The only place it runs through my code (as opposed to the libraries)
are the two "at x10.war" lines. But that's just setup cod to get ring
to invoke my handler. If I'm reading this right, the actual handler
code isn't even being run.
What's odd is that nothing outside the initialization code has
changed. Worse yet, this doesn't happen on the first - or even second
- access to the servlet. So long as I do nothing but render HTML, it
all works fine. The first time I actually try and use the servlet to
do something, the result page renders fine (but nothing happens). Try
and do something again, and I get the above traceback. Invoke the same
servlet with no actions (just render the HTML), and it still works
fine. Try and do something again - the above traceback.
I haven't presented any code because - well, it seems to be
irrelevant. A two-line change (turn a literal vector into a hashmap,
destructuring to match) can cause this. I finally get a version with
the step 1 changes to work, and try the step two changes - and I start
seeing the same problem.
This kind of thing - seemingly trivial changes causing apparently
unrelated code to blow up - would obviously be a pointer issue or
similar - in C (or similar). Except - well, I thought Java was
designed to prevent that kind of thing. And they just don't happen in
LISP-like languages. Only it is. If I were only seeing it with the sql
libraries, maybe it's an issue in those - except I saw pretty much the
same behavior before I was using the SQL code. This is why I think the
code is irrelevant.
I'm pretty much at a loss here - got no idea what to try next. The
most relevant thing google turned up was a bug in the version of
leingingen I was using - it sometimes omitted a class file building
uber[jw]ars (except why does the same thing appear to work once and
not the second time?), so I upgraded lein, which didn't help.
Ok, maybe it's a threading/agent issue. That would explain the "once
but never again" behavior, if the agent got into the FAILED
state. Could that corrupt something that might make jetty and/or ring
fail as above? Except then why do the pages that just render HTML and
not send work to the agent still work? Grrr.
Anyone got any clue bits (any at all) I can borrow?
Thanks,
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
