> 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
Hi Mike, It appears that you aren't seeing the actual error (whatever it may be) because of a bug in clj_stacktrace. Stu -- 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
