[jira] Commented: (GERONIMO-1387) Geronimo Console Applications portlets fail after starting app client.
[ http://issues.apache.org/jira/browse/GERONIMO-1387?page=comments#action_12360781 ] Aaron Mulder commented on GERONIMO-1387: This is a "training issue" -- you can't start an app client within the server or bad, bad things will happen. It sounds like we ought to disable that link in the console for the app client page. > Geronimo Console Applications portlets fail after starting app client. > -- > > Key: GERONIMO-1387 > URL: http://issues.apache.org/jira/browse/GERONIMO-1387 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Windows JDK 1.4.2_08, Jetty version of 1.0 12182005 test > release. > Reporter: Neal Sanche > Priority: Critical > > Log into console, and click App Clients navigation link on left. The > daytrader-derby-jetty-streamer-client/1.0/car component is stopped. Click the > 'Start' link. The server will throw an exception: > 22:57:55,161 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalStateException: More than one configuration mananger was > found > in kernel > at > org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationM > anager(ConfigurationUtil.java:60) > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView > (ConfigManagerPortlet.java:203) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218 > ) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 > ) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde > r.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170 > ) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati > onHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke > rImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke > rImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI > mpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo > rtlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl > etFragment.java:168) > at > org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService > (org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper > .java:322) > Then from that point onward, the server will be unable to show any of the > following portlets: > Application EARs > Web App WARs > EJB Jars > J2EE Connectors > App Clients > System Modules > Each of which will throw the above exception, or one remarkably similar. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1387) Geronimo Console Applications portlets fail after starting app client.
[ http://issues.apache.org/jira/browse/GERONIMO-1387?page=comments#action_12360780 ] Aaron Mulder commented on GERONIMO-1387: This is a "training issue" -- you can't start an app client within the server or bad, bad things will happen. It sounds like we ought to disable that link in the console for the app client page. > Geronimo Console Applications portlets fail after starting app client. > -- > > Key: GERONIMO-1387 > URL: http://issues.apache.org/jira/browse/GERONIMO-1387 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Windows JDK 1.4.2_08, Jetty version of 1.0 12182005 test > release. > Reporter: Neal Sanche > Priority: Critical > > Log into console, and click App Clients navigation link on left. The > daytrader-derby-jetty-streamer-client/1.0/car component is stopped. Click the > 'Start' link. The server will throw an exception: > 22:57:55,161 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalStateException: More than one configuration mananger was > found > in kernel > at > org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationM > anager(ConfigurationUtil.java:60) > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView > (ConfigManagerPortlet.java:203) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218 > ) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 > ) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde > r.java:99) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170 > ) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati > onHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke > rImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke > rImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI > mpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo > rtlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl > etFragment.java:168) > at > org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService > (org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper > .java:322) > Then from that point onward, the server will be unable to show any of the > following portlets: > Application EARs > Web App WARs > EJB Jars > J2EE Connectors > App Clients > System Modules > Each of which will throw the above exception, or one remarkably similar. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1387) Geronimo Console Applications portlets fail after starting app client.
Geronimo Console Applications portlets fail after starting app client. -- Key: GERONIMO-1387 URL: http://issues.apache.org/jira/browse/GERONIMO-1387 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Windows JDK 1.4.2_08, Jetty version of 1.0 12182005 test release. Reporter: Neal Sanche Priority: Critical Log into console, and click App Clients navigation link on left. The daytrader-derby-jetty-streamer-client/1.0/car component is stopped. Click the 'Start' link. The server will throw an exception: 22:57:55,161 ERROR [PortletFragment] Error in Portlet java.lang.IllegalStateException: More than one configuration mananger was found in kernel at org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationM anager(ConfigurationUtil.java:60) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView (ConfigManagerPortlet.java:203) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde r.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke rImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI mpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo rtlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl etFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService (org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:322) Then from that point onward, the server will be unable to show any of the following portlets: Application EARs Web App WARs EJB Jars J2EE Connectors App Clients System Modules Each of which will throw the above exception, or one remarkably similar. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Matt Hogstrom updated GERONIMO-1384: Fix Version: 1.1 (was: 1.0) Applied patch to 1.0 to prevent error. Moving to 1.1 for final fix from Aaron. > Web app with no Geronimo plan makes all secure pages insecure > - > > Key: GERONIMO-1384 > URL: http://issues.apache.org/jira/browse/GERONIMO-1384 > Project: Geronimo > Type: Bug > Components: security, web > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > Attachments: security-reject.patch > > If you deploy a web application with certain pages/URLs protected by a login, > but you don't include a Geronimo deployment plan, all those pages/URLs are > unprotected. To replicate: > Deploy this with no plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and > click the links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, you should get a login prompt and (since no realm was > configured) all logins should fail. > The web.xml in this case contains: > > > Admin Role > /protect/* > > > content-administrator > > > > > > No Access > /forbidden/* > > > > > FORM > MYREALM > > /auth/logon.html?param=test > /auth/logonError.html?param=test > > > > content-administrator > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=comments#action_12360776 ] Matt Hogstrom commented on GERONIMO-1384: - Applied patch to 1.0 branch. Sending modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Transmitting file data . Committed revision 357646. > Web app with no Geronimo plan makes all secure pages insecure > - > > Key: GERONIMO-1384 > URL: http://issues.apache.org/jira/browse/GERONIMO-1384 > Project: Geronimo > Type: Bug > Components: security, web > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > Attachments: security-reject.patch > > If you deploy a web application with certain pages/URLs protected by a login, > but you don't include a Geronimo deployment plan, all those pages/URLs are > unprotected. To replicate: > Deploy this with no plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and > click the links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, you should get a login prompt and (since no realm was > configured) all logins should fail. > The web.xml in this case contains: > > > Admin Role > /protect/* > > > content-administrator > > > > > > No Access > /forbidden/* > > > > > FORM > MYREALM > > /auth/logon.html?param=test > /auth/logonError.html?param=test > > > > content-administrator > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.0 Status: IRC Report
I'm agreeing to this with the express understanding that these changes are in by tonight and any further changes, including changes to the changes, will receive an unyielding, uncompromising, completely binding and everlasting -1 from me. The harsh reality is we're already looking at mid-week before the 1.0 could hit the mirrors -- a chunk of the world is going on holiday vacation and we aren't giving them too much time to try out our shiny 1.0 before they leave the office and don't come back till January. -David On Dec 18, 2005, at 3:16 PM, Aaron Mulder wrote: Alan, Matt, and I spoke about the release on IRC. Matt's thoughts are: 1. integrate the shell script changes to reduce verbosity. Matt thinks this is important because its a customer's first impression and an ECHO OFF is fairly trivial (famous last words) 2. Integrate the fixes from JGenender for clustering since this is such a big thing for users and this was advertised to folks. The change looks reasoinalbe...doesn't seem to risk TCK testing and if it doesn't work we're no worse off than we are now 3. (Aaron paraphrasing) Include the simple security patch to reject logins if web.xml has security settings but the Geronimo plan is not provided or does not have security settings. The proposal to change our Jetty system to use a "default" realm with no users in it has a higher risk of breaking something (plus, it's not ready). 4. Tag and cut a set of binaries tonight and start a TCK run Alan thought we should TCK and release the build that Matt made last night. I thought that we should integrate the changes above and TCK and release that. At the end of the conversation Matt asked me to summarize the conversation and said of the 4-step plan above: "you can give it my +1 and barring core dumps in Java this is it. I'll build tonight and ask David Blevins to start the TCK on it". After that John Sisson pointed out that we have not fixed the issue of spaces in the names of certain files in the documentation. I'm not totally clear whether Matt wanted more input or whether he's made his final decision as release manager, but I would assume that if anyone feels strongly that the plan above is a mistake then they should speak up right away. :) Thanks, Aaron
[jira] Assigned: (GERONIMO-1386) Docs produced by Confluence contain spaces in file names
[ http://issues.apache.org/jira/browse/GERONIMO-1386?page=all ] John Sisson reassigned GERONIMO-1386: - Assign To: Hernan Cunico Reassign this issue if someone else will be working on this. Thanks, John, > Docs produced by Confluence contain spaces in file names > > > Key: GERONIMO-1386 > URL: http://issues.apache.org/jira/browse/GERONIMO-1386 > Project: Geronimo > Type: Bug > Components: documentation > Versions: 1.0 > Reporter: John Sisson > Assignee: Hernan Cunico > Fix For: 1.1 > > This was reported to the dev list in: > http://www.mail-archive.com/dev%40geronimo.apache.org/msg14471.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1386) Docs produced by Confluence contain spaces in file names
Docs produced by Confluence contain spaces in file names Key: GERONIMO-1386 URL: http://issues.apache.org/jira/browse/GERONIMO-1386 Project: Geronimo Type: Bug Components: documentation Versions: 1.0 Reporter: John Sisson Fix For: 1.1 This was reported to the dev list in: http://www.mail-archive.com/dev%40geronimo.apache.org/msg14471.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Clustering fixes
These changes are for Tomcat clustering...using the Tomcat clustering objects. Lets chat about the wadi GBeans as a common object...I have lots of ideas. Lets be sure to keep the WADI lists up to date on this (on Apache - wadi-dev@incubator.apache.org). We are aligned on the WADI ideas ;-) Jeff Greg Wilkins wrote: > Jeff, > > are these tomcat specific or is there something we should mimic in the jetty > clustering (we really need to get a common wadi gbean(s) to avoid duplication > - let's > make this a 1.0.1 priority ) > > cheers > > Jeff Genender wrote: >> If...for whatever reason, the buildmaster (Mr Hogstrom) needs to rebuild >> 1.0 before the release...it would be very much appreciated if he could >> run this from the G1.0 root before he builds the binaries: >> >> svn merge -r 357492:357493 \ >> https://svn.apache.org/repos/asf/geronimo/trunk >> >> As this will finalize the Tomcat clustering teeny tiny fixes that would >> be great to have in 1.0. >> >> If not...then I guess it can wait for 1.0.1. >
Re: 1.0 Status: IRC Report
+1...good plan. Aaron Mulder wrote: > Alan, Matt, and I spoke about the release on IRC. Matt's thoughts are: > > 1. integrate the shell script changes to reduce verbosity. Matt thinks > this is important because its a customer's first impression and an > ECHO OFF is fairly trivial (famous last words) > 2. Integrate the fixes from JGenender for clustering since this is > such a big thing for users and this was advertised to folks. The > change looks reasoinalbe...doesn't seem to risk TCK testing and if it > doesn't work we're no worse off than we are now > 3. (Aaron paraphrasing) Include the simple security patch to reject > logins if web.xml has security settings but the Geronimo plan is not > provided or does not have security settings. The proposal to change > our Jetty system to use a "default" realm with no users in it has a > higher risk of breaking something (plus, it's not ready). > 4. Tag and cut a set of binaries tonight and start a TCK run > > Alan thought we should TCK and release the build that Matt made last > night. I thought that we should integrate the changes above and TCK > and release that. > > At the end of the conversation Matt asked me to summarize the > conversation and said of the 4-step plan above: "you can give it my +1 > and barring core dumps in Java this is it. I'll build tonight and > ask David Blevins to start the TCK on it". > > After that John Sisson pointed out that we have not fixed the issue of > spaces in the names of certain files in the documentation. > > I'm not totally clear whether Matt wanted more input or whether he's > made his final decision as release manager, but I would assume that if > anyone feels strongly that the plan above is a mistake then they > should speak up right away. :) > > Thanks, > Aaron
Re: 1.0 Status: IRC Report
Dims, I asked Aaron to send out the note above as I wanted to get it on the list. Unfortunately, I didn't have time to do that before I left to pick them up so I think his summary is accurate. I'll post another note in my pen when I get the chipmunks in their beds :) Matt Davanum Srinivas wrote: Guys, Please let matt come back and speak for himself :) -- dims On 12/18/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: release as what? rc1 or 1.0? On Dec 18, 2005, at 6:16 PM, Aaron Mulder wrote: Alan, Matt, and I spoke about the release on IRC. Matt's thoughts are: 1. integrate the shell script changes to reduce verbosity. Matt thinks this is important because its a customer's first impression and an ECHO OFF is fairly trivial (famous last words) 2. Integrate the fixes from JGenender for clustering since this is such a big thing for users and this was advertised to folks. The change looks reasoinalbe...doesn't seem to risk TCK testing and if it doesn't work we're no worse off than we are now 3. (Aaron paraphrasing) Include the simple security patch to reject logins if web.xml has security settings but the Geronimo plan is not provided or does not have security settings. The proposal to change our Jetty system to use a "default" realm with no users in it has a higher risk of breaking something (plus, it's not ready). 4. Tag and cut a set of binaries tonight and start a TCK run Alan thought we should TCK and release the build that Matt made last night. I thought that we should integrate the changes above and TCK and release that. At the end of the conversation Matt asked me to summarize the conversation and said of the 4-step plan above: "you can give it my +1 and barring core dumps in Java this is it. I'll build tonight and ask David Blevins to start the TCK on it". After that John Sisson pointed out that we have not fixed the issue of spaces in the names of certain files in the documentation. I'm not totally clear whether Matt wanted more input or whether he's made his final decision as release manager, but I would assume that if anyone feels strongly that the plan above is a mistake then they should speak up right away. :) Thanks, Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/
Installer Status
Hello, The installer is basically done. Here's a rundown of what's included in the latest patch. 1. The webbuilder and ejbbuilder namespaces are set correctly depending on the web container selected. 2. Either Jetty(default) or Tomcat may be selected, but not both. 3. The LDAP realm is being configured 4. installed scripts are made executable 5. Jetty and Tomcat samples are selectable and install successfully 6. LDAP demo is selectable and installs 7. Port selections are validated against each other to prevent conflicts between installed services 8. The SMTP transport is configurable, but does not currently run(the config is not installed in config-store even though the deps in project.xml seem correct). The latest patch is posted to GERONIMO-1192. This JIRA has quite a few patches posted. For clarity, it might be a good idea to close 1192 and open another if more patches are required. -- Regards, Erik
[jira] Commented: (GERONIMO-1371) SQL Exception logged during shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-1371?page=comments#action_12360770 ] John Sisson commented on GERONIMO-1371: --- I have also been able to reproduce this problem on Windows XP just by issuing the startup and shutdown commands. > SQL Exception logged during shutdown > > > Key: GERONIMO-1371 > URL: http://issues.apache.org/jira/browse/GERONIMO-1371 > Project: Geronimo > Type: Bug > Versions: 1.0 > Environment: Windows > Reporter: Dave Colasurdo > Fix For: 1.0, 1.x > Attachments: simple.patch > > Noticed two separate issues when using the latest v1 candidate build > (12/15/05) on a windows platform... > Seeing the following warning in the secondary window and the log for various > shutdowns... > a) "startup.bat" followed by "shutdown.bat" > b) "geronimo.bat start" followed by "shutdown.bat" > 13:36:31,052 WARN [GeronimoConnectionEventListener] connectionErrorOccurred > called with null > SQL Exception: No current connection. > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit(Unknown > Source) > at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit(Unknown > Source) > at > org.tranql.connector.jdbc.ManagedXAConnection.localTransactionStart(ManagedXAConnection.java:89) > at > org.tranql.connector.AbstractManagedConnection$LocalTransactionImpl.begin(AbstractManagedConnection.java:188) > at > org.tranql.connector.jdbc.ConnectionHandle.setAutoCommit(ConnectionHandle.java:161) > at > org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:126) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.activemq.store.PersistenceAdapter$$EnhancerByCGLIB$$98dcaa17.beginTransaction() > at > org.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:158) > at > org.activemq.util.TransactionTemplate.run(TransactionTemplate.java:38) > at > org.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:227) > at > org.activemq.store.journal.JournalPersistenceAdapter$3.run(JournalPersistenceAdapter.java:357) > at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:534) > 13:36:31,062 ERROR [JournalPersistenceAdapter] Failed to checkpoint a message > store: javax.jms.JMSException: Failed to create transaction: SQL Exception: > No current connection. > javax.jms.JMSException: Failed to create transaction: SQL Exception: No > current connection. > at > org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) > at > org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:130) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMeth
[jira] Closed: (GERONIMO-1385) bin\startup.bat echoes batch file commands due to missing @echo off
[ http://issues.apache.org/jira/browse/GERONIMO-1385?page=all ] John Sisson closed GERONIMO-1385: - > bin\startup.bat echoes batch file commands due to missing @echo off > --- > > Key: GERONIMO-1385 > URL: http://issues.apache.org/jira/browse/GERONIMO-1385 > Project: Geronimo > Type: Bug > Components: startup/shutdown > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0 > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1385) bin\startup.bat echoes batch file commands due to missing @echo off
[ http://issues.apache.org/jira/browse/GERONIMO-1385?page=all ] John Sisson resolved GERONIMO-1385: --- Resolution: Fixed > bin\startup.bat echoes batch file commands due to missing @echo off > --- > > Key: GERONIMO-1385 > URL: http://issues.apache.org/jira/browse/GERONIMO-1385 > Project: Geronimo > Type: Bug > Components: startup/shutdown > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0 > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.0 Status: IRC Report
On 12/18/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > release as what? rc1 or 1.0? That was not specifically discussed, but my sense is 1.0 because now that I look, Matt referred to putting other fixes in 1.0.1. Thanks, Aaron > On Dec 18, 2005, at 6:16 PM, Aaron Mulder wrote: > > > Alan, Matt, and I spoke about the release on IRC. Matt's thoughts > > are: > > > > 1. integrate the shell script changes to reduce verbosity. Matt thinks > > this is important because its a customer's first impression and an > > ECHO OFF is fairly trivial (famous last words) > > 2. Integrate the fixes from JGenender for clustering since this is > > such a big thing for users and this was advertised to folks. The > > change looks reasoinalbe...doesn't seem to risk TCK testing and if it > > doesn't work we're no worse off than we are now > > 3. (Aaron paraphrasing) Include the simple security patch to reject > > logins if web.xml has security settings but the Geronimo plan is not > > provided or does not have security settings. The proposal to change > > our Jetty system to use a "default" realm with no users in it has a > > higher risk of breaking something (plus, it's not ready). > > 4. Tag and cut a set of binaries tonight and start a TCK run > > > > Alan thought we should TCK and release the build that Matt made last > > night. I thought that we should integrate the changes above and TCK > > and release that. > > > > At the end of the conversation Matt asked me to summarize the > > conversation and said of the 4-step plan above: "you can give it my +1 > > and barring core dumps in Java this is it. I'll build tonight and > > ask David Blevins to start the TCK on it". > > > > After that John Sisson pointed out that we have not fixed the issue of > > spaces in the names of certain files in the documentation. > > > > I'm not totally clear whether Matt wanted more input or whether he's > > made his final decision as release manager, but I would assume that if > > anyone feels strongly that the plan above is a mistake then they > > should speak up right away. :) > > > > Thanks, > > Aaron > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
Re: 1.0 Status: IRC Report
Guys, Please let matt come back and speak for himself :) -- dims On 12/18/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > release as what? rc1 or 1.0? > > > On Dec 18, 2005, at 6:16 PM, Aaron Mulder wrote: > > > Alan, Matt, and I spoke about the release on IRC. Matt's thoughts > > are: > > > > 1. integrate the shell script changes to reduce verbosity. Matt thinks > > this is important because its a customer's first impression and an > > ECHO OFF is fairly trivial (famous last words) > > 2. Integrate the fixes from JGenender for clustering since this is > > such a big thing for users and this was advertised to folks. The > > change looks reasoinalbe...doesn't seem to risk TCK testing and if it > > doesn't work we're no worse off than we are now > > 3. (Aaron paraphrasing) Include the simple security patch to reject > > logins if web.xml has security settings but the Geronimo plan is not > > provided or does not have security settings. The proposal to change > > our Jetty system to use a "default" realm with no users in it has a > > higher risk of breaking something (plus, it's not ready). > > 4. Tag and cut a set of binaries tonight and start a TCK run > > > > Alan thought we should TCK and release the build that Matt made last > > night. I thought that we should integrate the changes above and TCK > > and release that. > > > > At the end of the conversation Matt asked me to summarize the > > conversation and said of the 4-step plan above: "you can give it my +1 > > and barring core dumps in Java this is it. I'll build tonight and > > ask David Blevins to start the TCK on it". > > > > After that John Sisson pointed out that we have not fixed the issue of > > spaces in the names of certain files in the documentation. > > > > I'm not totally clear whether Matt wanted more input or whether he's > > made his final decision as release manager, but I would assume that if > > anyone feels strongly that the plan above is a mistake then they > > should speak up right away. :) > > > > Thanks, > > Aaron > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: 1.0 Status: IRC Report
release as what? rc1 or 1.0? On Dec 18, 2005, at 6:16 PM, Aaron Mulder wrote: Alan, Matt, and I spoke about the release on IRC. Matt's thoughts are: 1. integrate the shell script changes to reduce verbosity. Matt thinks this is important because its a customer's first impression and an ECHO OFF is fairly trivial (famous last words) 2. Integrate the fixes from JGenender for clustering since this is such a big thing for users and this was advertised to folks. The change looks reasoinalbe...doesn't seem to risk TCK testing and if it doesn't work we're no worse off than we are now 3. (Aaron paraphrasing) Include the simple security patch to reject logins if web.xml has security settings but the Geronimo plan is not provided or does not have security settings. The proposal to change our Jetty system to use a "default" realm with no users in it has a higher risk of breaking something (plus, it's not ready). 4. Tag and cut a set of binaries tonight and start a TCK run Alan thought we should TCK and release the build that Matt made last night. I thought that we should integrate the changes above and TCK and release that. At the end of the conversation Matt asked me to summarize the conversation and said of the 4-step plan above: "you can give it my +1 and barring core dumps in Java this is it. I'll build tonight and ask David Blevins to start the TCK on it". After that John Sisson pointed out that we have not fixed the issue of spaces in the names of certain files in the documentation. I'm not totally clear whether Matt wanted more input or whether he's made his final decision as release manager, but I would assume that if anyone feels strongly that the plan above is a mistake then they should speak up right away. :) Thanks, Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Realmless security. Was: Release 1.0 New Build Available
So after some IRC discussion, it looks like this is not on the table for 1.0 (instead, we're looking at a simpler fix to reject deployments on Jetty which have web.xml security but not geronimo-web.xml security). I tried for the fix described below and I could not get it to work in the time I spent on it. I changed JettyWebAppContext to set a JettyJAASRealm pointing to a non-existant Geronimo realm, and also to construct a generic DefaultPrincipal. Then I had to change SecurityContextBeforeAfter.obtainUser to not blow up if there was no set of checked and excluded permissions specified. But it still ended up generating a 403 for a web app with no security at all in SecurityContextBeforeAfter.checkSecurityConstraints when it called AccessControlContext.checkPermissions. So I think probably JettyModuleBuilder needs to change to apply the right JACC stuff even if no Geronimo security information is provided. But that's as far as I got, so I'm not really sure. If you can come up with a patch for this (for 1.0.1) that would be great. Thanks, Aaron On 12/18/05, Greg Wilkins <[EMAIL PROTECTED]> wrote: > Aaron Mulder wrote: > > Well it appears that Tomcat and Jetty handle this situation > > differently (Tomcat: all secure pages locked down, Jetty: all secure > > pages accessible to anybody), which is *definitely* a bug... > > If Jetty is not given a realm, but is given security constraints for a > resources, it returns a "500 configuration error". So the Jetty plugin > must either be giving Jetty a realm or not giving it the security > constraints. > > From a quick look at JettyModuleBuilder, I think the security > constraints are not being built if there is no security realm name. > > > But really, if the user put security settings in their web.xml, then > > clearly they're expecting security to be applied. If we disable all > > security because they missed a deployment plan or a deployment plan > > setting, then I think that's a huge security problem. Gnerally > > speaking, I think it's always best to fail to a more secure state, not > > to fail to an "anybody authorized for anything" state. That's > > certainly the behavior you'd expect from your bank. > > I agree - but then 1.0 is not going to be a real production release. > I really think it should be called a 1.0RC. > > But anyway... I'm out for a few hours and if David has not fixed this by then, > I'll work on a fix for trunk and we can then decide if that makes it for 1.0 > > cheers >
1.0 Status: IRC Report
Alan, Matt, and I spoke about the release on IRC. Matt's thoughts are: 1. integrate the shell script changes to reduce verbosity. Matt thinks this is important because its a customer's first impression and an ECHO OFF is fairly trivial (famous last words) 2. Integrate the fixes from JGenender for clustering since this is such a big thing for users and this was advertised to folks. The change looks reasoinalbe...doesn't seem to risk TCK testing and if it doesn't work we're no worse off than we are now 3. (Aaron paraphrasing) Include the simple security patch to reject logins if web.xml has security settings but the Geronimo plan is not provided or does not have security settings. The proposal to change our Jetty system to use a "default" realm with no users in it has a higher risk of breaking something (plus, it's not ready). 4. Tag and cut a set of binaries tonight and start a TCK run Alan thought we should TCK and release the build that Matt made last night. I thought that we should integrate the changes above and TCK and release that. At the end of the conversation Matt asked me to summarize the conversation and said of the 4-step plan above: "you can give it my +1 and barring core dumps in Java this is it. I'll build tonight and ask David Blevins to start the TCK on it". After that John Sisson pointed out that we have not fixed the issue of spaces in the names of certain files in the documentation. I'm not totally clear whether Matt wanted more input or whether he's made his final decision as release manager, but I would assume that if anyone feels strongly that the plan above is a mistake then they should speak up right away. :) Thanks, Aaron
[jira] Updated: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Aaron Mulder updated GERONIMO-1384: --- Attachment: security-reject.patch security-reject.patch is a first step where Jetty will refuse to deploy a web app including security settings if there is no Geronimo plan or a Geronimo plan that does not include security settings. At least this way we don't have a situation where a user expects security but none is applied. I hope we'll later provide a "better" fix to have Jetty use a default realm with no principals in it so that security is applied but no logins work (so all secure pages are just inaccessible) > Web app with no Geronimo plan makes all secure pages insecure > - > > Key: GERONIMO-1384 > URL: http://issues.apache.org/jira/browse/GERONIMO-1384 > Project: Geronimo > Type: Bug > Components: web, security > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.0 > Attachments: security-reject.patch > > If you deploy a web application with certain pages/URLs protected by a login, > but you don't include a Geronimo deployment plan, all those pages/URLs are > unprotected. To replicate: > Deploy this with no plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and > click the links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, you should get a login prompt and (since no realm was > configured) all logins should fail. > The web.xml in this case contains: > > > Admin Role > /protect/* > > > content-administrator > > > > > > No Access > /forbidden/* > > > > > FORM > MYREALM > > /auth/logon.html?param=test > /auth/logonError.html?param=test > > > > content-administrator > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Proposed Jetty Security Fix
I couldn't figure out how to fix the problem properly. So to avoid
the hole, here's a patch to reject deployments if web.xml includes
security settings and geronimo-web.xml does not. This way, at least
it's impossible to end up thinking you have security in place when
actually you do not.
Aaron
Index: modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java
===
--- modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java (revision 357489)
+++ modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java (working copy)
@@ -421,6 +421,10 @@
GerMessageDestinationType[] gerMessageDestinations = gerWebApp.getMessageDestinationArray();
ENCConfigBuilder.registerMessageDestinations(earContext.getRefContext(), module.getName(), messageDestinations, gerMessageDestinations);
+if((webApp.getSecurityConstraintArray().length > 0 || webApp.getSecurityRoleArray().length > 0) &&
+(!gerWebApp.isSetSecurityRealmName() || !gerWebApp.isSetSecurity())) {
+throw new DeploymentException("web.xml includes security elements but Geronimo deployment plan is not provided or does not contain and elements necessary to configured security accordingly.");
+}
if (gerWebApp.isSetSecurity()) {
if (!gerWebApp.isSetSecurityRealmName()) {
throw new DeploymentException("You have supplied a security configuration for web app " + module.getName() + " but no security-realm-name to allow login");
Re: Clustering fixes
Jeff, are these tomcat specific or is there something we should mimic in the jetty clustering (we really need to get a common wadi gbean(s) to avoid duplication - let's make this a 1.0.1 priority ) cheers Jeff Genender wrote: > If...for whatever reason, the buildmaster (Mr Hogstrom) needs to rebuild > 1.0 before the release...it would be very much appreciated if he could > run this from the G1.0 root before he builds the binaries: > > svn merge -r 357492:357493 \ > https://svn.apache.org/repos/asf/geronimo/trunk > > As this will finalize the Tomcat clustering teeny tiny fixes that would > be great to have in 1.0. > > If not...then I guess it can wait for 1.0.1.
Realmless security. Was: Release 1.0 New Build Available
Aaron Mulder wrote: > Well it appears that Tomcat and Jetty handle this situation > differently (Tomcat: all secure pages locked down, Jetty: all secure > pages accessible to anybody), which is *definitely* a bug... If Jetty is not given a realm, but is given security constraints for a resources, it returns a "500 configuration error". So the Jetty plugin must either be giving Jetty a realm or not giving it the security constraints. >From a quick look at JettyModuleBuilder, I think the security constraints are not being built if there is no security realm name. > But really, if the user put security settings in their web.xml, then > clearly they're expecting security to be applied. If we disable all > security because they missed a deployment plan or a deployment plan > setting, then I think that's a huge security problem. Gnerally > speaking, I think it's always best to fail to a more secure state, not > to fail to an "anybody authorized for anything" state. That's > certainly the behavior you'd expect from your bank. I agree - but then 1.0 is not going to be a real production release. I really think it should be called a 1.0RC. But anyway... I'm out for a few hours and if David has not fixed this by then, I'll work on a fix for trunk and we can then decide if that makes it for 1.0 cheers
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-branches-1.0-200512181734.patch.gz This patch should just about wrap up the installer. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.1 > Attachments: 20051214_jsisson_patch_installer.patch, > installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer-branches-1.0-12151601.patch.gz, > installer-branches-1.0-200512181734.patch.gz, > installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=comments#action_12360761 ] erik daughtrey commented on GERONIMO-1192: -- I have added Javamail and Daytrader configuration to the installer. However, javamail will not start, so the installer will configure it, but not mark it for starting. I have taken care of the issues raised in JSISSON's patch and ensured that all configs are inclued now. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.1 > Attachments: 20051214_jsisson_patch_installer.patch, > installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer-branches-1.0-12151601.patch.gz, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1371) SQL Exception logged during shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-1371?page=all ] John Sisson updated GERONIMO-1371: -- Summary: SQL Exception logged during shutdown (was: Geronimo startup/shutdown issues) Description: Noticed two separate issues when using the latest v1 candidate build (12/15/05) on a windows platform... Seeing the following warning in the secondary window and the log for various shutdowns... a) "startup.bat" followed by "shutdown.bat" b) "geronimo.bat start" followed by "shutdown.bat" 13:36:31,052 WARN [GeronimoConnectionEventListener] connectionErrorOccurred called with null SQL Exception: No current connection. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit(Unknown Source) at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit(Unknown Source) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionStart(ManagedXAConnection.java:89) at org.tranql.connector.AbstractManagedConnection$LocalTransactionImpl.begin(AbstractManagedConnection.java:188) at org.tranql.connector.jdbc.ConnectionHandle.setAutoCommit(ConnectionHandle.java:161) at org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:126) at org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) at org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.store.PersistenceAdapter$$EnhancerByCGLIB$$98dcaa17.beginTransaction() at org.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:158) at org.activemq.util.TransactionTemplate.run(TransactionTemplate.java:38) at org.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:227) at org.activemq.store.journal.JournalPersistenceAdapter$3.run(JournalPersistenceAdapter.java:357) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) 13:36:31,062 ERROR [JournalPersistenceAdapter] Failed to checkpoint a message store: javax.jms.JMSException: Failed to create transaction: SQL Exception: No current connection. javax.jms.JMSException: Failed to create transaction: SQL Exception: No current connection. at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:130) at org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) at org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.store.PersistenceAdapter$$EnhancerByCGLIB$$98dcaa17.beginTransaction() at org.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:158) at org.activemq.util.TransactionTemplate.run(TransactionTemplate.java:38) at org.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:227) at org.activemq.store.journal.JournalPersiste
[jira] Created: (GERONIMO-1385) bin\startup.bat echoes batch file commands due to missing @echo off
bin\startup.bat echoes batch file commands due to missing @echo off --- Key: GERONIMO-1385 URL: http://issues.apache.org/jira/browse/GERONIMO-1385 Project: Geronimo Type: Bug Components: startup/shutdown Reporter: John Sisson Assigned to: John Sisson Fix For: 1.0 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.0 New Build Available
I think a security issue is worth delaying a release for. It sounds like it should be simple to fix. Jan Aaron Mulder wrote: Another major problem: If you deploy a WAR with security settings an no geronimo-web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: -1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08
Re: Release 1.0 New Build Available
Why *not* put up an RC that we can release (i.e. distribute for people to work with rather than an unofficial candidate that we put in some persons directory)? Can you give a reason why you are against the RC? 1.0 is important for the whole project. It's really a big accomplishment. geir On Dec 18, 2005, at 3:25 PM, Dain Sundstrom wrote: -1 to doing an rc Lets do 1.0.0 now and 1.0.1 in two weeks. -dain On Dec 18, 2005, at 12:16 PM, Geir Magnusson Jr. wrote: +1 Do an RC and publicize it. We'll get a surge of interest. Let people beat the tar out of it. Having a 1.0 would have been a nice tie-in to ApacheCon, but that's over now. Maybe let the RC process run over the holiday season, and hit the world with a 1.0 right after New Year as people get back to work, recharged, saws sharpened and ready to do new things. Lets make a splash then - go into the New Year on all cylinders... geir On Dec 18, 2005, at 2:04 PM, Aaron Mulder wrote: Another major problem: If you deploy a WAR with security settings an no geronimo- web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo- ldap-demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: -1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var \temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_1
Re: Release 1.0 New Build Available
Well it appears that Tomcat and Jetty handle this situation differently (Tomcat: all secure pages locked down, Jetty: all secure pages accessible to anybody), which is *definitely* a bug... But really, if the user put security settings in their web.xml, then clearly they're expecting security to be applied. If we disable all security because they missed a deployment plan or a deployment plan setting, then I think that's a huge security problem. Gnerally speaking, I think it's always best to fail to a more secure state, not to fail to an "anybody authorized for anything" state. That's certainly the behavior you'd expect from your bank. Thanks, Aaron On 12/18/05, David Jencks <[EMAIL PROTECTED]> wrote: > I always thought this was a feature rather than a bug. I believe > that what determines if you get security is whether there is a role- > principal mapping in the geronimo plan, not the existence of the > geronimo plan. I believe the same applies to ejbs. > > I'm a bit nervous about changing this stable behavior this close to a > release. > > david jencks > > On Dec 18, 2005, at 11:04 AM, Aaron Mulder wrote: > > > Another major problem: > > > > If you deploy a WAR with security settings an no geronimo-web.xml, all > > supposedly secure content is unprotected! Try deploying this with no > > plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap- > > demo-1.0-SNAPSHOT.war > > and then visiting > > http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the > > links to "secure" and "forbidden". Both links work, with no login > > prompt. Instead, IMO, you should get a login prompt and (since no > > realm was configured) all logins should fail. > > > > -1 to releasing without the fix. :) I'm sorry, this is the stuff > > that's supposed to be flushed out during the "release candidate" > > phase. We never had one since we were trying to get 1.0 out the door > > in 30 seconds or less, but now we're having one, and I think we ought > > to use it. I'd rather release a solid 1.0 in a week instead of a > > broken one now. > > > > Aaron > > > > On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >> -1 to all "fixes" > >> > >> We're never going to get this release out at this rate. Let's list > >> these as known issues and plan for a 1.0.1 release in two weeks. > >> > >> -dain > >> > >> On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: > >> > >>> Cool...I have a clustering GBean fix...so since we need to rebuild I > >>> would like to slide mine in too. > >>> > >>> Aaron Mulder wrote: > I'd like to put one more fix in here -- sorry, but I just got > back to > my internet connection. Right now if you put a username or > password > of blank in the database pool portlet, the deployment fails. > This is > of course required for connections to the embedded Derby instance, > and > I have the fix ready. > > Thanks, > Aaron > > On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: > > Can we also address part 2 (shutdown error) of GERONIMO-1371? It > > fails > > consistently when issuing a startup followed by a shutdown.. > > Anyone have any insight here? If we don't fix it, we should add > > this to > > the Release notes as a "known issue". > > > > BTW, looking through the release notes... I assume "Specific > > Issues, > > Features and Improvements for Version 1.0" is a list of things > > that > > already have been fixed in 1.0. We may want to make this a bit > > clearer. > > "Specific Issues, Features and Improvements *fixed* for Version > > 1.0" > > > > Hmm.. Should there be a section in the release notes for common > > known > > issues (JIRAs) or do you feel that a link to JIRA is sufficient? > > The > > "Significant Missing Features" section info is much broader and > > not at a > > JIRA granularity. > > > > > > Thanks > > -Dave- > > > > Dave Colasurdo wrote: > >> Matt Hogstrom wrote: > >> > >>> Deferring to 1.1 > >>> GERONIMO-1371 - Geronimo startup/shutdown issues > >>> > >> Any chance of incorporating part 1 of JIRA 1371? It is simply > >> adding an > >> @echo off to startup.bat (and a "launching new window" > >> message). > >> > >> While not a functional problem, it sure will make a big > >> difference as to a user's first impression of geronimo.. > >> > >> Have attached the patch to the JIRA.. > >> > >> Here is the output with the fix: > >> > >> C:\matt_spin_121805\geronimo-1.0\bin>startup > >> Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 > >> Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 > >> Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp > >> Using JRE_HOME:c:\j2sdk1.4.2_08 > >> > >> Launching Geronimo in a new window > >> >
Re: Release 1.0 New Build Available
I always thought this was a feature rather than a bug. I believe that what determines if you get security is whether there is a role- principal mapping in the geronimo plan, not the existence of the geronimo plan. I believe the same applies to ejbs. I'm a bit nervous about changing this stable behavior this close to a release. david jencks On Dec 18, 2005, at 11:04 AM, Aaron Mulder wrote: Another major problem: If you deploy a WAR with security settings an no geronimo-web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap- demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: -1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0
Re: Release 1.0 New Build Available
-1 to doing an rc Lets do 1.0.0 now and 1.0.1 in two weeks. -dain On Dec 18, 2005, at 12:16 PM, Geir Magnusson Jr. wrote: +1 Do an RC and publicize it. We'll get a surge of interest. Let people beat the tar out of it. Having a 1.0 would have been a nice tie-in to ApacheCon, but that's over now. Maybe let the RC process run over the holiday season, and hit the world with a 1.0 right after New Year as people get back to work, recharged, saws sharpened and ready to do new things. Lets make a splash then - go into the New Year on all cylinders... geir On Dec 18, 2005, at 2:04 PM, Aaron Mulder wrote: Another major problem: If you deploy a WAR with security settings an no geronimo-web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap- demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: -1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == "
Re: Release 1.0 New Build Available
+1 Do an RC and publicize it. We'll get a surge of interest. Let people beat the tar out of it. Having a 1.0 would have been a nice tie-in to ApacheCon, but that's over now. Maybe let the RC process run over the holiday season, and hit the world with a 1.0 right after New Year as people get back to work, recharged, saws sharpened and ready to do new things. Lets make a splash then - go into the New Year on all cylinders... geir On Dec 18, 2005, at 2:04 PM, Aaron Mulder wrote: Another major problem: If you deploy a WAR with security settings an no geronimo-web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap- demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: -1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_
Re: Clustering fixes
Oh yes...and most importantly, Dain said if our buildmaster says its ok, then its ok to slide in. Jeff Genender wrote: > If...for whatever reason, the buildmaster (Mr Hogstrom) needs to rebuild > 1.0 before the release...it would be very much appreciated if he could > run this from the G1.0 root before he builds the binaries: > > svn merge -r 357492:357493 \ > https://svn.apache.org/repos/asf/geronimo/trunk > > As this will finalize the Tomcat clustering teeny tiny fixes that would > be great to have in 1.0. > > If not...then I guess it can wait for 1.0.1. > > Thanks! > > Jeff
Clustering fixes
If...for whatever reason, the buildmaster (Mr Hogstrom) needs to rebuild 1.0 before the release...it would be very much appreciated if he could run this from the G1.0 root before he builds the binaries: svn merge -r 357492:357493 \ https://svn.apache.org/repos/asf/geronimo/trunk As this will finalize the Tomcat clustering teeny tiny fixes that would be great to have in 1.0. If not...then I guess it can wait for 1.0.1. Thanks! Jeff
RE: [jira] Updated: (GERONIMO-1381) [Daytrader] Removed unused code
Hi Matt, > -Original Message- > From: Matt Hogstrom [mailto:[EMAIL PROTECTED] > Sent: dimanche 18 décembre 2005 18:19 > To: dev@geronimo.apache.org > Subject: Re: [jira] Updated: (GERONIMO-1381) [Daytrader] Removed unused > code > > Vincent, > > Something must have gotten moved when DayTrader was moved around. > Originally > there was a circular dependency and the code causing this was moved to > Core. AFAIK there's nothing in the core... Also core doesn't sound like a very good name to me. I think it should be possible to get away with it without creating a new module. Here's one idea for example: - the ejb module could create an ejb client jar - the wsappclient code required by the ejb module be moved to the ejb client jar > I'll look into this later today to see what happened. Thanks -Vincent > Vincent Massol (JIRA) wrote: > > [ http://issues.apache.org/jira/browse/GERONIMO-1381?page=all ] > > > > Vincent Massol updated GERONIMO-1381: > > - > > > > Attachment: remove-unused-code-vmassol-20051218.patch > > > > > >>[Daytrader] Removed unused code > >>--- > >> > >> Key: GERONIMO-1381 > >> URL: http://issues.apache.org/jira/browse/GERONIMO-1381 > >> Project: Geronimo > >>Type: Improvement > >> Components: sample apps > >>Versions: 1.0-M5 > >>Reporter: Vincent Massol > >> Attachments: remove-unused-code-vmassol-20051218.patch > >> > >>- The core/ subproject is just doing nothing and should be removed > >>- All the tests in the different modules are also doing nothing (my > guess is that they were generated using the genapp plugin at some point in > the past) > >>Attaching patch. > > > >
Re: Release 1.0 New Build Available
Aaron, Dain, It's the release manager's call, which ones to "sneak in" :) thanks, dims On 12/18/05, Aaron Mulder <[EMAIL PROTECTED]> wrote: > Another major problem: > > If you deploy a WAR with security settings an no geronimo-web.xml, all > supposedly secure content is unprotected! Try deploying this with no > plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visiting > http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the > links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, IMO, you should get a login prompt and (since no > realm was configured) all logins should fail. > > -1 to releasing without the fix. :) I'm sorry, this is the stuff > that's supposed to be flushed out during the "release candidate" > phase. We never had one since we were trying to get 1.0 out the door > in 30 seconds or less, but now we're having one, and I think we ought > to use it. I'd rather release a solid 1.0 in a week instead of a > broken one now. > > Aaron > > On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > -1 to all "fixes" > > > > We're never going to get this release out at this rate. Let's list > > these as known issues and plan for a 1.0.1 release in two weeks. > > > > -dain > > > > On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: > > > > > Cool...I have a clustering GBean fix...so since we need to rebuild I > > > would like to slide mine in too. > > > > > > Aaron Mulder wrote: > > >> I'd like to put one more fix in here -- sorry, but I just got back to > > >> my internet connection. Right now if you put a username or password > > >> of blank in the database pool portlet, the deployment fails. This is > > >> of course required for connections to the embedded Derby instance, > > >> and > > >> I have the fix ready. > > >> > > >> Thanks, > > >> Aaron > > >> > > >> On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: > > >>> Can we also address part 2 (shutdown error) of GERONIMO-1371? It > > >>> fails > > >>> consistently when issuing a startup followed by a shutdown.. > > >>> Anyone have any insight here? If we don't fix it, we should add > > >>> this to > > >>> the Release notes as a "known issue". > > >>> > > >>> BTW, looking through the release notes... I assume "Specific Issues, > > >>> Features and Improvements for Version 1.0" is a list of things that > > >>> already have been fixed in 1.0. We may want to make this a bit > > >>> clearer. > > >>> "Specific Issues, Features and Improvements *fixed* for Version > > >>> 1.0" > > >>> > > >>> Hmm.. Should there be a section in the release notes for common > > >>> known > > >>> issues (JIRAs) or do you feel that a link to JIRA is sufficient? > > >>> The > > >>> "Significant Missing Features" section info is much broader and > > >>> not at a > > >>> JIRA granularity. > > >>> > > >>> > > >>> Thanks > > >>> -Dave- > > >>> > > >>> Dave Colasurdo wrote: > > Matt Hogstrom wrote: > > > > > Deferring to 1.1 > > > GERONIMO-1371 - Geronimo startup/shutdown issues > > > > > Any chance of incorporating part 1 of JIRA 1371? It is simply > > adding an > > @echo off to startup.bat (and a "launching new window" > > message). > > > > While not a functional problem, it sure will make a big > > difference as to a user's first impression of geronimo.. > > > > Have attached the patch to the JIRA.. > > > > Here is the output with the fix: > > > > C:\matt_spin_121805\geronimo-1.0\bin>startup > > Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp > > Using JRE_HOME:c:\j2sdk1.4.2_08 > > > > Launching Geronimo in a new window > > > > > > Here is the output Without the fix: > > > > c:\matt_spin_121805\geronimo-1.0\bin>startup > > > > c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == > > "Windows_NT" > > setlocal > > > > c:\matt_spin_121805\geronimo-1.0\bin>set > > CURRENT_DIR=c:\matt_spin_121805\geronim > > o-1.0\bin > > > > c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome > > > > c:\matt_spin_121805\geronimo-1.0\bin>set > > GERONIMO_HOME=c:\matt_spin_121805\geron > > imo-1.0\bin > > > > c:\matt_spin_121805\geronimo-1.0\bin>if exist > > "c:\matt_spin_121805\geronimo-1.0\ > > bin\bin\geronimo.bat" goto okHome > > > > c:\matt_spin_121805\geronimo-1.0\bin>cd .. > > > > c:\matt_spin_121805\geronimo-1.0>set > > GERONIMO_HOME=c:\matt_spin_121805\geronimo- > > 1.0 > > > > c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 > > \geronimo-1.0\bin > > > > C:\matt_spin_121805\geronimo-1.0\bin>if exist > > "c:\matt_spi
[jira] Updated: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Aaron Mulder updated GERONIMO-1384: --- Component: security web > Web app with no Geronimo plan makes all secure pages insecure > - > > Key: GERONIMO-1384 > URL: http://issues.apache.org/jira/browse/GERONIMO-1384 > Project: Geronimo > Type: Bug > Components: web, security > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.0 > > If you deploy a web application with certain pages/URLs protected by a login, > but you don't include a Geronimo deployment plan, all those pages/URLs are > unprotected. To replicate: > Deploy this with no plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and > click the links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, you should get a login prompt and (since no realm was > configured) all logins should fail. > The web.xml in this case contains: > > > Admin Role > /protect/* > > > content-administrator > > > > > > No Access > /forbidden/* > > > > > FORM > MYREALM > > /auth/logon.html?param=test > /auth/logonError.html?param=test > > > > content-administrator > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
Web app with no Geronimo plan makes all secure pages insecure - Key: GERONIMO-1384 URL: http://issues.apache.org/jira/browse/GERONIMO-1384 Project: Geronimo Type: Bug Components: web, security Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.0 If you deploy a web application with certain pages/URLs protected by a login, but you don't include a Geronimo deployment plan, all those pages/URLs are unprotected. To replicate: Deploy this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and click the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, you should get a login prompt and (since no realm was configured) all logins should fail. The web.xml in this case contains: Admin Role /protect/* content-administrator No Access /forbidden/* FORM MYREALM /auth/logon.html?param=test /auth/logonError.html?param=test content-administrator -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.0 New Build Available
Another major problem: If you deploy a WAR with security settings an no geronimo-web.xml, all supposedly secure content is unprotected! Try deploying this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visiting http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and clicking the links to "secure" and "forbidden". Both links work, with no login prompt. Instead, IMO, you should get a login prompt and (since no realm was configured) all logins should fail. -1 to releasing without the fix. :) I'm sorry, this is the stuff that's supposed to be flushed out during the "release candidate" phase. We never had one since we were trying to get 1.0 out the door in 30 seconds or less, but now we're having one, and I think we ought to use it. I'd rather release a solid 1.0 in a week instead of a broken one now. Aaron On 12/18/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > -1 to all "fixes" > > We're never going to get this release out at this rate. Let's list > these as known issues and plan for a 1.0.1 release in two weeks. > > -dain > > On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: > > > Cool...I have a clustering GBean fix...so since we need to rebuild I > > would like to slide mine in too. > > > > Aaron Mulder wrote: > >> I'd like to put one more fix in here -- sorry, but I just got back to > >> my internet connection. Right now if you put a username or password > >> of blank in the database pool portlet, the deployment fails. This is > >> of course required for connections to the embedded Derby instance, > >> and > >> I have the fix ready. > >> > >> Thanks, > >> Aaron > >> > >> On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: > >>> Can we also address part 2 (shutdown error) of GERONIMO-1371? It > >>> fails > >>> consistently when issuing a startup followed by a shutdown.. > >>> Anyone have any insight here? If we don't fix it, we should add > >>> this to > >>> the Release notes as a "known issue". > >>> > >>> BTW, looking through the release notes... I assume "Specific Issues, > >>> Features and Improvements for Version 1.0" is a list of things that > >>> already have been fixed in 1.0. We may want to make this a bit > >>> clearer. > >>> "Specific Issues, Features and Improvements *fixed* for Version > >>> 1.0" > >>> > >>> Hmm.. Should there be a section in the release notes for common > >>> known > >>> issues (JIRAs) or do you feel that a link to JIRA is sufficient? > >>> The > >>> "Significant Missing Features" section info is much broader and > >>> not at a > >>> JIRA granularity. > >>> > >>> > >>> Thanks > >>> -Dave- > >>> > >>> Dave Colasurdo wrote: > Matt Hogstrom wrote: > > > Deferring to 1.1 > > GERONIMO-1371 - Geronimo startup/shutdown issues > > > Any chance of incorporating part 1 of JIRA 1371? It is simply > adding an > @echo off to startup.bat (and a "launching new window" > message). > > While not a functional problem, it sure will make a big > difference as to a user's first impression of geronimo.. > > Have attached the patch to the JIRA.. > > Here is the output with the fix: > > C:\matt_spin_121805\geronimo-1.0\bin>startup > Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 > Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 > Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp > Using JRE_HOME:c:\j2sdk1.4.2_08 > > Launching Geronimo in a new window > > > Here is the output Without the fix: > > c:\matt_spin_121805\geronimo-1.0\bin>startup > > c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == > "Windows_NT" > setlocal > > c:\matt_spin_121805\geronimo-1.0\bin>set > CURRENT_DIR=c:\matt_spin_121805\geronim > o-1.0\bin > > c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome > > c:\matt_spin_121805\geronimo-1.0\bin>set > GERONIMO_HOME=c:\matt_spin_121805\geron > imo-1.0\bin > > c:\matt_spin_121805\geronimo-1.0\bin>if exist > "c:\matt_spin_121805\geronimo-1.0\ > bin\bin\geronimo.bat" goto okHome > > c:\matt_spin_121805\geronimo-1.0\bin>cd .. > > c:\matt_spin_121805\geronimo-1.0>set > GERONIMO_HOME=c:\matt_spin_121805\geronimo- > 1.0 > > c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 > \geronimo-1.0\bin > > C:\matt_spin_121805\geronimo-1.0\bin>if exist > "c:\matt_spin_121805\geronimo-1.0\ > bin\geronimo.bat" goto okHome > > C:\matt_spin_121805\geronimo-1.0\bin>set > EXECUTABLE=c:\matt_spin_121805\geronimo > -1.0\bin\geronimo.bat > > C:\matt_spin_121805\geronimo-1.0\bin>if exist > "c:\matt_spin_121805\geronimo-1.0\ > bin\geronimo.bat" goto okExec > > C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= > >
Re: Release 1.0 New Build Available
-1 to all "fixes" We're never going to get this release out at this rate. Let's list these as known issues and plan for a 1.0.1 release in two weeks. -dain On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote: Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805 \geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08
Re: Release 1.0 New Build Available
Cool...I have a clustering GBean fix...so since we need to rebuild I would like to slide mine in too. Aaron Mulder wrote: > I'd like to put one more fix in here -- sorry, but I just got back to > my internet connection. Right now if you put a username or password > of blank in the database pool portlet, the deployment fails. This is > of course required for connections to the embedded Derby instance, and > I have the fix ready. > > Thanks, > Aaron > > On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: >> Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails >> consistently when issuing a startup followed by a shutdown.. >> Anyone have any insight here? If we don't fix it, we should add this to >> the Release notes as a "known issue". >> >> BTW, looking through the release notes... I assume "Specific Issues, >> Features and Improvements for Version 1.0" is a list of things that >> already have been fixed in 1.0. We may want to make this a bit clearer. >> "Specific Issues, Features and Improvements *fixed* for Version 1.0" >> >> Hmm.. Should there be a section in the release notes for common known >> issues (JIRAs) or do you feel that a link to JIRA is sufficient? The >> "Significant Missing Features" section info is much broader and not at a >> JIRA granularity. >> >> >> Thanks >> -Dave- >> >> Dave Colasurdo wrote: >>> Matt Hogstrom wrote: >>> Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues >>> Any chance of incorporating part 1 of JIRA 1371? It is simply adding an >>> @echo off to startup.bat (and a "launching new window" >>> message). >>> >>> While not a functional problem, it sure will make a big >>> difference as to a user's first impression of geronimo.. >>> >>> Have attached the patch to the JIRA.. >>> >>> Here is the output with the fix: >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>startup >>> Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 >>> Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 >>> Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp >>> Using JRE_HOME:c:\j2sdk1.4.2_08 >>> >>> Launching Geronimo in a new window >>> >>> >>> Here is the output Without the fix: >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>startup >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" >>> setlocal >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>set >>> CURRENT_DIR=c:\matt_spin_121805\geronim >>> o-1.0\bin >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>set >>> GERONIMO_HOME=c:\matt_spin_121805\geron >>> imo-1.0\bin >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>if exist >>> "c:\matt_spin_121805\geronimo-1.0\ >>> bin\bin\geronimo.bat" goto okHome >>> >>> c:\matt_spin_121805\geronimo-1.0\bin>cd .. >>> >>> c:\matt_spin_121805\geronimo-1.0>set >>> GERONIMO_HOME=c:\matt_spin_121805\geronimo- >>> 1.0 >>> >>> c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805\geronimo-1.0\bin >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>if exist >>> "c:\matt_spin_121805\geronimo-1.0\ >>> bin\geronimo.bat" goto okHome >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>set >>> EXECUTABLE=c:\matt_spin_121805\geronimo >>> -1.0\bin\geronimo.bat >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>if exist >>> "c:\matt_spin_121805\geronimo-1.0\ >>> bin\geronimo.bat" goto okExec >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs >>> >>> C:\matt_spin_121805\geronimo-1.0\bin>call >>> "c:\matt_spin_121805\geronimo-1.0\bin\ >>> geronimo.bat" start >>> Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 >>> Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 >>> Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp >>> Using JRE_HOME:c:\j2sdk1.4.2_08 >>> >>> >>> >>> >>>
[jira] Updated: (GERONIMO-1382) DB Pool Portlet blows up on empty username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1382?page=all ] Aaron Mulder updated GERONIMO-1382: --- Description: If you leave the username and/or password empty on the database pool portlet, that is translated to a value of "null". Currently, the JSR-88 connector implementation attempts to write XML with "nil=true" or something to that effect, which is not valid for the schemas. Instead, we need to omit those config property setting elements. This is a little complex because we attempt to keep a set of config property setting elements that maps 1:1 to the config settings available in ra.xml, so we don't want to permanently delete missing elements when you save or something like that. Also, the DB pool portlet itself gets an NPE on line 789 or so when the username or password is null and it tries to put that into a Hashtable to connect. was:If you leave the username and/or password empty on the database pool portlet, that is translated to a value of "null". Currently, the JSR-88 connector implementation attempts to write XML with "nil=true" or something to that effect, which is not valid for the schemas. Instead, we need to omit those config property setting elements. This is a little complex because we attempt to keep a set of config property setting elements that maps 1:1 to the config settings available in ra.xml, so we don't want to permanently delete missing elements when you save or something like that. > DB Pool Portlet blows up on empty username/password > --- > > Key: GERONIMO-1382 > URL: http://issues.apache.org/jira/browse/GERONIMO-1382 > Project: Geronimo > Type: Bug > Components: console, deployment > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.0 > > If you leave the username and/or password empty on the database pool portlet, > that is translated to a value of "null". Currently, the JSR-88 connector > implementation attempts to write XML with "nil=true" or something to that > effect, which is not valid for the schemas. Instead, we need to omit those > config property setting elements. This is a little complex because we > attempt to keep a set of config property setting elements that maps 1:1 to > the config settings available in ra.xml, so we don't want to permanently > delete missing elements when you save or something like that. > Also, the DB pool portlet itself gets an NPE on line 789 or so when the > username or password is null and it tries to put that into a Hashtable to > connect. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.0 New Build Available
I'd like to put one more fix in here -- sorry, but I just got back to my internet connection. Right now if you put a username or password of blank in the database pool portlet, the deployment fails. This is of course required for connections to the embedded Derby instance, and I have the fix ready. Thanks, Aaron On 12/18/05, Dave Colasurdo <[EMAIL PROTECTED]> wrote: > Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails > consistently when issuing a startup followed by a shutdown.. > Anyone have any insight here? If we don't fix it, we should add this to > the Release notes as a "known issue". > > BTW, looking through the release notes... I assume "Specific Issues, > Features and Improvements for Version 1.0" is a list of things that > already have been fixed in 1.0. We may want to make this a bit clearer. > "Specific Issues, Features and Improvements *fixed* for Version 1.0" > > Hmm.. Should there be a section in the release notes for common known > issues (JIRAs) or do you feel that a link to JIRA is sufficient? The > "Significant Missing Features" section info is much broader and not at a > JIRA granularity. > > > Thanks > -Dave- > > Dave Colasurdo wrote: > > Matt Hogstrom wrote: > > > >> > >> Deferring to 1.1 > >> GERONIMO-1371 - Geronimo startup/shutdown issues > >> > > > > Any chance of incorporating part 1 of JIRA 1371? It is simply adding an > > @echo off to startup.bat (and a "launching new window" > > message). > > > > While not a functional problem, it sure will make a big > > difference as to a user's first impression of geronimo.. > > > > Have attached the patch to the JIRA.. > > > > Here is the output with the fix: > > > > C:\matt_spin_121805\geronimo-1.0\bin>startup > > Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp > > Using JRE_HOME:c:\j2sdk1.4.2_08 > > > > Launching Geronimo in a new window > > > > > > Here is the output Without the fix: > > > > c:\matt_spin_121805\geronimo-1.0\bin>startup > > > > c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" > > setlocal > > > > c:\matt_spin_121805\geronimo-1.0\bin>set > > CURRENT_DIR=c:\matt_spin_121805\geronim > > o-1.0\bin > > > > c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome > > > > c:\matt_spin_121805\geronimo-1.0\bin>set > > GERONIMO_HOME=c:\matt_spin_121805\geron > > imo-1.0\bin > > > > c:\matt_spin_121805\geronimo-1.0\bin>if exist > > "c:\matt_spin_121805\geronimo-1.0\ > > bin\bin\geronimo.bat" goto okHome > > > > c:\matt_spin_121805\geronimo-1.0\bin>cd .. > > > > c:\matt_spin_121805\geronimo-1.0>set > > GERONIMO_HOME=c:\matt_spin_121805\geronimo- > > 1.0 > > > > c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805\geronimo-1.0\bin > > > > C:\matt_spin_121805\geronimo-1.0\bin>if exist > > "c:\matt_spin_121805\geronimo-1.0\ > > bin\geronimo.bat" goto okHome > > > > C:\matt_spin_121805\geronimo-1.0\bin>set > > EXECUTABLE=c:\matt_spin_121805\geronimo > > -1.0\bin\geronimo.bat > > > > C:\matt_spin_121805\geronimo-1.0\bin>if exist > > "c:\matt_spin_121805\geronimo-1.0\ > > bin\geronimo.bat" goto okExec > > > > C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= > > > > C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs > > > > C:\matt_spin_121805\geronimo-1.0\bin>call > > "c:\matt_spin_121805\geronimo-1.0\bin\ > > geronimo.bat" start > > Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 > > Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp > > Using JRE_HOME:c:\j2sdk1.4.2_08 > > > > > > > > > > >
Re: [jira] Updated: (GERONIMO-1381) [Daytrader] Removed unused code
Vincent, Something must have gotten moved when DayTrader was moved around. Originally there was a circular dependency and the code causing this was moved to Core. I'll look into this later today to see what happened. Thanks for pointing this out. Vincent Massol (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1381?page=all ] Vincent Massol updated GERONIMO-1381: - Attachment: remove-unused-code-vmassol-20051218.patch [Daytrader] Removed unused code --- Key: GERONIMO-1381 URL: http://issues.apache.org/jira/browse/GERONIMO-1381 Project: Geronimo Type: Improvement Components: sample apps Versions: 1.0-M5 Reporter: Vincent Massol Attachments: remove-unused-code-vmassol-20051218.patch - The core/ subproject is just doing nothing and should be removed - All the tests in the different modules are also doing nothing (my guess is that they were generated using the genapp plugin at some point in the past) Attaching patch.
[jira] Commented: (GERONIMO-1378) Bad application web.xml makes digester go crazy
[ http://issues.apache.org/jira/browse/GERONIMO-1378?page=comments#action_12360741 ] anita kulshreshtha commented on GERONIMO-1378: -- I have not looked at TMB code recently, but the deployer reports to the console "The application was successfully deployed" and console shows the app running! The behavior in Jetty is different. It reports to the console "Could not load servlet class org... " and the app is not deployed. You are correct that Jetty also show the stack trace. So we will not have a simple parse error message. But I think TMB should give DeploymentException just to be consistent. In Tomcat's case, next time the server is started, all these errors show up at startup time due to a badly deployed app. > Bad application web.xml makes digester go crazy > --- > > Key: GERONIMO-1378 > URL: http://issues.apache.org/jira/browse/GERONIMO-1378 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Environment: all > Reporter: anita kulshreshtha > Priority: Minor > > This trace is produced when the element has a > non-existent class name: > 11:49:15,484 ERROR [ContextConfig] Parse error in application web.xml > java.lang.RuntimeException: org.apache.catalina.manager.JMXProxyServlet > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2719) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2745) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:339) > at > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1031) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4076) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) > at > org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) > at > org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) > at > org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407) > at > org.apache.geron
[jira] Created: (GERONIMO-1383) Connector DConfigBeans don't load correctly from XML
Connector DConfigBeans don't load correctly from XML Key: GERONIMO-1383 URL: http://issues.apache.org/jira/browse/GERONIMO-1383 Project: Geronimo Type: Bug Components: connector, deployment Versions: 1.0 Reporter: Aaron Mulder Assigned to: Aaron Mulder Fix For: 1.1 When you load an existing geronimo-ra.xml plan using the connector DConfigBeans, most of the incoming data seems to be lost (e.g. there are no connection definition instances). -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1382) DB Pool Portlet blows up on empty username/password
DB Pool Portlet blows up on empty username/password --- Key: GERONIMO-1382 URL: http://issues.apache.org/jira/browse/GERONIMO-1382 Project: Geronimo Type: Bug Components: deployment, console Versions: 1.0 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.0 If you leave the username and/or password empty on the database pool portlet, that is translated to a value of "null". Currently, the JSR-88 connector implementation attempts to write XML with "nil=true" or something to that effect, which is not valid for the schemas. Instead, we need to omit those config property setting elements. This is a little complex because we attempt to keep a set of config property setting elements that maps 1:1 to the config settings available in ra.xml, so we don't want to permanently delete missing elements when you save or something like that. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.0 New Build Available
Can we also address part 2 (shutdown error) of GERONIMO-1371? It fails consistently when issuing a startup followed by a shutdown.. Anyone have any insight here? If we don't fix it, we should add this to the Release notes as a "known issue". BTW, looking through the release notes... I assume "Specific Issues, Features and Improvements for Version 1.0" is a list of things that already have been fixed in 1.0. We may want to make this a bit clearer. "Specific Issues, Features and Improvements *fixed* for Version 1.0" Hmm.. Should there be a section in the release notes for common known issues (JIRAs) or do you feel that a link to JIRA is sufficient? The "Significant Missing Features" section info is much broader and not at a JIRA granularity. Thanks -Dave- Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805\geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08
[jira] Commented: (GERONIMO-1378) Bad application web.xml makes digester go crazy
[ http://issues.apache.org/jira/browse/GERONIMO-1378?page=comments#action_12360718 ] Jeff Genender commented on GERONIMO-1378: - Where in Jetty is the error caught and loads the servlet further? It throws an Exception too on this condition...as I pointed out it throws a DeploymentException on line 952 of the JMB. How does it differ whether we throw the Exception or Tomcat throws it? The result will be the same. I am not averse to us catching and throwing errors, but it should be done when we are parsing the web.xml. We shouldn't be fragmenting the web.xml parsing. > Bad application web.xml makes digester go crazy > --- > > Key: GERONIMO-1378 > URL: http://issues.apache.org/jira/browse/GERONIMO-1378 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Environment: all > Reporter: anita kulshreshtha > Priority: Minor > > This trace is produced when the element has a > non-existent class name: > 11:49:15,484 ERROR [ContextConfig] Parse error in application web.xml > java.lang.RuntimeException: org.apache.catalina.manager.JMXProxyServlet > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2719) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2745) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:339) > at > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1031) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4076) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) > at > org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) > at > org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) > at > org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBe
[jira] Commented: (GERONIMO-1378) Bad application web.xml makes digester go crazy
[ http://issues.apache.org/jira/browse/GERONIMO-1378?page=comments#action_12360717 ] anita kulshreshtha commented on GERONIMO-1378: -- I think it is a very common mistake to specify bad class name either because of typo or cut-and-paste. Until GERONIMO-1035 is finished, TomcatModuleBuilder could catch this and avoid the stack trace. In Jetty, this error is caught because Jetty needs to load the servlet for further processing, not because it is trying to validate the web.xml. IMHO, a simple parse error is much more user friendly. I think we should do it because it can be easily done, and the other container does not behave the same way. Once this error is caught, the deployment is aborted. This web.xml will not be released to Tomcat. > Bad application web.xml makes digester go crazy > --- > > Key: GERONIMO-1378 > URL: http://issues.apache.org/jira/browse/GERONIMO-1378 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Environment: all > Reporter: anita kulshreshtha > Priority: Minor > > This trace is produced when the element has a > non-existent class name: > 11:49:15,484 ERROR [ContextConfig] Parse error in application web.xml > java.lang.RuntimeException: org.apache.catalina.manager.JMXProxyServlet > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2719) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2745) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:339) > at > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1031) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4076) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) > at > org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) > at > org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) > at > org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407) >
Re: Release 1.0 New Build Available
Thanks Dave. I think we can do that. Since its not a code change it should be pretty easy. Keep us honest as the time progresses. Dave Colasurdo wrote: Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805\geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08
Re: Release 1.0 New Build Available
Looks like the redirect at http://geronimo.apache.org/redirects/additionalSamples.html needs to be updated to the new location of the samples. A link to the new location is shown on the old page. Matt Hogstrom wrote: I have rebuilt the 1.0 server with the following JIRA's incorporated and this was at Committed revision 357442 of subversion. The server started successfully on my system (Mac OS) for both Tomcat and Jetty. I wiped out my Maven repo before rebuilding so to the best of my knowledge it works on my system and should work on yours. The images are available at http://people.apache.org/~hogstrom/geronimo-1.0 The files are: geronimo-tomcat-j2ee-1.0-20051218.tar.gz geronimo-tomcat-j2ee-1.0-20051218.zip geronimo-jetty-j2ee-1.0-20051218.tar.gz geronimo-jetty-j2ee-1.0-20051218.zip Note: These files extract into ./geronimo-1.0 which is different than the file name. Please ensure that any previous release of Geronimo installed in that directory tree has been removed. Please take time to download and run through the images and verify they start and stop without errors (there are some known ActiveMQ errors at shutdown around connection problems. I believe these can safely be ignored and will be fixed in a near term release.) Post comments back to the list and we'll incorporate the changes quickly and keep the train moving. I have not had time to download and retest these images to make sure they made it up correctly. Any problems reply back to this thread. Mr. Blevins and Mr. Jencks, I hate to impose on you but can you start a TCK run on this build and barring any major issues this might be it so it would be good to have verification of the build. Thanks - Matt Here is the list of defects incorporated into this build. Completed GERONIMO-1363 - DayTrader still using old geronimo-spec files - applied by Matt GERONIMO-1364 - update welcome pages to point at HTTP redirects in the geronimo.apache.org site GERONIMO-1372 - Exception during startup - TradeEJB - Fixed per Dain GERONIMO-1373 - DB info portlet not working correctly - Applied by Matt GERONIMO-1375 - Invalid login to console should not produce stack trace GERONIMO-1377 - Startup Warning on tomcat - unknown default host. - Fixed by Jeff Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues
[jira] Commented: (GERONIMO-1378) Bad application web.xml makes digester go crazy
[ http://issues.apache.org/jira/browse/GERONIMO-1378?page=comments#action_12360716 ] Jeff Genender commented on GERONIMO-1378: - Trapping digester errors is not good as this is how Tomcat handles its XML parsing and its the way it flags errors. Even if we catch this condition before we release the web.xml to Tomcat, we will still have an Exception, as Jetty still throws an Exception at line 952 of the Jetty ModuleBuilder...so we would likely do the exact same. IMHO, since the TomcatModuleBuilder is not doing the parsing and verification of the web.xml, I would not fix this. Until we get the full parsing and handling of the web.xml on the Geronimo side, we shouldn't go trapping web.xml parsing errors that come from the responsible handlers (Tomcat). I believe that issue GERONIMO-1035, which you opened, should eventually handle parsing and will handle this condition. Therefore this is not a bug...its expected behavior. > Bad application web.xml makes digester go crazy > --- > > Key: GERONIMO-1378 > URL: http://issues.apache.org/jira/browse/GERONIMO-1378 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Environment: all > Reporter: anita kulshreshtha > Priority: Minor > > This trace is produced when the element has a > non-existent class name: > 11:49:15,484 ERROR [ContextConfig] Parse error in application web.xml > java.lang.RuntimeException: org.apache.catalina.manager.JMXProxyServlet > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2719) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2745) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:339) > at > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1031) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4076) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) > at > org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) > at > org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) > at > org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.
Re: Release 1.0 New Build Available
Matt Hogstrom wrote: Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues Any chance of incorporating part 1 of JIRA 1371? It is simply adding an @echo off to startup.bat (and a "launching new window" message). While not a functional problem, it sure will make a big difference as to a user's first impression of geronimo.. Have attached the patch to the JIRA.. Here is the output with the fix: C:\matt_spin_121805\geronimo-1.0\bin>startup Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08 Launching Geronimo in a new window Here is the output Without the fix: c:\matt_spin_121805\geronimo-1.0\bin>startup c:\matt_spin_121805\geronimo-1.0\bin>if "Windows_NT" == "Windows_NT" setlocal c:\matt_spin_121805\geronimo-1.0\bin>set CURRENT_DIR=c:\matt_spin_121805\geronim o-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if not "" == "" goto gotHome c:\matt_spin_121805\geronimo-1.0\bin>set GERONIMO_HOME=c:\matt_spin_121805\geron imo-1.0\bin c:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\bin\geronimo.bat" goto okHome c:\matt_spin_121805\geronimo-1.0\bin>cd .. c:\matt_spin_121805\geronimo-1.0>set GERONIMO_HOME=c:\matt_spin_121805\geronimo- 1.0 c:\matt_spin_121805\geronimo-1.0>cd c:\matt_spin_121805\geronimo-1.0\bin C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okHome C:\matt_spin_121805\geronimo-1.0\bin>set EXECUTABLE=c:\matt_spin_121805\geronimo -1.0\bin\geronimo.bat C:\matt_spin_121805\geronimo-1.0\bin>if exist "c:\matt_spin_121805\geronimo-1.0\ bin\geronimo.bat" goto okExec C:\matt_spin_121805\geronimo-1.0\bin>set CMD_LINE_ARGS= C:\matt_spin_121805\geronimo-1.0\bin>if == goto doneSetArgs C:\matt_spin_121805\geronimo-1.0\bin>call "c:\matt_spin_121805\geronimo-1.0\bin\ geronimo.bat" start Using GERONIMO_BASE: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_HOME: c:\matt_spin_121805\geronimo-1.0 Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp Using JRE_HOME:c:\j2sdk1.4.2_08
Re: Release 1.0 New Build Available
I have used geronimo-tomcat-j2ee-1.0-20051218.zip and have tested all the issues mentioned here on win XP. They all have been fixed. thanks Anita --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I have rebuilt the 1.0 server with the following > JIRA's incorporated and this > was at Committed revision 357442 of subversion. > > The server started successfully on my system (Mac > OS) for both Tomcat and Jetty. > I wiped out my Maven repo before rebuilding so to > the best of my knowledge it > works on my system and should work on yours. > > The images are available at > http://people.apache.org/~hogstrom/geronimo-1.0 > > The files are: > > geronimo-tomcat-j2ee-1.0-20051218.tar.gz > geronimo-tomcat-j2ee-1.0-20051218.zip > > geronimo-jetty-j2ee-1.0-20051218.tar.gz > geronimo-jetty-j2ee-1.0-20051218.zip > > Note: These files extract into ./geronimo-1.0 which > is different than the file > name. Please ensure that any previous release of > Geronimo installed in that > directory tree has been removed. > > Please take time to download and run through the > images and verify they start > and stop without errors (there are some known > ActiveMQ errors at shutdown around > connection problems. I believe these can safely be > ignored and will be fixed in > a near term release.) > > Post comments back to the list and we'll incorporate > the changes quickly and > keep the train moving. > > I have not had time to download and retest these > images to make sure they made > it up correctly. Any problems reply back to this > thread. > > Mr. Blevins and Mr. Jencks, I hate to impose on you > but can you start a TCK run > on this build and barring any major issues this > might be it so it would be good > to have verification of the build. > > Thanks > > - Matt > > Here is the list of defects incorporated into this > build. > > Completed > GERONIMO-1363 - DayTrader still using old > geronimo-spec files - applied by Matt > GERONIMO-1364 - update welcome pages to point at > HTTP redirects in the > geronimo.apache.org site > GERONIMO-1372 - Exception during startup - TradeEJB > - Fixed per Dain > GERONIMO-1373 - DB info portlet not working > correctly - Applied by Matt > GERONIMO-1375 - Invalid login to console should not > produce stack trace > GERONIMO-1377 - Startup Warning on tomcat - unknown > default host. - Fixed by Jeff > > Deferring to 1.1 > GERONIMO-1371 - Geronimo startup/shutdown issues > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-1371) Geronimo startup/shutdown issues
[ http://issues.apache.org/jira/browse/GERONIMO-1371?page=all ] Dave Colasurdo updated GERONIMO-1371: - Attachment: simple.patch Attached simple.patch for part 1.. > Geronimo startup/shutdown issues > > > Key: GERONIMO-1371 > URL: http://issues.apache.org/jira/browse/GERONIMO-1371 > Project: Geronimo > Type: Bug > Versions: 1.0 > Environment: Windows > Reporter: Dave Colasurdo > Fix For: 1.0, 1.x > Attachments: simple.patch > > Noticed two separate issues when using the latest v1 candidate build > (12/15/05) on a windows platform... > 1) When issuing startup.bat, lots of debug messages appear in the primary > window.. Suspect this is just a missing @echo off > 2) Seeing the following warning in the secondary window and the log for > various shutdowns... > a) "startup.bat" followed by "shutdown.bat" > b) "geronimo.bat start" followed by "shutdown.bat" > 13:36:31,052 WARN [GeronimoConnectionEventListener] connectionErrorOccurred > called with null > SQL Exception: No current connection. > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit(Unknown > Source) > at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit(Unknown > Source) > at > org.tranql.connector.jdbc.ManagedXAConnection.localTransactionStart(ManagedXAConnection.java:89) > at > org.tranql.connector.AbstractManagedConnection$LocalTransactionImpl.begin(AbstractManagedConnection.java:188) > at > org.tranql.connector.jdbc.ConnectionHandle.setAutoCommit(ConnectionHandle.java:161) > at > org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:126) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.activemq.store.PersistenceAdapter$$EnhancerByCGLIB$$98dcaa17.beginTransaction() > at > org.activemq.store.journal.JournalPersistenceAdapter.beginTransaction(JournalPersistenceAdapter.java:158) > at > org.activemq.util.TransactionTemplate.run(TransactionTemplate.java:38) > at > org.activemq.store.journal.JournalMessageStore.checkpoint(JournalMessageStore.java:227) > at > org.activemq.store.journal.JournalPersistenceAdapter$3.run(JournalPersistenceAdapter.java:357) > at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:534) > 13:36:31,062 ERROR [JournalPersistenceAdapter] Failed to checkpoint a message > store: javax.jms.JMSException: Failed to create transaction: SQL Exception: > No current connection. > javax.jms.JMSException: Failed to create transaction: SQL Exception: No > current connection. > at > org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) > at > org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction(JDBCPersistenceAdapter.java:130) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction(JDBCPersistenceAdapterGBean.java:76) > at > org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel
[jira] Commented: (GERONIMO-1378) Bad application web.xml makes digester go crazy
[ http://issues.apache.org/jira/browse/GERONIMO-1378?page=comments#action_12360714 ] anita kulshreshtha commented on GERONIMO-1378: -- JettyModuleBuilder loads servlet classes to check if they are regular servlets or a web service. IIRC TomcatModuleBuilder does the same. At this point the above error can be caught, and the deployment can be abandoned. > Bad application web.xml makes digester go crazy > --- > > Key: GERONIMO-1378 > URL: http://issues.apache.org/jira/browse/GERONIMO-1378 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0-M5 > Environment: all > Reporter: anita kulshreshtha > Priority: Minor > > This trace is produced when the element has a > non-existent class name: > 11:49:15,484 ERROR [ContextConfig] Parse error in application web.xml > java.lang.RuntimeException: org.apache.catalina.manager.JMXProxyServlet > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2719) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2745) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:339) > at > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1031) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4076) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) > at > org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) > at > org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) > at > org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > at > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanI
[jira] Updated: (GERONIMO-1381) [Daytrader] Removed unused code
[ http://issues.apache.org/jira/browse/GERONIMO-1381?page=all ] Vincent Massol updated GERONIMO-1381: - Attachment: remove-unused-code-vmassol-20051218.patch > [Daytrader] Removed unused code > --- > > Key: GERONIMO-1381 > URL: http://issues.apache.org/jira/browse/GERONIMO-1381 > Project: Geronimo > Type: Improvement > Components: sample apps > Versions: 1.0-M5 > Reporter: Vincent Massol > Attachments: remove-unused-code-vmassol-20051218.patch > > - The core/ subproject is just doing nothing and should be removed > - All the tests in the different modules are also doing nothing (my guess is > that they were generated using the genapp plugin at some point in the past) > Attaching patch. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1381) [Daytrader] Removed unused code
[Daytrader] Removed unused code --- Key: GERONIMO-1381 URL: http://issues.apache.org/jira/browse/GERONIMO-1381 Project: Geronimo Type: Improvement Components: sample apps Versions: 1.0-M5 Reporter: Vincent Massol Attachments: remove-unused-code-vmassol-20051218.patch - The core/ subproject is just doing nothing and should be removed - All the tests in the different modules are also doing nothing (my guess is that they were generated using the genapp plugin at some point in the past) Attaching patch. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.0 Status - Saturday the 17th
[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 Yup...just sent out a note in a new thread. Dain Sundstrom wrote: > So are we ready to spin up another set of binaries now? > > -dain > > On Dec 17, 2005, at 5:04 PM, Jeff Genender wrote: > >> Its fixed...I set a defaultHost GBean reference in the engine. >> >> David Jencks wrote: >> >>> >>> On Dec 17, 2005, at 1:14 PM, Jeff Genender wrote: >>> The Engine is starting before the host. After chatting with Dain...the problem seems to be... The plan is looking for a collection of hosts. But this does not seem to place the dependency when there is a collection, only when its a single GBean reference. Therefore its random of who gets started first...call it luck of the draw? Therefore, this can rear its head in HEAD (no pun intended). The problem stems from the fact that the user can have "n" number of hosts...and the Engine needs to wait until all of these are started. I would have hoped that the Collection reference would act like a direct GBean reference and wait until all have started, but this was my misunderstanding. Can this be a problem for other GBeans that have collection dependencies down the road - not just for Tomcat? IMHO, I think the fact the Engine is starting before the Hosts is dangerous and very bad. I'll work on a solution of some form... >>> >>> >>> The only possibility I've thought of so far is a linked list starting >>> with the Engine with a reference to the first or last Host, and each >>> Host with a reference to another. I use something like this to order >>> the servlet startup in jetty. >>> >>> david jencks >>> Jeff Dave Colasurdo wrote: > Does anybody know why the "unknown default host" warning still > occurs in > 1.0 but not in head? I thought Dain's fix was picked up by both > 1.0 and > head? I also thought the next 1.0 candidate build would be made from > the 1.0 branch and not head? Is this incorrect? > > Thanks > -Dave- > > Jeff Genender wrote: > >> I was too darn quick with my send button... >> >> Yes...let me follow up... >> >> Building form HEAD...this error (1377) does not occur...I should >> have >> made that more clear in all of my previous emails. >> >> Dave Colasurdo wrote: >> >>> I've extracted and built a fresh copy of the 1.0 branch.. >>> >>> I no longer see the TradeEJB exception reported in >>> GERONIMO-1372!! >>> >>> However, I still see the "unknown default host" reported in >>> GERONIMO-1377. So, doesn't look like the 1372 fix addresses the >>> 1377 >>> problem. Jeff had suggested building head. Is there some other >>> fix in >>> head that isn't in the 1.0 branch that addresses this? Last time I >>> built head (last night).. I didn't see the "unknown default host" >>> error. >>> >>> Also, concerning the conversation as to whether 1377 is a >>> showstopper.. >>> Of course I'm sure that Jeff's assessment that there is no >>> functional >>> problem is totally accurate. However, I suspect the presence of >>> this >>> message in the log at initial startup will cause confusion and many >>> questions among new v1 users. It may give the wrong initial >>> perception >>> that the default geronimo v1 configuration doesn't work properly. >>> >>> Hopefully Jeff will tell me that this is fixed in "head" and will >>> somehow be moved to v1.. >>> >>> On an unrelated note, I did see an exception during shutdown .. >>> >>> http://www.rafb.net/paste/results/H4vwRo78.html >>> >>> Is this covered under any other JIRA? >>> >>> BTW, How long do the www.rafb.net paste entries last? >>> >>> Thanks >>> -Dave- >>> >>> >>> Matt Hogstrom wrote: >>> Here is the lost of outstanding defects and their status: In Process GERONIMO-1364 - update welcome pages to point at HTTP redirects in the geronimo.apache.org site GERONIMO-1371 - Geronimo startup/shutdown issues GERONIMO-1375 - Invalid login to console should not produce stack trace GERONIMO-1377 - Startup Warning on tomcat - unknown default host. Completed GERONIMO-1363 - DayTrader still using old geronimo-spec files - applied by Matt GERONIMO-1372 - Exception during startup - TradeEJB - Fixed per Dain GERONIMO-1373 - DB info portle
Release 1.0 New Build Available
I have rebuilt the 1.0 server with the following JIRA's incorporated and this was at Committed revision 357442 of subversion. The server started successfully on my system (Mac OS) for both Tomcat and Jetty. I wiped out my Maven repo before rebuilding so to the best of my knowledge it works on my system and should work on yours. The images are available at http://people.apache.org/~hogstrom/geronimo-1.0 The files are: geronimo-tomcat-j2ee-1.0-20051218.tar.gz geronimo-tomcat-j2ee-1.0-20051218.zip geronimo-jetty-j2ee-1.0-20051218.tar.gz geronimo-jetty-j2ee-1.0-20051218.zip Note: These files extract into ./geronimo-1.0 which is different than the file name. Please ensure that any previous release of Geronimo installed in that directory tree has been removed. Please take time to download and run through the images and verify they start and stop without errors (there are some known ActiveMQ errors at shutdown around connection problems. I believe these can safely be ignored and will be fixed in a near term release.) Post comments back to the list and we'll incorporate the changes quickly and keep the train moving. I have not had time to download and retest these images to make sure they made it up correctly. Any problems reply back to this thread. Mr. Blevins and Mr. Jencks, I hate to impose on you but can you start a TCK run on this build and barring any major issues this might be it so it would be good to have verification of the build. Thanks - Matt Here is the list of defects incorporated into this build. Completed GERONIMO-1363 - DayTrader still using old geronimo-spec files - applied by Matt GERONIMO-1364 - update welcome pages to point at HTTP redirects in the geronimo.apache.org site GERONIMO-1372 - Exception during startup - TradeEJB - Fixed per Dain GERONIMO-1373 - DB info portlet not working correctly - Applied by Matt GERONIMO-1375 - Invalid login to console should not produce stack trace GERONIMO-1377 - Startup Warning on tomcat - unknown default host. - Fixed by Jeff Deferring to 1.1 GERONIMO-1371 - Geronimo startup/shutdown issues
