Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1347911.1156875262750.JavaMail.jira@brutus>
Date: Tue, 29 Aug 2006 11:14:22 -0700 (PDT)
From: "Ted Kirby (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Updated: (GERONIMO-2363) Console: create new pool using
 wizard, cannot use "show plan" button for any XA database, even derby
In-Reply-To: <8196437.1156875142301.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/GERONIMO-2363?page=all ]

Ted Kirby updated GERONIMO-2363:
--------------------------------

    Attachment: dbwizard_edit.jsp.patch

here is a patch, or rather a bypass.  I think the file needs more work, as described above in the JIRA.

> 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.1.1, 1.2
>            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