[jira] Assigned: (GERONIMO-573) Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin
[ http://issues.apache.org/jira/browse/GERONIMO-573?page=history ] David Jencks reassigned GERONIMO-573: - Assign To: David Jencks Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin - Key: GERONIMO-573 URL: http://issues.apache.org/jira/browse/GERONIMO-573 Project: Apache Geronimo Type: Improvement Components: deployment Reporter: John Sisson Assignee: David Jencks Priority: Trivial Attachments: WaitForStarted_patch.txt Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin to enable waitForStarted to wait longer to enable the server to be paused during debugging. The default behaviour has not changed (maxTries=40 retryInterval=1000). Patch coming.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-573) Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin
[ http://issues.apache.org/jira/browse/GERONIMO-573?page=history ] David Jencks closed GERONIMO-573: - Resolution: Fixed Fix Version: 1.0-M4 Applied, except I renamed the interval property retryIntervalMilliseconds to encourage people not to set it to 1. Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin - Key: GERONIMO-573 URL: http://issues.apache.org/jira/browse/GERONIMO-573 Project: Apache Geronimo Type: Improvement Components: deployment Reporter: John Sisson Assignee: David Jencks Priority: Trivial Fix For: 1.0-M4 Attachments: WaitForStarted_patch.txt Add optional maxTries and retryInterval attributes to deploy:waitForStarted maven plugin to enable waitForStarted to wait longer to enable the server to be paused during debugging. The default behaviour has not changed (maxTries=40 retryInterval=1000). Patch coming.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-568) Switch system-datasource plan to the derby xa connector
I am working on a patch for switching system-datasource plan to the derby xa connector as well as moving the timer gbeans to the system datasource plan. http://issues.apache.org/jira/browse/GERONIMO-568 I am having a problem where the JDBCStoreThreadPooledNonTransactionalTimer GBean is being invoked before the DerbySystemGBean. The JDBCStoreThreadPooledNonTransactionalTimer constructor creates a new instance of JDBCWorkerPersistence, which then calls the execSQL method in its superclass that opens a database connection, therefore initialising the embedded derby database. One of the problems with this is that the SystemDatabase and derby.log are not created under geronimo\var\derby (since the derby.system.home property is set by the DerbySystemGBean, which hasn't been started yet. Both the timer GBeans have a reference to geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=org/apache/geronimo/SystemDatabase,j2eeType=JCAManagedConnectionFactory,name=SystemDatasource,* The SystemDatasource GBean reference is shown as started in the log before Derby has been initialised. Some options to discuss: * Have the Timer GBeans have a reference to the DerbySystem GBean, so they aren't started until the DerbySystem GBean has started. Do you really want a DerbySystem parameter on the constructor of the Timer GBeans? Even if we do this, it won't stop future GBeans referencing the SystemDatasource when Derby hasn't been initialised. * Have the SystemDatasource Gbean have a reference to the DerbySystem GBean, so the SystemDatasource is not started until the DerbySystem GBean has started. Not sure how this can be done and how practical it is. * Have a new system-derby-plan.xml file with configId=org/apache/geronimo/DerbySystem and parentId=org/apache/geronimo/Server that contains the DerbySystem and DerbyNetwork gbeans . Change the system-database-plan.xml file to have parentId=org/apache/geronimo/DerbySystem. Thanks, John
[jira] Assigned: (GERONIMO-569) StackOverflowError when sending error page
[ http://issues.apache.org/jira/browse/GERONIMO-569?page=history ] Greg Wilkins reassigned GERONIMO-569: - Assign To: Greg Wilkins StackOverflowError when sending error page -- Key: GERONIMO-569 URL: http://issues.apache.org/jira/browse/GERONIMO-569 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: Linux 2.4.28-cpufreq.suspend, jdk5.0 Reporter: Petr Sickboy Hejl Assignee: Greg Wilkins Attachments: jetty-errorpages.patch In reaction on simple jsp page that causes NumberFormatException, defined error page is not sent and geronimo logs StackOverflowException. Any subsequent http request to server returns error page that should be returned before. ---web.xml--- ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; version=2.4 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-name xml:lang=cstest4/display-name welcome-file-list welcome-filewelcome.jsp/welcome-file /welcome-file-list error-page exception-typejava.lang.NumberFormatException/exception-type location/WEB-INF/BadNumber.html/location /error-page error-page error-code404/error-code location/WEB-INF/NoSuchPage.html/location /error-page /web-app ---geronimo.log (part)--- 10:53:03,854 DEBUG [HttpServer] Try WebApplicationContext[/test4,test4],0 10:53:03,854 DEBUG [HttpContext] Handler [EMAIL PROTECTED] 10:53:03,854 DEBUG [ServletHandler] servlet=*.jsp=jsp 10:53:03,855 DEBUG [ServletHttpRequest] Got Session 79ir83g342qjn from cookie 10:53:03,855 DEBUG [ServletHandler] [EMAIL PROTECTED] 10:53:03,855 DEBUG [WebApplicationHandler] chain=jsr154-jsp 10:53:03,855 DEBUG [JspServlet] JspEngine -- /Dates_and_Times.jsp 10:53:03,855 DEBUG [JspServlet]ServletPath: /Dates_and_Times.jsp 10:53:03,855 DEBUG [JspServlet] PathInfo: null 10:53:03,855 DEBUG [ServletHandler] getRealPath of /Dates_and_Times.jsp in [EMAIL PROTECTED] 10:53:03,856 DEBUG [JspServlet] RealPath: /usr/local/ApacheGeronimo/config-store/15/test4.war/Dates_and_Times.jsp 10:53:03,856 DEBUG [JspServlet] RequestURI: /test4/Dates_and_Times.jsp 10:53:03,856 DEBUG [JspServlet]QueryString: null 10:53:03,856 DEBUG [JspServlet] Request Params: 10:53:04,030 DEBUG [Compiler] Using classpath:
[jira] Assigned: (GERONIMO-395) Error for /blojsom/: java.lang.StackOverflowError
[ http://issues.apache.org/jira/browse/GERONIMO-395?page=history ] Greg Wilkins reassigned GERONIMO-395: - Assign To: Greg Wilkins Error for /blojsom/: java.lang.StackOverflowError - Key: GERONIMO-395 URL: http://issues.apache.org/jira/browse/GERONIMO-395 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: Microsoft Windows XP [Wersja 5.1.2600] java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing) CYGWIN_NT-5.1 Shrek 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin Reporter: Shrek the Ogre Assignee: Greg Wilkins Attachments: jetty-errorpages.patch It's a build from the fresh checkout. Before upgrading Jetty to 5.1-SNAPSHOT blojsom (http://blojsom.sf.net) worked well. Now, once blojsom 2.19 has been deployed using the deployer tool, Jetty prints out the following at the first page of blojsom: ... 10:51:22,250 WARN [ServletHandler] Error for /blojsom/ java.lang.StackOverflowError at java.lang.StringBuffer.append(Unknown Source) at org.apache.log4j.helpers.AbsoluteTimeDateFormat.format(AbsoluteTimeDateFormat.java:113) at java.text.DateFormat.format(Unknown Source) at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternParser.java:436) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:56) at org.apache.log4j.PatternLayout.format(PatternLayout.java:495) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:292) at org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:225) at org.apache.log4j.WriterAppender.append(WriterAppender.java:150) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.apache.geronimo.system.logging.log4j.CachingLog4jLog.debug(CachingLog4jLog.java:69) at org.apache.geronimo.kernel.log.GeronimoLog.debug(GeronimoLog.java:66) at org.mortbay.jetty.servlet.Default.getResource(Default.java:189) at org.mortbay.jetty.servlet.Default.service(Default.java:209) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
[jira] Commented: (GERONIMO-569) StackOverflowError when sending error page
[ http://issues.apache.org/jira/browse/GERONIMO-569?page=comments#action_58912 ] Greg Wilkins commented on GERONIMO-569: --- The problem was a bug in jetty where the JSR154 filter was hiding the type of the dispatch. This has been resolved in Jetty CVS with an explicit pass of the dispatch type. A new jetty release will be filtering through maven in the next day or two. StackOverflowError when sending error page -- Key: GERONIMO-569 URL: http://issues.apache.org/jira/browse/GERONIMO-569 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: Linux 2.4.28-cpufreq.suspend, jdk5.0 Reporter: Petr Sickboy Hejl Assignee: Greg Wilkins Attachments: jetty-errorpages.patch In reaction on simple jsp page that causes NumberFormatException, defined error page is not sent and geronimo logs StackOverflowException. Any subsequent http request to server returns error page that should be returned before. ---web.xml--- ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; version=2.4 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-name xml:lang=cstest4/display-name welcome-file-list welcome-filewelcome.jsp/welcome-file /welcome-file-list error-page exception-typejava.lang.NumberFormatException/exception-type location/WEB-INF/BadNumber.html/location /error-page error-page error-code404/error-code location/WEB-INF/NoSuchPage.html/location /error-page /web-app ---geronimo.log (part)--- 10:53:03,854 DEBUG [HttpServer] Try WebApplicationContext[/test4,test4],0 10:53:03,854 DEBUG [HttpContext] Handler [EMAIL PROTECTED] 10:53:03,854 DEBUG [ServletHandler] servlet=*.jsp=jsp 10:53:03,855 DEBUG [ServletHttpRequest] Got Session 79ir83g342qjn from cookie 10:53:03,855 DEBUG [ServletHandler] [EMAIL PROTECTED] 10:53:03,855 DEBUG [WebApplicationHandler] chain=jsr154-jsp 10:53:03,855 DEBUG [JspServlet] JspEngine -- /Dates_and_Times.jsp 10:53:03,855 DEBUG [JspServlet]ServletPath: /Dates_and_Times.jsp 10:53:03,855 DEBUG [JspServlet] PathInfo: null 10:53:03,855 DEBUG [ServletHandler] getRealPath of /Dates_and_Times.jsp in [EMAIL PROTECTED] 10:53:03,856 DEBUG [JspServlet] RealPath: /usr/local/ApacheGeronimo/config-store/15/test4.war/Dates_and_Times.jsp 10:53:03,856 DEBUG [JspServlet] RequestURI: /test4/Dates_and_Times.jsp 10:53:03,856 DEBUG [JspServlet]QueryString: null 10:53:03,856 DEBUG [JspServlet] Request Params: 10:53:04,030 DEBUG [Compiler] Using classpath:
[jira] Commented: (GERONIMO-395) Error for /blojsom/: java.lang.StackOverflowError
[ http://issues.apache.org/jira/browse/GERONIMO-395?page=comments#action_58913 ] Greg Wilkins commented on GERONIMO-395: --- This patch is not the correct approach, as it will violate the TCK. The actual problem was due to a bug in jetty where the JSR154 filter could hide the type of the dispatch. This has been fixed in jetty CVS with an explicit pass of the type. A release will flow into geronimo shortly. Error for /blojsom/: java.lang.StackOverflowError - Key: GERONIMO-395 URL: http://issues.apache.org/jira/browse/GERONIMO-395 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: Microsoft Windows XP [Wersja 5.1.2600] java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing) CYGWIN_NT-5.1 Shrek 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin Reporter: Shrek the Ogre Assignee: Greg Wilkins Attachments: jetty-errorpages.patch It's a build from the fresh checkout. Before upgrading Jetty to 5.1-SNAPSHOT blojsom (http://blojsom.sf.net) worked well. Now, once blojsom 2.19 has been deployed using the deployer tool, Jetty prints out the following at the first page of blojsom: ... 10:51:22,250 WARN [ServletHandler] Error for /blojsom/ java.lang.StackOverflowError at java.lang.StringBuffer.append(Unknown Source) at org.apache.log4j.helpers.AbsoluteTimeDateFormat.format(AbsoluteTimeDateFormat.java:113) at java.text.DateFormat.format(Unknown Source) at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternParser.java:436) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:56) at org.apache.log4j.PatternLayout.format(PatternLayout.java:495) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:292) at org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:225) at org.apache.log4j.WriterAppender.append(WriterAppender.java:150) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.apache.geronimo.system.logging.log4j.CachingLog4jLog.debug(CachingLog4jLog.java:69) at org.apache.geronimo.kernel.log.GeronimoLog.debug(GeronimoLog.java:66) at org.mortbay.jetty.servlet.Default.getResource(Default.java:189) at org.mortbay.jetty.servlet.Default.service(Default.java:209) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:413) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:529) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at
[jira] Commented: (GERONIMO-479) Root of WebApp Displays WEB-INF and META-INF Directories
[ http://issues.apache.org/jira/browse/GERONIMO-479?page=comments#action_58966 ] Petr Sickboy Hejl commented on GERONIMO-479: I tested this bug today with GERONIMO-569 (StackOverflow) patch by Greg Wilkins. Summary is: 1) when no welcome file is specified, server list out the content of app root directory (and I'm not sure if this is incorrect..., someone who knows the specification could help?) 2) if user tries to access the WEB-INF or META-INF directory 404 is returned (so it is nice and correct, isn't it?) If the behaviour described in item 1) is correct, this issue should be closed. I attach my test webapp ;) Root of WebApp Displays WEB-INF and META-INF Directories Key: GERONIMO-479 URL: http://issues.apache.org/jira/browse/GERONIMO-479 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: WinXP, JDK 1.4.2 Reporter: Seth Ladd I deployed a simple webapp containing nothing more than a web.xml. There is no welcome.jsp configured or provided. The deploy was OK, but when I browse to http://localhost:8080/testbed I see a directory listing, with the directories WEB-INF and META-INF listed. This, itself, should not happen. When clicking on WEB-INF, I generate a StackOverflow. I would expect a nice Forbidden message, or even a 404 (or whatever the Servlet spec says). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-479) Root of WebApp Displays WEB-INF and META-INF Directories
[ http://issues.apache.org/jira/browse/GERONIMO-479?page=history ] Petr Sickboy Hejl updated GERONIMO-479: --- Attachment: listBug.ear Test application for described issue. Root of WebApp Displays WEB-INF and META-INF Directories Key: GERONIMO-479 URL: http://issues.apache.org/jira/browse/GERONIMO-479 Project: Apache Geronimo Type: Bug Components: web Versions: 1.0-M3 Environment: WinXP, JDK 1.4.2 Reporter: Seth Ladd Attachments: listBug.ear I deployed a simple webapp containing nothing more than a web.xml. There is no welcome.jsp configured or provided. The deploy was OK, but when I browse to http://localhost:8080/testbed I see a directory listing, with the directories WEB-INF and META-INF listed. This, itself, should not happen. When clicking on WEB-INF, I generate a StackOverflow. I would expect a nice Forbidden message, or even a 404 (or whatever the Servlet spec says). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
