[BUILD] 2.0: Failed for Revision: 603489
Geronimo Revision: 603489 built with tests included See the full build-0200.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/build-0200.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 25 minutes 9 seconds [INFO] Finished at: Wed Dec 12 02:39:31 EST 2007 [INFO] Final Memory: 228M/1013M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-0200-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 155.234 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-0200-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 157.449 sec FAILURE!
[BUILD] 2.1: Failed for Revision: 603506
OpenEJB trunk at 603491 Geronimo Revision: 603506 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/build-0300.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 29 minutes 52 seconds [INFO] Finished at: Wed Dec 12 03:40:17 EST 2007 [INFO] Final Memory: 293M/653M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-0300-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 55.204 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-0300-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.515 sec FAILURE!
[jira] Resolved: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3618. Resolution: Fixed New patch Committed revision 603548. Thank you for following up with a new fix on this. when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: HttpIoHandler.patch, patch.zip If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3689) should provide additional thread pool to isolate running of the callback event notification
[ https://issues.apache.org/jira/browse/GERONIMO-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550912 ] Rick McGuire commented on GERONIMO-3689: I think I have the patch backlog cleared up now, if you'd like to submit the patch. If I'm mistaken and there are other pending patches, please let me know. should provide additional thread pool to isolate running of the callback event notification - Key: GERONIMO-3689 URL: https://issues.apache.org/jira/browse/GERONIMO-3689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee The mina 1.1 documentation recommends disabling the default ThreadModel, as well as additionally providing an ExecutorFilter to isolate code that runs when events are notified (IoHandler) and thus in our case callback code. The default ThreadModel should be disabled by SocketConnectorConfig.setThreadModel(ThreadModel.MANUAL), and there should be an option of supplying a thread pool at the end of the filter chain. Please see http://mina.apache.org/configuring-thread-model.html for more discussion... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3686. Resolution: Fixed Assignee: Rick McGuire Committed revision 603540. Very nice set of additions. Thank you for the contribution Sangjin. AsyncHttpClient does not reuse connection even if connections are persistent Key: GERONIMO-3686 URL: https://issues.apache.org/jira/browse/GERONIMO-3686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3686.patch Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is opened, even though connections may be kept alive per HTTP spec. If connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire reassigned GERONIMO-3618: -- Assignee: Rick McGuire when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: HttpIoHandler.patch, patch.zip If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Genesis 1.3
+1 On 11/12/2007, at 8:58 PM, Jason Dillon wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... --jason
[RESULT] [VOTE] Release activation and jsvamail spec jars + javamail provider jars.
The vote to publish new releases of activation and javamail has passed with 8 +1 votes, no 0 votes and no -1 votes. Voting +1 were Rick McGuire Guillaume Nodet Alan Cabrera Jay McHugh Davanum Srinivas Jacek Laskowski Matt Hogstrom Kevan Miller
[jira] Commented: (GERONIMO-3697) Monitoring Console fix ups
[ https://issues.apache.org/jira/browse/GERONIMO-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550973 ] Anita Kulshreshtha commented on GERONIMO-3697: -- *rev 603613:* - Fix the tag used for generating names for TimeStatistics. The value returned is total count not current time. - Turn of annoying 'could not turn Stats on for .' message. Monitoring Console fix ups --- Key: GERONIMO-3697 URL: https://issues.apache.org/jira/browse/GERONIMO-3697 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha This issue is for minor fixes to monitoring console and monitoring agent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3697) Monitoring Console fix ups
[ https://issues.apache.org/jira/browse/GERONIMO-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550973 ] akulshre edited comment on GERONIMO-3697 at 12/12/07 6:19 AM: *rev 603613:* - Fix the tag used for generating names for TimeStatistics. The value returned is total count not current time. - Turn off annoying 'could not turn Stats on for .' message. was (Author: akulshre): *rev 603613:* - Fix the tag used for generating names for TimeStatistics. The value returned is total count not current time. - Turn of annoying 'could not turn Stats on for .' message. Monitoring Console fix ups --- Key: GERONIMO-3697 URL: https://issues.apache.org/jira/browse/GERONIMO-3697 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha This issue is for minor fixes to monitoring console and monitoring agent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550980 ] Mike McLean commented on GERONIMO-3523: --- The Tomcat option worked great. Thanks. java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan Fix For: 2.1 On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3693) monitoring client does not perform operations correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550983 ] Anita Kulshreshtha commented on GERONIMO-3693: -- Viet, Is it possible to use the min/max values given by TimeStatistics or Rangestatistics instead of computing it 'over the observed period'? The value returned is maximum since the measurement started which is not same as the max value during graphing period. monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3693.patch Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 603606
Geronimo Revision: 603606 built with tests included See the full build-0800.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/build-0800.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 25 minutes 20 seconds [INFO] Finished at: Wed Dec 12 08:37:28 EST 2007 [INFO] Final Memory: 229M/1010M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-0800-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 159.872 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-0800-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 157.691 sec FAILURE!
[jira] Commented: (GERONIMO-3693) monitoring client does not perform operations correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550987 ] Viet Hung Nguyen commented on GERONIMO-3693: Anita, Correct me if I'm wrong, but you are saying that min/max values by TimeStatistics and RangeStatistics should be just one value. So we shouldn't be able to display it in a line graph? monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3693.patch Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3702) monitoring client to display a graph when the graph name is clicked on
monitoring client to display a graph when the graph name is clicked on -- Key: GERONIMO-3702 URL: https://issues.apache.org/jira/browse/GERONIMO-3702 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen the monitoring client has graph names displayed as links so that the user can click on it to display the single graph, instead of having to add it to a view to look at the graph. this should be implemented to open up a new window with that graph. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3693) monitoring client does not perform operations correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551000 ] Anita Kulshreshtha commented on GERONIMO-3693: -- - Correct! There is no need to plot min and max value graphs separately. For example it does not make sense to plot graph for HeapSizeMax with min, max and avg! It would be nice if these values (min, max) could be used to plot say JVMHeapCurrent graph. - The TimeStatistics is a bit tricky. The min, max values are for totaltime/count. And it should be possible to draw 'count' graph and 'total time' graph separately. IIRC Erik said that Dojo 1.0.1 does not allow us to plot min, max, avg in the graph. If we switch to 1.0.1 we will need to redo this part monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3693.patch Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551004 ] Sangjin Lee commented on GERONIMO-3686: --- It seems that a couple of added files were not committed: src/test/java/org/apache/ahc/ConnectionReuseTest.java src/main/java/org/apache/ahc/codec/SessionCache.java The build must be broken without them... Could you please add them? Thanks. AsyncHttpClient does not reuse connection even if connections are persistent Key: GERONIMO-3686 URL: https://issues.apache.org/jira/browse/GERONIMO-3686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3686.patch Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is opened, even though connections may be kept alive per HTTP spec. If connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551008 ] Rick McGuire commented on GERONIMO-3686: Oops, sorry. I saw the new files but forgot to do the svn add before the commit. The files are there now: Committed revision 603657. AsyncHttpClient does not reuse connection even if connections are persistent Key: GERONIMO-3686 URL: https://issues.apache.org/jira/browse/GERONIMO-3686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3686.patch Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is opened, even though connections may be kept alive per HTTP spec. If connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.1: Failed for Revision: 603617
OpenEJB trunk at 603607 Geronimo Revision: 603617 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/build-0900.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 29 seconds [INFO] Finished at: Wed Dec 12 09:43:44 EST 2007 [INFO] Final Memory: 294M/1009M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-0900-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 56.506 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-0900-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 55.196 sec FAILURE!
[jira] Commented: (GERONIMO-3605) GShell-ize deployer commands
[ https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551024 ] Jarek Gawor commented on GERONIMO-3605: --- Fixed the 'connect' command to actaully connect to remote servers (revision 603667). Also fixed the 'disconnect' command to work properly (revision 603068). GShell-ize deployer commands Key: GERONIMO-3605 URL: https://issues.apache.org/jira/browse/GERONIMO-3605 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: Jarek Gawor Fix For: 2.1 make the cli deployer commands such as list-plugins accessible through gshell (and then remove the standalone deployer) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-97) License and Notice info for gshell-embeddable
License and Notice info for gshell-embeddable - Key: GSHELL-97 URL: https://issues.apache.org/jira/browse/GSHELL-97 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Components: Build Affects Versions: 1.0-alpha-1 Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.0-alpha-1 gshell-embeddable needs to License and Notice files to be included in the jar file. I'm not sure how to add these when using the shade plugin. Hoping Jason D can lend a hand. Will attach the license and notice files to this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-97) License and Notice info for gshell-embeddable
[ https://issues.apache.org/jira/browse/GSHELL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GSHELL-97: --- Attachment: embeddableNotice.txt embeddableLicense.txt Here are the files. There's some ripple on effects in gshell-assembly and the root license/notice in the source tree. I have made those changes and will commit separately. License and Notice info for gshell-embeddable - Key: GSHELL-97 URL: https://issues.apache.org/jira/browse/GSHELL-97 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Build Affects Versions: 1.0-alpha-1 Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.0-alpha-1 Attachments: embeddableLicense.txt, embeddableNotice.txt gshell-embeddable needs to License and Notice files to be included in the jar file. I'm not sure how to add these when using the shade plugin. Hoping Jason D can lend a hand. Will attach the license and notice files to this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3702) monitoring client to display a graph when the graph name is clicked on
[ https://issues.apache.org/jira/browse/GERONIMO-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3702: --- Attachment: geronimo-3702.patch Before committing please execute the following command: svn add client/client-war/src/main/webapp/monitoringPopUpGraph.jsp Thanks, Viet monitoring client to display a graph when the graph name is clicked on -- Key: GERONIMO-3702 URL: https://issues.apache.org/jira/browse/GERONIMO-3702 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3702.patch the monitoring client has graph names displayed as links so that the user can click on it to display the single graph, instead of having to add it to a view to look at the graph. this should be implemented to open up a new window with that graph. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3702) monitoring client to display a graph when the graph name is clicked on
[ https://issues.apache.org/jira/browse/GERONIMO-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551045 ] Erik B. Craig commented on GERONIMO-3702: - Patch Committed revision 603683. Thanks Viet monitoring client to display a graph when the graph name is clicked on -- Key: GERONIMO-3702 URL: https://issues.apache.org/jira/browse/GERONIMO-3702 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3702.patch the monitoring client has graph names displayed as links so that the user can click on it to display the single graph, instead of having to add it to a view to look at the graph. this should be implemented to open up a new window with that graph. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Genesis 1.3
+1 Jarek On Dec 11, 2007 4:58 AM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... --jason
[jira] Resolved: (GERONIMO-3689) should provide additional thread pool to isolate running of the callback event notification
[ https://issues.apache.org/jira/browse/GERONIMO-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3689. Resolution: Fixed Committed revision 603700. Very nice patch. This is not only a good enhancement, but it brings the implementation around to the recommended way of writing mina applications. Much simpler to implement than I expected. should provide additional thread pool to isolate running of the callback event notification - Key: GERONIMO-3689 URL: https://issues.apache.org/jira/browse/GERONIMO-3689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3689.patch The mina 1.1 documentation recommends disabling the default ThreadModel, as well as additionally providing an ExecutorFilter to isolate code that runs when events are notified (IoHandler) and thus in our case callback code. The default ThreadModel should be disabled by SocketConnectorConfig.setThreadModel(ThreadModel.MANUAL), and there should be an option of supplying a thread pool at the end of the filter chain. Please see http://mina.apache.org/configuring-thread-model.html for more discussion... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3689) should provide additional thread pool to isolate running of the callback event notification
[ https://issues.apache.org/jira/browse/GERONIMO-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3689: -- Attachment: 3689.patch a suggested patch should provide additional thread pool to isolate running of the callback event notification - Key: GERONIMO-3689 URL: https://issues.apache.org/jira/browse/GERONIMO-3689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3689.patch The mina 1.1 documentation recommends disabling the default ThreadModel, as well as additionally providing an ExecutorFilter to isolate code that runs when events are notified (IoHandler) and thus in our case callback code. The default ThreadModel should be disabled by SocketConnectorConfig.setThreadModel(ThreadModel.MANUAL), and there should be an option of supplying a thread pool at the end of the filter chain. Please see http://mina.apache.org/configuring-thread-model.html for more discussion... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: structure of GShell commands
I'm cool with putting all the deploy/* commands under geronimo/. Jarek On Dec 11, 2007 10:04 AM, Kevan Miller [EMAIL PROTECTED] wrote: We currently have the following structure for Geronimo GShell commands: geronimo/ start-server stop-server start-client deploy/ install-library disconnect deploy ... This doesn't make much sense to me. Let's either assume GShell is used for Geronimo server or assume that GShell can be used for multiple target environments, but not both... I think the current deploy/ commands should be under the geronimo tree. What do others think? I think applying a bit more structure, now, will minimize entropy over time... Anybody want to have a shot at proposing a command structure? --kevan
[jira] Resolved: (GERONIMO-3702) monitoring client to display a graph when the graph name is clicked on
[ https://issues.apache.org/jira/browse/GERONIMO-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3702. Resolution: Fixed Fix Version/s: 2.1 monitoring client to display a graph when the graph name is clicked on -- Key: GERONIMO-3702 URL: https://issues.apache.org/jira/browse/GERONIMO-3702 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3702.patch the monitoring client has graph names displayed as links so that the user can click on it to display the single graph, instead of having to add it to a view to look at the graph. this should be implemented to open up a new window with that graph. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551083 ] Sangjin Lee commented on GERONIMO-3638: --- OK, I think I understand what the right thing here is... For URL encoding, now the new RFC is 3986 and it obsoletes 2396. It states snippet When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. For example, the character A would be represented as A, the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as %C3%80, and the character KATAKANA LETTER A would be represented as %E3%82%A2. /snippet The default URL encoding charset used to be ISO-8859-1, but now it is UTF-8. The distinction becomes clear when you need to encode Unicode characters that do not exist in the ascii code page. In any case, I think the right thing to happen here is: - The default charset for URL encoding queries and forms shall be ISO-8859-1 - One should allow the charset to be overridden specifically with UTF-8 in mind Thoughts? should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3698) Installation of Admin Console fails with missing dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3698: - Assignee: Jarek Gawor Installation of Admin Console fails with missing dependency --- Key: GERONIMO-3698 URL: https://issues.apache.org/jira/browse/GERONIMO-3698 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 Installation of the Jetty admin console fails with a missing dependency. Starting with a framework assembly, I installed the Jetty Admin Console: 6: Geronimo Plugins :: Administration Console - Jetty (2.1-SNAPSHOT) The installation fails with a missing dependency for: org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car The installation works if I first install the jetty6 plugin. Here's the full failure info: Install Services [enter a comma separated list of numbers or 'q' to quit]: 6 Checking for status every 1000ms: Downloading org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car Copying commons-collections/commons-collections/3.1/jar to the repository (100%) Downloading org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Downloading org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar 320 kB of org.apache.tomcat/jasper-jdt/6.0.13/jar Starting org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car Installation Complete! Used existing: org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-core/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-common/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-management/2.1-SNAPSHOT/jar Used existing: asm/asm/2.2.3/jar Used existing: asm/asm-commons/2.2.3/jar Used existing: org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-transformer/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.plugins/pluto-support/2.1-SNAPSHOT/car Installed new: org.apache.pluto/pluto-portal-driver/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-portal-driver-impl/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-container/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-api/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-impl/1.2.0-G601060/jar Installed new: commons-logging/commons-logging-api/1.0.4/jar Installed new: commons-beanutils/commons-beanutils/1.6.1/jar Installed new: commons-collections/commons-collections/3.1/jar Installed new: javax.portlet/portlet-api/1.0/jar Installed new: org.apache.geronimo.configs/spring/2.1-SNAPSHOT/car Installed new: org.springframework/spring-core/2.0.5/jar Installed new: org.springframework/spring-beans/2.0.5/jar Installed new: org.springframework/spring-context/2.0.5/jar Installed new: org.springframework/spring-web/2.0.5/jar Installed new: org.codehaus.castor/castor/1.0.5/jar Installed new: org.apache.geronimo.plugins/geronimo-pluto/2.1-SNAPSHOT/jar Installed new: org.apache.pluto/pluto-taglib/1.2.0-G601060/jar Installed new: commons-digester/commons-digester/1.8/jar Installed new: org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee-schema/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.schema/geronimo-schema-jee_5/1.1/jar Installed new: org.apache.geronimo.schema/geronimo-schema-j2ee_1.4/1.2/jar Installed new: org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-webservices/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-reflect/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-test-ddbean/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-naming-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-security-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-j2ee-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-finder/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-web-2.5-builder/2.1-SNAPSHOT/jar Installed new:
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551100 ] Erik B. Craig commented on GERONIMO-3300: - Dojo 1.0.1 is now released, and it would be fantastic to get this in as part of the default full assembly alongside Dojo 0.4.3, particularly for use of the new charting libraries for the monitoring plugin. I am looking into making this happen as paul has described previously... Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3698) Installation of Admin Console fails with missing dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3698. --- Resolution: Fixed Updated PluginInstallerGBean to verify prerequisites before installing a plugin (revision 603730). Using the console-jetty example, the user will now see the following exception: org.apache.geronimo.kernel.repository.MissingDependencyException: org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car requires org.apache.geronimo.configs/jetty6// to be installed Installation of Admin Console fails with missing dependency --- Key: GERONIMO-3698 URL: https://issues.apache.org/jira/browse/GERONIMO-3698 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 Installation of the Jetty admin console fails with a missing dependency. Starting with a framework assembly, I installed the Jetty Admin Console: 6: Geronimo Plugins :: Administration Console - Jetty (2.1-SNAPSHOT) The installation fails with a missing dependency for: org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car The installation works if I first install the jetty6 plugin. Here's the full failure info: Install Services [enter a comma separated list of numbers or 'q' to quit]: 6 Checking for status every 1000ms: Downloading org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car Copying commons-collections/commons-collections/3.1/jar to the repository (100%) Downloading org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Downloading org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar 320 kB of org.apache.tomcat/jasper-jdt/6.0.13/jar Starting org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car Installation Complete! Used existing: org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-core/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-common/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-management/2.1-SNAPSHOT/jar Used existing: asm/asm/2.2.3/jar Used existing: asm/asm-commons/2.2.3/jar Used existing: org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-transformer/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.plugins/pluto-support/2.1-SNAPSHOT/car Installed new: org.apache.pluto/pluto-portal-driver/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-portal-driver-impl/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-container/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-api/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-impl/1.2.0-G601060/jar Installed new: commons-logging/commons-logging-api/1.0.4/jar Installed new: commons-beanutils/commons-beanutils/1.6.1/jar Installed new: commons-collections/commons-collections/3.1/jar Installed new: javax.portlet/portlet-api/1.0/jar Installed new: org.apache.geronimo.configs/spring/2.1-SNAPSHOT/car Installed new: org.springframework/spring-core/2.0.5/jar Installed new: org.springframework/spring-beans/2.0.5/jar Installed new: org.springframework/spring-context/2.0.5/jar Installed new: org.springframework/spring-web/2.0.5/jar Installed new: org.codehaus.castor/castor/1.0.5/jar Installed new: org.apache.geronimo.plugins/geronimo-pluto/2.1-SNAPSHOT/jar Installed new: org.apache.pluto/pluto-taglib/1.2.0-G601060/jar Installed new: commons-digester/commons-digester/1.8/jar Installed new: org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee-schema/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.schema/geronimo-schema-jee_5/1.1/jar Installed new: org.apache.geronimo.schema/geronimo-schema-j2ee_1.4/1.2/jar Installed new: org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-webservices/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-reflect/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-test-ddbean/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-naming-builder/2.1-SNAPSHOT/jar Installed new:
[BUILD] 2.0: Failed for Revision: 603704
Geronimo Revision: 603704 built with tests included See the full build-1400.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/build-1400.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 27 minutes 43 seconds [INFO] Finished at: Wed Dec 12 14:37:04 EST 2007 [INFO] Final Memory: 268M/862M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-1400-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 159.641 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 158.696 sec FAILURE!
Re: GShell ANSI colors support on Window.
Did you hear back from Marc about this? --jason On Dec 11, 2007, at 9:19 PM, Hiram Chirino wrote: It was a bit of bummer when I noticed that GShell has no colorized output on Windows. :( But I noticed that the Perl guys were able to do it. See the Win32::Console::ANSI' project [1]. So I updated the jline dll that is used on Windows with the c code that the Perl project is using and BAM!, we have color. I sent a note out to the jline project about this. Hopefully they incorporate this feature into future releases. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[BUILD] 2.1: Failed for Revision: 603721
OpenEJB trunk at 603704 Geronimo Revision: 603721 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/build-1500.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 28 minutes 14 seconds [INFO] Finished at: Wed Dec 12 15:38:39 EST 2007 [INFO] Final Memory: 295M/1010M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-1500-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 56.263 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-1500-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 53.531 sec FAILURE!
Re: GShell ANSI colors support on Window.
Not yet. On Dec 12, 2007 4:37 PM, Jason Dillon [EMAIL PROTECTED] wrote: Did you hear back from Marc about this? --jason On Dec 11, 2007, at 9:19 PM, Hiram Chirino wrote: It was a bit of bummer when I noticed that GShell has no colorized output on Windows. :( But I noticed that the Perl guys were able to do it. See the Win32::Console::ANSI' project [1]. So I updated the jline dll that is used on Windows with the c code that the Perl project is using and BAM!, we have color. I sent a note out to the jline project about this. Hopefully they incorporate this feature into future releases. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: [VOTE] Release Genesis 1.3
+1 Joe Jason Dillon wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... --jason
[jira] Issue Comment Edited: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551083 ] sjlee0 edited comment on GERONIMO-3638 at 12/12/07 3:04 PM: - OK, I think I understand what the right thing here is... For URL encoding, now the new RFC is 3986 and it obsoletes 2396. It states snippet When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. For example, the character A would be represented as A, the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as %C3%80, and the character KATAKANA LETTER A would be represented as %E3%82%A2. /snippet The default URL encoding charset used to be US-ASCII, but now it is UTF-8. The distinction becomes clear when you need to encode Unicode characters that do not exist in the ascii code page. In any case, I think the right thing to happen here is: - The default charset for URL encoding queries and forms shall be US-ASCII - One should allow the charset to be overridden specifically with UTF-8 in mind Independent of the URL encoding charset, one needs a charset with which to encode/decode HTTP elements. Currently it is using Charset.defaultCharset(). This is incorrect. It should use US-ASCII. Thoughts? was (Author: sjlee0): OK, I think I understand what the right thing here is... For URL encoding, now the new RFC is 3986 and it obsoletes 2396. It states snippet When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. For example, the character A would be represented as A, the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as %C3%80, and the character KATAKANA LETTER A would be represented as %E3%82%A2. /snippet The default URL encoding charset used to be ISO-8859-1, but now it is UTF-8. The distinction becomes clear when you need to encode Unicode characters that do not exist in the ascii code page. In any case, I think the right thing to happen here is: - The default charset for URL encoding queries and forms shall be ISO-8859-1 - One should allow the charset to be overridden specifically with UTF-8 in mind Thoughts? should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3638.patch Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3638: -- Attachment: (was: patch.zip) should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3638.patch Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3638: -- Attachment: 3638.patch a suggested fix should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3638.patch Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551151 ] Jay D. McHugh commented on GERONIMO-3300: - I have tried to create a plugin for dojo-1.0.1 under /plugins. But, it does not work the way I expected it to. So, any help on getting that to act like a real plugin would be great. Jay Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3698) Installation of Admin Console fails with missing dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-3698: I don't think there are any good uses for plugin prerequisites, and that we should use dependencies instead and remove the prereq capability entirely. I'll raise this on the dev list. I also wonder what changed recently since I was quite sure I had been using this plugin as a manual test case. Installation of Admin Console fails with missing dependency --- Key: GERONIMO-3698 URL: https://issues.apache.org/jira/browse/GERONIMO-3698 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 Installation of the Jetty admin console fails with a missing dependency. Starting with a framework assembly, I installed the Jetty Admin Console: 6: Geronimo Plugins :: Administration Console - Jetty (2.1-SNAPSHOT) The installation fails with a missing dependency for: org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car The installation works if I first install the jetty6 plugin. Here's the full failure info: Install Services [enter a comma separated list of numbers or 'q' to quit]: 6 Checking for status every 1000ms: Downloading org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car Copying commons-collections/commons-collections/3.1/jar to the repository (100%) Downloading org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Downloading org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar 320 kB of org.apache.tomcat/jasper-jdt/6.0.13/jar Starting org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car Installation Complete! Used existing: org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-core/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-common/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-management/2.1-SNAPSHOT/jar Used existing: asm/asm/2.2.3/jar Used existing: asm/asm-commons/2.2.3/jar Used existing: org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-transformer/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.plugins/pluto-support/2.1-SNAPSHOT/car Installed new: org.apache.pluto/pluto-portal-driver/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-portal-driver-impl/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-container/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-api/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-impl/1.2.0-G601060/jar Installed new: commons-logging/commons-logging-api/1.0.4/jar Installed new: commons-beanutils/commons-beanutils/1.6.1/jar Installed new: commons-collections/commons-collections/3.1/jar Installed new: javax.portlet/portlet-api/1.0/jar Installed new: org.apache.geronimo.configs/spring/2.1-SNAPSHOT/car Installed new: org.springframework/spring-core/2.0.5/jar Installed new: org.springframework/spring-beans/2.0.5/jar Installed new: org.springframework/spring-context/2.0.5/jar Installed new: org.springframework/spring-web/2.0.5/jar Installed new: org.codehaus.castor/castor/1.0.5/jar Installed new: org.apache.geronimo.plugins/geronimo-pluto/2.1-SNAPSHOT/jar Installed new: org.apache.pluto/pluto-taglib/1.2.0-G601060/jar Installed new: commons-digester/commons-digester/1.8/jar Installed new: org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee-schema/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.schema/geronimo-schema-jee_5/1.1/jar Installed new: org.apache.geronimo.schema/geronimo-schema-j2ee_1.4/1.2/jar Installed new: org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-webservices/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-reflect/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-test-ddbean/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-naming-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-security-builder/2.1-SNAPSHOT/jar Installed new:
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551154 ] Rick McGuire commented on GERONIMO-3703: Would making the createClientSSLContext() method protected rather than private be sufficient to provide this function? should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Jeff Genender [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. IMHO, it should definitely be a plugin (as should everything we ship), but I think it should be a plugin that is installed by default. I hear y'all :) If the plugin has to be installed by default, server/trunk/plugin is the best place for it. I will be moving it to server/trunk/plugin/monitoring/mconsole and server/trunk/plugin/monitoring/agent Viet has been working on fixing problems discussed elsewhere in this thread. It will be wired into the main build when it is fairly stable. Thanks Anita As pointed out in another email, monitoring is typically shipped and active in some form for most other application servers. If most of the users find it helpful to have automatically enabled, then its probably good that we do so. I would probably suggest as we get closer to a release date that we get more input from users on this subject so we can make a proper and informed decision. Jeff Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551162 ] Sangjin Lee commented on GERONIMO-3703: --- One idea would be to allow callers to pass in SSLContext. One thing to think about is whether we want to make it part of an AsyncHttpClient instance or pass in SSLContext as part of a sendRequest() call. I think Jeff was talking about using a single instance of AsyncHttpClient for various different hosts, and I think it makes sense. If we want to preserve that ability, then making SSLContext part of AsyncHttpClient (which it is today) may not be a good idea. Maybe we should pass it in explicitly when we call sendRequest()? should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Do Plugins need Prerequisites?
It was mainly for things like this plugin needs you to hook it up to a database where we can't reasonably provide a database -- you have to set up a DB instance and a connection pool with the right name and then the plugin will install. Or it could be a dependency on a proprietary driver or product where we can't distribute that product as a plugin dependency. I can think of a number of cases where there wouldn't be a way for us to provide a one-size-fits-all dependency. Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
Do Plugins need Prerequisites?
Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551169 ] Sangjin Lee commented on GERONIMO-3703: --- One could add SSLContext to HttpRequestMessage as an optional field. In FutureListener, we could check the protocol (if it is https), check to see if the SSL filter is already in the filter chain (to handle a situation where the session is being reused), and then check the SSLContext off of the HttpRequestMessage and use it. The only interesting case is what you want to do if you need an SSLContext and the caller didn't set it on HttpRequestMessage. Do you then throw a RuntimeException or do you use a default SSLContext (something like what's being used currently)? I would think using a default context might not be a bad idea, but others might differ. should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3703: -- Attachment: 3703.patch how about this? should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Attachments: 3703.patch Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Do Plugins need Prerequisites?
On Dec 12, 2007, at 3:39 PM, Aaron Mulder wrote: It was mainly for things like this plugin needs you to hook it up to a database where we can't reasonably provide a database -- you have to set up a DB instance and a connection pool with the right name and then the plugin will install. Or it could be a dependency on a proprietary driver or product where we can't distribute that product as a plugin dependency. I can think of a number of cases where there wouldn't be a way for us to provide a one-size-fits-all dependency. I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. thanks david jencks Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
[BUILD] 2.0: Failed for Revision: 603793
Geronimo Revision: 603793 built with tests included See the full build-2000.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/build-2000.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 27 minutes 50 seconds [INFO] Finished at: Wed Dec 12 20:36:40 EST 2007 [INFO] Final Memory: 268M/861M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-2000-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 157.402 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071212/logs-2000-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 156.147 sec FAILURE!
[BUILD] 2.1: Failed for Revision: 603800
OpenEJB trunk at 603794 Geronimo Revision: 603800 built with tests included See the full build-2100.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/build-2100.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071212 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 40 minutes 18 seconds [INFO] Finished at: Wed Dec 12 21:49:04 EST 2007 [INFO] Final Memory: 325M/863M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-2100-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 51.719 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071212/logs-2100-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 55.016 sec FAILURE!
