Re: [Resin-interest] Moving from Tomcat, getting No forwarding URI for form
Hey Pat, I'd stick with Tomcat. Resin has some excellent features that can't be found anywhere else (full EJB 2.0 and PHP support for one, and remarkably easy to use configuration files), but Tomcat is now a de facto standard and extremely well supported by an enormous community. I would wager you'd get more help with your question on tomcat-users(http://tomcat.apache.org/lists.html :) But really Tomcat's much larger user base is it's biggest selling point. Tomcat is extremely well tested, and my own travails with Resin's JSTL support show how important community testing is. I really wanted my company to move to Resin 3.0 but it just couldn't cut the mustard, so we stayed with Tomcat. I'm still hopeful, though, that Resin will emerge as the fastest bestest most featureful Java app server out there. It's classloaders, built-in XSLT engine, and easy configuration are not to be found elsewhere, and it's too bad I have to sacrifice these remarkable features just to get *reliable* compatibility with the full range of JavaEE specifications. Peace, Josh On 5/8/07, Pat Farrell [EMAIL PROTECTED] wrote: I had a set of pages working perfectly with Tomcat, and am trying to move them to Resin. My /j_security_check servlet seems to be blowing up with the following response javax.servlet.ServletException: No forwarding URI for form authentication. Either the login form must specify j_uri or the session must have a saved URI. I'll do either, but don't see how I am supposed to specify either. Pointers would be greatly appreciated. Thanks Pat -- Pat Farrell http://www.pfarrell.com/ ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin plugin for Eclipse?
On 3/7/07, Daniel López [EMAIL PROTECTED] wrote: We create the .project structure so it points to our build directories through virtual links (so the built artifacts do not end up in the source directory) and with that and calling Ant from inside Eclipse, it's enough for us. I'm not sure I understand this part. Can you elaborate a bit more? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question on db based distributed session
Corrections below: On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: ... While there are [[hacky]] ways to notify the offline server of state changes ... How can you have your cake and eat it too? You need some way for nodes to see if they are participating in a distributed session [[on startup]] and if they are and if there is an active node, ignore any persisted session state and get state from the distributed session. If there is no active node, then load session from disk. ... Peace, Josh ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question on db based distributed session
Hmm. I was reading: http://www.caucho.com/resin-3.1/doc/tcp-sessions.xtp Particularly the section under recovery which states: When Host C restarts, possibly with an upgraded version of Resin, it needs to use the most up-to-date version of the session; its file-saved session will probably be obsolete. When a new session arrives, Host C loads the saved session from both the file and from Host D. It will use the newest session as the current value. Once it's loaded the new session, it will remain consistent as if the server had never stopped. So Resin actually implements have your cake and eat it too but it's not working in your case. Perhaps there is some error when the comparison is made - perhaps the clocks on the two systems are not in sync. Or something. :) Peace, Josh On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: Corrections below: On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: ... While there are [[hacky]] ways to notify the offline server of state changes ... How can you have your cake and eat it too? You need some way for nodes to see if they are participating in a distributed session [[on startup]] and if they are and if there is an active node, ignore any persisted session state and get state from the distributed session. If there is no active node, then load session from disk. ... Peace, Josh ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] JSTL issue with Resin 3.0.22
Hi,
I'm evaluating Resin as an alternative to JBoss. I'm particularly fond
of it's fast startup times and terse yet readable configuration files.
However, I'm concerned that one of my test applications fails to work
giving me an error.
In particular, I have a JSP that contains the following:
c:import url=program.jsp var=xresponse scope=page
c:param name=xml
c:out value=${fn:trim(xrequest)}
escapeXml='false'/
/c:param
/c:import
x:parse doc=${fn:trim(xresponse)} var=parsedresponse/
That last line generates the error:
500 Servlet Exception
/prototype/user/create/index.jsp:101: unexpected attribute `doc' in x:parse
com.caucho.jsp.JspLineParseException: /prototype/user/create/index.jsp:101:
unexpected attribute `doc' in x:parse
at com.caucho.jsp.java.JspNode.error(JspNode.java:1480)
at com.caucho.jsp.java.JspNode.error(JspNode.java:1471)
at com.caucho.jsp.java.GenericTag.fillAttributes(GenericTag.java)
at com.caucho.jsp.java.CustomTag.generate(CustomTag.java)
at
com.caucho.jsp.java.JspContainerNode.generateChildren(JspContainerNode.java:439)
at com.caucho.jsp.java.JstlCoreIf.generate(JstlCoreIf.java:137)
at
com.caucho.jsp.java.JspContainerNode.generateChildren(JspContainerNode.java:439)
at com.caucho.jsp.java.JspTop.generate(JspTop.java:239)
at
com.caucho.jsp.java.JavaJspGenerator.generate(JavaJspGenerator.java:635)
at
com.caucho.jsp.java.JavaJspGenerator.generate(JavaJspGenerator.java:502)
at
com.caucho.jsp.JspCompilerInstance.generate(JspCompilerInstance.java:477)
at
com.caucho.jsp.JspCompilerInstance.compile(JspCompilerInstance.java:373)
at com.caucho.jsp.JspManager.compile(JspManager.java:233)
at com.caucho.jsp.JspManager.createPage(JspManager.java:177)
at com.caucho.jsp.JspManager.createPage(JspManager.java:157)
at com.caucho.jsp.PageManager.getPage(PageManager.java:248)
at com.caucho.jsp.PageManager.getPage(PageManager.java:166)
at com.caucho.jsp.QServlet.getSubPage(QServlet.java:292)
at com.caucho.jsp.QServlet.getPage(QServlet.java:210)
at
com.caucho.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:206)
at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:133)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520)
at com.caucho.util.ThreadPool.run(ThreadPool.java:442)
at java.lang.Thread.run(Thread.java:595)
Resin-3.0.22 (built Mon, 13 Nov 2006 09:32:38 PST)
===
This code works in Tomcat 5.5.
I did a bit of searching and wanted to try the turn of fast jstl as
a workaround. Two issues here:
1) The documentation on this configuration option appears to be wrong.
Consider what http://www.caucho.com/resin-3.0/jsp/jstl.xtp says:
caucho.com
http-server
jsp fast-jstl='false'/
...
/http-server
/caucho.com
Where do these tags appear in resin.conf? They don't. A Google search turned up:
http://www.simongbrown.com/blog/2005/06/20/disabling_fast_jstl_on_resin_3_0_x.html
which indicates it can go into webapp. So I did that, but
2) Adding this configuration doesn't fix the problem. The doc
attribute of x:parse is most certainly supported by JSTL 1.1:
http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html
-
Interestingly, I just checked and realized that I had configured
Tomcat with JSTL at the container level, and so this project does not
contain the jstl.jar and standard.jar. I'm going to try adding these
next (and adding the taglib declaration to web.xml). But I see this as
a seperate bug in Resin: if I disable fast jstl, I would expect the
application to fail faster with a taglib not found type of error.
I am very much hoping that there is some oversight on my part. I do
not like JBoss's baroque configuration at all and would very much like
to convince my peers that Resin is the way to go.
Kind regards,
Josh Rehman
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
