Re: [Resin-interest] Resin 3.1.1 and Struts iterate tag problems
Thanks Jason. I'm now trying this with Resin 3.1.2. However, it's taking a painfully long time to start up - of the order of one hour, where Resin2x and Resin 3.1.1 take 1-2 minutes to startup with the app deployed. Is this related to the new startup listen() change in resin 3.1.2? I'm using the default resin.conf file. Thanks, Ambar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Wang Sent: Tuesday, September 11, 2007 7:33 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin 3.1.1 and Struts iterate tag problems 3.1.2 is ok, I tested iterate page in struts example project both on 3.1.1 and 3.1.2 the exception occurs on 3.1.1 but does not occur on 3.1.2 On 9/11/07, Jason Wang [EMAIL PROTECTED] wrote: Resin 3.1.1 doesn't allow to nest jsp statement in a taglib, I don't know why, maybe just a bug, you can try 3.1.2 Jason On 9/10/07, Ambar Hegde [EMAIL PROTECTED] wrote: Hi, I'm trying to move an existing application from Resin 2x to Resin 3.1.1, with JDK 1.5. The application uses Struts 1.1, however the problem persists with Struts 1.3.8 as well. Using the iterate tag from struts-logic.tld causes resin to throw the following error: /jsp/LocationReportMain.jsp:246: not a statement [19:36:22.319] java.lang.Integer null; [19:36:22.319] ^ [19:36:22.319] /jsp/LocationReportMain.jsp:246: ';' expected [19:36:22.319] java.lang.Integer null; [19:36:22.319] ^ The source jsp is: logic:iterate id=driverValues name=SingleUserLocReportInitializer property=teamMembers type= java.util.Hashtablehtml:option value='%=driverValues.get(USER_ID).toString()%' %=driverValues.get(NAME).toString()%/html:option/logic:iterate Would appreciate any help on this. TIA -Ambar ___ 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
[Resin-interest] Filters are not run when using rewrite-dispatch forward
Hi, Filters are not run when requests are forwarded with rewrite-dispatch. According to these bug reports it's fixed in 3.1: http://bugs.caucho.com/view.php?id=1510 http://bugs.caucho.com/view.php?id=1514 Are there any plans to patch this into 3.0? Regards, Jonas ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1.1 and Struts iterate tag problems
Thanks Jason. I'm now trying this with Resin 3.1.2. However, it's taking a painfully long time to start up - of the order of one hour, where Resin2x and Resin 3.1.1 take 1-2 minutes to startup with the app deployed. Is this related to the new startup listen() change in resin 3.1.2? I'm using the default resin.conf file. There should not be such a difference in startup between those two versions. Actually, I think there was some work done to make the startup of 3.1.2 a bit faster. Obtaining a thread dump from the process while it is doing whatever it is doing during startup that is taking so long would be helpful. Sometimes it's beneficial to get 2 thread dumps, a few seconds or a minute apart. Some documentation about thread dumps: http://www.caucho.com/resin-3.1/doc/troubleshoot.xtp#thread-dump You can also use the startup logging to get a general idea of what is taking so long. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Classpath problem
Hi Joe, Thanks, I did remove it. Not that it helped ;) There was more to the messages, basically going down the list of classes that were undefined. I have changed the package the servlet is in to be in the same hierarchy as others being run and that has somehow resolved this issue, even though the rest of the servlets don't use the apache commons. I have no idea why it's now working again, but I'll be grateful for it. Thanks for the help! Janene McCrillis -- Message: 3 Date: Mon, 10 Sep 2007 08:46:22 -1000 From: Joe Dane [EMAIL PROTECTED] Subject: Re: [Resin-interest] Classpath problem To: General Discussion for the Resin application server resin-interest@caucho.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I will reiterate Daniel's good advice: never put application libraries/classes in the global classpath, unless you are absolutely certain you know what you're doing. Even then, you probably should avoid the practice. As to your particular problem, I notice that the error message seems a bit odd: On Sep 7, 2007, at 10:32 AM, Janene McCrillis wrote: The resin error log file shows this: [2007/09/07 14:05:59] Unresolved compilation problems: The import org.apache cannot be resolved Is that the entire message? That would seem to indicate not a library problem at all, but a compilation problem. In particular, that you've got the nonsensical statement import org.apache somewhere. Actually, I've noticed something that I consider fascinating, which is that when I do an over-hasty compile/deploy and I miss the fact that one of my Java classes has compilation errors, resin (which has no access to the source) presents me with an error message like the one above, and includes an error message from the *compiler*. Fascinating, because it seems to mean that even though the compile failed, the compiler produced some sort of object code which indicates the error, and the loading JVM is able to read that code and recreate the compiler message. -- joe ** ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] 64-bit Windows and Resin Pro 3.0.21
We currently have Resin Pro 3.0.21 running on Windows 2003 Server and are considering upgrading to 64-bit. When we try this configuration on a test machine, we get a Resin message saying, Socket JNI library is not available, which means that we don't have the 64-bit DLL's for resin. There are instructions on how to compile Resin in 64-bit for *nix, but nothing for windows. Are those available for Resin Pro 3.0.21? If so, how can I get them? Or can we build them ourselves? I saw a couple references in google to bugs.caucho.com, but that's currently down. The cached page says it's fixed in 3.1.1. Does that mean in order to get 64-bit support for Windows, we must upgrade to Resin 3.1.1? Rob ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Bamboo 1.2.2 extremly slow on resin 3.1.2
Hi, I was trying to setup atlassian bamboo on resin 3.1.2 but it ran extremely slow, page load time roughly a minute for each page and cpu usage constantly at 100%. Tested on RHEL 4 and Mac OS. This issue seems to be fixed in the latest 3.1 snapshot and it doesn't exist in 3.1.1 or 3.0.24. Just out of curiosity what might cause this issue in 3.1.2? I couldn't find anything in the changes list that could potentially cause the problem. Also, when can we expect the 3.1.3 release out the door? Cheers, Henric -- .henric.larsson. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] resin-pro-3.1.s070910 / IllegalStateException / Can't call getEntrySet()
Hi, I still get this Exception after invalidating a Session and redirecting to the Login-Page: ---8--- [06:30:09.030] java.lang.IllegalStateException: Can't call getEntrySet() when session is no longer valid. [06:30:09.030] at com.caucho.server.session.SessionImpl.getEntrySet(SessionImpl.java:1198) [06:30:09.030] at com.caucho.server.session.SessionImpl.store(SessionImpl.java:1127) [06:30:09.030] at com.caucho.server.session.SessionManager.store(SessionManager.java:1601) [06:30:09.030] at com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:402) [06:30:09.030] at com.caucho.server.session.SessionImpl.save(SessionImpl.java:906) [06:30:09.030] at com.caucho.server.connection.AbstractHttpRequest.saveSession(AbstractHttpRequest.java:2428) [06:30:09.030] at com.caucho.server.connection.AbstractHttpResponse.sendRedirect(AbstractHttpResponse.java:614) [06:30:09.030] at org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:214) [06:30:09.030] at org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:67) [06:30:09.030] at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:288) [06:30:09.030] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) [06:30:09.030] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:74) [06:30:09.030] at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:159) [06:30:09.030] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:177) [06:30:09.030] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:241) [06:30:09.030] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:264) [06:30:09.030] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:547) [06:30:09.030] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:685) [06:30:09.030] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:607) [06:30:09.030] at java.lang.Thread.run(Thread.java:619) ---8--- Is this still a timing issue (bugtrack says it should be fixed)? Or do I have to look elsewhere? Regards, --- Jan. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
