Yes, both with Maven for development and on the server (though I'd really love to switch to Glassfish if I can just figure out the context-in-the-url issue).
Derek Chen-Becker wrote: > Crapola: > > http://jira.codehaus.org/browse/JETTY-958 > > I think I've confirmed that this is not lift. I added a non-lift input > text element to an existing lift form: > > <input name="testthis" type="text" /> > > Then I use the following code, which I believe should be getting direct > access to Jetty's HttpServletRequest instance: > > Log.info("testthis = " + (S.request.map({r => > r.request.getParameter("testthis")}) openOr "not found!")) > > And when I put a cedilla in, I get: > > INFO - testthis = ç > > Can you confirm that you're using Jetty? I also tried the flags listed > in the JIRA ticket: > > -Dorg.mortbay.util.URI.charset=utf-8 -Dfile.encoding=UTF-8 > > But they didn't seem to do anything (it didn't crash, though). I'm not > sure if I specified those correctly for use with the Maven jetty:run > command line: > > mvn -Djetty.port=9090 -Dorg.mortbay.util.URI.charset=utf-8 > -Dfile.encoding=UTF-8 jetty:run > > Anyways, this doesn't look to be Lift's fault. I know that's not a great > answer. I'm trying to think of whether there's a clean, simple way to > "undo" the bogus transform but I don't know enough about charset > handling. One more interesting thing is that if I change my log code to: > > Log.info("testthis = " + (S.request.map({r => > r.request.getCharacterEncoding + r.request.getParameter("testthis")}) > openOr "not found!")) > > I get: > > INFO - testthis = nullç > > Which seems to indicate that the character encoding for the POST isn't > being set. I tried overriding it: > > S.request.foreach{ r => r.request.setCharacterEncoding("UTF-8")} > > and that seems to have absolutely no effect (in fact, I get the same > "null" log message). > > Derek > > On Sun, Mar 15, 2009 at 3:08 PM, Charles F. Munat <c...@munat.com > <mailto:c...@munat.com>> wrote: > > > Marc Boschma wrote: > >> When I use ç instead, the problem is that it is *not* > converted > >> to ç as it goes into the database, and then on the way out the XML > >> interpreter does not recognize it as a character entity reference > >> and so > >> converts the & to &. > > > > I think this is due to using the standard Scala XML load functions > > rather than the lift XML parser. From memory I don't think the > > standard parser recognises that many named entities. ie. does > ç > > work instead of ç ? If so then that is probably what is > > happening on this issue. > > ç goes into the database unchanged, but comes back out as > &#x00E7. For that matter, & in the DB comes out as &amp; on > the page. > > This is actually fine with me. It means that my users can just type &, > <, > etc. and they will appear on the page that way (rather than being > intepreted as HTML tags). It's safer, too. There is no way for them to > insert HTML, especially script tags. > > So really, the only problem I have is that I need to be able to type a ç > and have it still a ç when it gets to the database. > > Chas. > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
