[ http://issues.apache.org/jira/browse/GERONIMO-2363?page=comments#action_12431340 ] Lin Sun commented on GERONIMO-2363: -----------------------------------
The whole block of code doesn't seem to be needed. I've ran test without them for create & edit xa and non-xa pool they work fine. This portion of deleted code is for generic pool, however the code resides in the <<< tag below. <c:when test="${pool.generic}"> ... </c:when> <c:otherwise> <%-- This is an XA or other connection factory that we don't have special parameter handling for --%> ...<<< the code for generic pool was here which isn't correct. </c:otherwise> Modified: trunk/geronimo/applications/console-standard/src/webapp/WEB-INF/view/dbwizard/edit.jsp =================================================================== <td>${ConfigParams[prop.key].description}</td> </tr> </c:forEach> - <tr><td colspan="2"> - <%-- Just to be safe, save all the Generic properties since we're not going to edit them here --%> - <input type="hidden" name="user" value="${pool.user}" /> - <input type="hidden" name="password" value="${pool.password}" /> - <input type="hidden" name="driverClass" value="${pool.driverClass}" /> - <input type="hidden" name="url" value="${pool.url}" /> - <input type="hidden" name="jars" value="${pool.jars}" /> - </td></tr> </c:otherwise> </c:choose> <!-- HEADER --> > Console: create new pool using wizard, cannot use "show plan" button for any > XA database, even derby > ---------------------------------------------------------------------------------------------------- > > Key: GERONIMO-2363 > URL: http://issues.apache.org/jira/browse/GERONIMO-2363 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, databases > Affects Versions: 1.2, 1.1.1 > Reporter: Ted Kirby > Attachments: dbwizard_edit.jsp.patch > > > From admin console, click Database Pools, Create new pool using the wizard, > choose an XA database type. If you select any driver jars, or none and click > show plan, you don't get a plan (all blank), but you do get this traceback in > the log/ on the console: > 13:48:53,552 ERROR [DatabasePoolPortlet] Unable to save connection pool > java.lang.IllegalArgumentException: Invalid id: > at > org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:899) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:340) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at > org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) > at > org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:419) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:869) > at java.lang.Thread.run(Thread.java:797) > The problem is an extra null value in the jars array. > If line 235 that adds a jars instance to the web page is removed, the > function works. > In general, I think there are too many jars on this page. > If pool.jars is defined coming into the page, then lines 62-64 will generate > more jars instances, and probably wreak more havoc. > These lines are mostly redundant to line 235. > I object to have the name jars refer to the db jar selection control, which I > feel should be its main purpose, as well as to these hidden fields to cache > values for the server. > There is also a lot of choosing going on, and the page either puts a jars > selection control on the page, or yet another instance of a hidden jars > containing ${pool.jars}. > I suggest cleaning all this up, and creating a separate name for the hidden > jars variable(s), if they are needed. -- 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