[
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
