Re: [Resin-interest] Is there an easy way to do this? port
Jose Quinteiro escribió: Hi, As Jose, I would recommend having different instances for development and deployment. Even though Resin does a good job on separating contexts and detecting changes and restarting just the appropriate web app. You will still affect your deployment applications with the common frequent restarts during development. And as Jose said, you don't need two copies of the whole Resin software, just two config files so you don't have to worry about maintaing/upgrading two full instances. In fact, we use more than one instance even in deployment, as that allows us to handle upgrades/problems more gracefully as applications affected by what happens to others is minimised. Cheers! D. The way I've accomplished this is by having two different instances of Resin, with different conf files. It's easy to do with 3.0.x, a little harder with 3.1.0. HTH, Jose. Vinny wrote: Hi, I am trying figure out a way to do a kind of virtual hosting based on port number. I want my production apps running under port 443 docroot : (/web/production/webapps) and my dev apps running under 8080. docroot : (/web/dev/webapps) both production and dev apps will have the same context names (like ROOT.war for example) I just need resin to differentiate on port number basically. I was thinking perhaps I could nest host/ under http/ but it seems like I will have to make a completely seperate server/ block? Is that really the case? Thanks in advance -- Ghetto Java: http://www.ghettojava.com http://www.ghettojava.com ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Is there an easy way to do this? port
On Feb 2, 2007, at 12:39 AM, Daniel López wrote: Jose Quinteiro escribió: Hi, As Jose, I would recommend having different instances for development and deployment. Even though Resin does a good job on separating contexts and detecting changes and restarting just the appropriate web app. You will still affect your deployment applications with the common frequent restarts during development. True. And as Jose said, you don't need two copies of the whole Resin software, just two config files so you don't have to worry about maintaing/upgrading two full instances. FYI, in Resin 3.1 you could just use one config file and have two separate cluster blocks. The -server foo will select which cluster will be active for that JVM. -- Scott In fact, we use more than one instance even in deployment, as that allows us to handle upgrades/problems more gracefully as applications affected by what happens to others is minimised. Cheers! D. The way I've accomplished this is by having two different instances of Resin, with different conf files. It's easy to do with 3.0.x, a little harder with 3.1.0. HTH, Jose. Vinny wrote: Hi, I am trying figure out a way to do a kind of virtual hosting based on port number. I want my production apps running under port 443 docroot : (/web/production/webapps) and my dev apps running under 8080. docroot : (/web/dev/webapps) both production and dev apps will have the same context names (like ROOT.war for example) I just need resin to differentiate on port number basically. I was thinking perhaps I could nest host/ under http/ but it seems like I will have to make a completely seperate server/ block? Is that really the case? Thanks in advance -- Ghetto Java: http://www.ghettojava.com http://www.ghettojava.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 problems with the jsp taglib
Use different taglib prefix in the included pages, that should do the trick. -Kai On 2/1/07, Murthy ch [EMAIL PROTECTED] wrote: I am new to resin websever.I am facing some problems when i try to use resin as webserver for a webapplication we developed. I am getting the following error when i tried to load the jsp page. [22:57:06.312] Caused by: com.caucho.jsp.JspLineParseException: /jsp/common/taglibs.jsp:1: The taglib prefix 'c' must be defined before any matching p refixes are used. [22:57:06.312] [22:57:06.312] 1: %@ taglib uri=http://java.sun.com/jstl/core_rt; prefix=c % [22:57:06.312] 2: %@ taglib uri=http://java.sun.com/jsp/jstl/functions; prefix=fn % [22:57:06.312] 3: %@ taglib uri=http://java.sun.com/jstl/fmt_rt; prefix=fmt % [22:57:06.312] [22:57:06.312] at com.caucho.jsp.JspParser.error(JspParser.java:1779) [22:57:06.312] at com.caucho.jsp.JspParser.processTaglibDirective(JspParser.java:1345) [22:57:06.312] at com.caucho.jsp.JspParser.parseDirective(JspParser.java:884) [22:57:06.312] at com.caucho.jsp.JspParser.parseScriptlet(JspParser.java:758) [22:57:06.312] at com.caucho.jsp.JspParser.parseNode(JspParser.java:462) [22:57:06.312] at com.caucho.jsp.JspParser.parseJsp(JspParser.java:362) [22:57:06.312] at com.caucho.jsp.JspParser.parse(JspParser.java:255) [22:57:06.312] at com.caucho.jsp.JspCompilerInstance.generate(JspCompilerInstance.java:489) [22:57:06.312] at com.caucho.jsp.JspCompilerInstance.compile(JspCompilerInstance.java:386) [22:57:06.312] at com.caucho.jsp.JspManager.compile(JspManager.java:236) [22:57:06.312] at com.caucho.jsp.JspManager.createPage(JspManager.java:166) [22:57:06.312] at com.caucho.jsp.JspManager.createPage(JspManager.java:146) [22:57:06.312] at com.caucho.jsp.PageManager.getPage(PageManager.java:241) [22:57:06.312] at com.caucho.jsp.PageManager.getPage(PageManager.java:157) [22:57:06.312] at com.caucho.jsp.QServlet.getSubPage(QServlet.java:294) [22:57:06.312] at com.caucho.jsp.QServlet.getPage(QServlet.java:210) [22:57:06.312] at com.caucho.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:233) [22:57:06.312] at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:143) [22:57:06.312] at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:97) [22:57:06.312] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226) [22:57:06.312] at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:279) [22:57:06.312] at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) [22:57:06.312] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1085) [22:57:06.312] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:398) [22:57:06.312] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:241) [22:57:06.312] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) [22:57:06.312] at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) [22:57:06.312] at javax.servlet.http.HttpServlet.service(HttpServlet.java:115) [22:57:06.312] at javax.servlet.http.HttpServlet.service(HttpServlet.java:92) [22:57:06.312] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103) [22:57:06.312] at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:97) [22:57:06.312] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226) [22:57:06.312] at com.caucho.server.webapp.RequestDispatcherImpl.include(RequestDispatcherImpl.java:488) [22:57:06.312] at com.caucho.server.webapp.RequestDispatcherImpl.include(RequestDispatcherImpl.java:353) [22:57:06.312] at org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(ImportSupport.java:296) [22:57:06.312] ... 76 more After looking in to the jsp code what we written, and understand this problem is causing because of we defined jsp tablib directive multiple places. when if we use any tablib references in between the tablib directive declaration we are getting the above error. Basically we are including the some jsp pages in the main page.so we are defining the tablib primitives in the subpages also for Ex: MainPage.jsp -x-x Start of the mainpage.jsp ---x--x [EMAIL PROTECTED] contentType=text/html; charset=UTF-8% %@ taglib uri=http://java.sun.com/jstl/core_rt; prefix=c % %@ taglib uri=http://java.sun.com/jsp/jstl/functions; prefix=fn % %@ taglib uri=http://java.sun.com/jstl/fmt_rt; prefix=fmt % @include file=/jsp/include/Menu.jsp@ -x-x-end of the mainpage.jsp
Re: [Resin-interest] Odd problem with JSP recompile
On Feb 2, 2007, at 4:37 PM, Gerry Panganiban wrote: The dependency list looks correct. The tag files I am changing are listed there. Although I noticed that some of the values that are being passed into the lastModified attribute are actually negative (e.g.: -6419312961657006312L) That number's just a CRC. So half of them should be negative. Are you changing the return values for things like doStartTag()? Resin's tag analysis code looks to see what values your tag can return from doStartTag() and generates optimized code based on those values. But the dependency checking code only validates the signatures, not the actual code. So it's possible that Resin isn't detecting your changes because it thinks you haven't done anything significant to the class. Does that sound possible? -- Scott --Gerry --- [EMAIL PROTECTED] wrote: From: Scott Ferguson [EMAIL PROTECTED] To: General Discussion for the Resin application server resin- [EMAIL PROTECTED] Subject: Re: [Resin-interest] Odd problem with JSP recompile Date: Fri, 2 Feb 2007 16:21:46 -0800 On Feb 2, 2007, at 3:21 PM, Gerry Panganiban wrote: This problem has been baffling me for weeks now. We are running resin (somewhat older 3.0.14 release) and I'm seeing something strange. Much of our application's interface is implemented in JSP 2.0 *.tag files. As part of our build process (using ant), we auto- generate a *.jsp file which is a simple wrapper around a main tag file, which itself embeds many other *.tag files underneath it. Normally, in our development environment, any change in the underlying tag files are detected by resin, which will then recompile the tag and redeploy just the tag files that changed and its 'parent' tags. Can you look at the generated *.java class for the JSP file? It should list the dependencies, which may give an idea why that dependency isn't being detected. -- Scott The problem is that for ONE specific wrapper tag, changes in tags underneath it are never seen by resin and does not trigger a recompile. Our only workaround so far has been to: 1) Stop the resin server 2) Rebuild the entire web app, including the auto-generated wrapper JSPs 3) Copy the entire web app's directory structure to the resin webapps directory 4) Restart the resin server This causes resin to have to *recompile* all the tag and jsp files which can be very time consuming (it takes as long as 30 minutes). What I don't understand is why for EVERY auto-generated wrapper JSP except this one, resin does not detect that a dependent tag file has been changed. I've made sure that resin.conf file has the proper settings (jsp auto-compile=true ... etc ). Another oddity is that this problem only started happening fairly recently. Nothing in the development environment has changed. Can anyone shed some light as to why this might possibly be happening? Thanks! ___ 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 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] Odd problem with JSP recompile
Our tags are just jsp-tag files (*.tag), which I believe do not explictly override the doStartTag() method (there is no such method in the compiled tag's .java file) --- [EMAIL PROTECTED] wrote: From: Scott Ferguson [EMAIL PROTECTED] To: General Discussion for the Resin application server resin-interest@caucho.com Subject: Re: [Resin-interest] Odd problem with JSP recompile Date: Fri, 2 Feb 2007 16:45:02 -0800 On Feb 2, 2007, at 4:37 PM, Gerry Panganiban wrote: The dependency list looks correct. The tag files I am changing are listed there. Although I noticed that some of the values that are being passed into the lastModified attribute are actually negative (e.g.: -6419312961657006312L) That number's just a CRC. So half of them should be negative. Are you changing the return values for things like doStartTag()? Resin's tag analysis code looks to see what values your tag can return from doStartTag() and generates optimized code based on those values. But the dependency checking code only validates the signatures, not the actual code. So it's possible that Resin isn't detecting your changes because it thinks you haven't done anything significant to the class. Does that sound possible? -- Scott --Gerry --- [EMAIL PROTECTED] wrote: From: Scott Ferguson [EMAIL PROTECTED] To: General Discussion for the Resin application server resin- [EMAIL PROTECTED] Subject: Re: [Resin-interest] Odd problem with JSP recompile Date: Fri, 2 Feb 2007 16:21:46 -0800 On Feb 2, 2007, at 3:21 PM, Gerry Panganiban wrote: This problem has been baffling me for weeks now. We are running resin (somewhat older 3.0.14 release) and I'm seeing something strange. Much of our application's interface is implemented in JSP 2.0 *.tag files. As part of our build process (using ant), we auto- generate a *.jsp file which is a simple wrapper around a main tag file, which itself embeds many other *.tag files underneath it. Normally, in our development environment, any change in the underlying tag files are detected by resin, which will then recompile the tag and redeploy just the tag files that changed and its 'parent' tags. Can you look at the generated *.java class for the JSP file? It should list the dependencies, which may give an idea why that dependency isn't being detected. -- Scott The problem is that for ONE specific wrapper tag, changes in tags underneath it are never seen by resin and does not trigger a recompile. Our only workaround so far has been to: 1) Stop the resin server 2) Rebuild the entire web app, including the auto-generated wrapper JSPs 3) Copy the entire web app's directory structure to the resin webapps directory 4) Restart the resin server This causes resin to have to *recompile* all the tag and jsp files which can be very time consuming (it takes as long as 30 minutes). What I don't understand is why for EVERY auto-generated wrapper JSP except this one, resin does not detect that a dependent tag file has been changed. I've made sure that resin.conf file has the proper settings (jsp auto-compile=true ... etc ). Another oddity is that this problem only started happening fairly recently. Nothing in the development environment has changed. Can anyone shed some light as to why this might possibly be happening? Thanks! ___ 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 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 mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
