[BUILD] branches/2.0: Failed for Revision: 742280
Geronimo Revision: 742280 built with tests included See the full build-0200.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/build-0200.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 34 minutes 26 seconds [INFO] Finished at: Mon Feb 09 02:38:17 EST 2009 [INFO] Final Memory: 217M/857M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/logs-0200-tomcat/test.log [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.277 sec FAILURE! -- [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.273 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.619 sec FAILURE! -- [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/logs-0200-jetty/test.log [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.325 sec FAILURE! -- [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.315 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.678 sec FAILURE! -- [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.306 sec FAILURE!
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671759#action_12671759 ] Jack Cai commented on GERONIMO-4525: Thanks Jarek for your help! Ack to 1) 2). 3) It is because the cmd executing the batch script exits with the exit code of the last executied command, not the value of errorlevel. Take geronimo.bat as an example, the last command is @endlocal, so the exit code will always be 0. Calling cmd /cd exit /b %errorlevel% will set the exit code properly. This is helpful when the batch file is called from a program, for example from a Java program (use Runtime.getRuntime().exec()). Some other comment on your commit - geronimo.bat - better add cmd /cd exit /b 1 at line 253, to indicate user input errors - better add cmd /cd exit /b 0 at line 309, to reset the errorlevel, because some previous calls to set XXX= will result in errorlevel 1 :-( service_pr.bat - better add cmd /cd exit /b 1 at line 167, to indicate user input errors - remove unnecessary line 226-234 No effective exit code for all Windows commands --- Key: GERONIMO-4525 URL: https://issues.apache.org/jira/browse/GERONIMO-4525 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3 Environment: MS Windows Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525_Jack.patch There are multiple problems in the current Windows batch commands (including geronimo.bat, startup.bat, etc.) - It's not recommended to define an environment variable with the name ERRORLEVEL. See [1]. - Set a value to ERRORLEVEL has no effect to the exit code of the batch command (so the documented exit code 0 and 1 are not actually there). - The value of the ERRORLEVEL variable will also get unset when the @endlocal command is called. [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting
[ https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671783#action_12671783 ] caiwenjing commented on GERONIMO-4507: -- I give the priority of my language setting to English, but the admin console still displays chinese. Environment: windows xp professional 2002 sp3 + IE7 Admin console should honor the priority of user agent's language setting Key: GERONIMO-4507 URL: https://issues.apache.org/jira/browse/GERONIMO-4507 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3, 2.2 Environment: All Reporter: Jack Cai Assignee: Donald Woods Priority: Minor Fix For: 2.1.4, 2.2 Attachments: locale-priority.patch, locale-priority_fix.patch, locale-priority_V21.patch See discussion: http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George updated GERONIMO-4369: Attachment: G4369-0209.patch This is a patch that addresses the use case of child configurations being updated and restarted via a parent restart. The patch exposes a new method on Configuration i.e. getManageableAttributeStore that is accessible to all classes in the same package and the SimpleConfigurationManager applies overrides during a restart by calling the method appl. If no objections will apply within a few days The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Manu T George Priority: Blocker Fix For: 2.1.4, 2.2 Attachments: G-4369-0205.patch, G4369-0209.patch, Geronimo-4369-01.21.patch, Geronimo-4369-11.13.patch, Geronimo-4369-11.17.patch, Geronimo-4369-11.19.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-121) Constructor injection doesn't work with constructor argument of type array
Constructor injection doesn't work with constructor argument of type array
--
Key: XBEAN-121
URL: https://issues.apache.org/jira/browse/XBEAN-121
Project: XBean
Issue Type: Bug
Affects Versions: 3.5
Reporter: Piotr Bzdyl
A sample class:
package test;
public class SomeBean {
private final String[] arguments;
public SomeBean(String[] arguments) {
this.arguments = arguments;
}
}
And mapping configuration:
something = test.SomeBean
test.SomeBean(java.lang.String[]).parameterNames = arguments
Using:
myNs:something arguments=#.../
causes:
Caused by: org.springframework.beans.BeanInstantiationException: Could not
instantiate bean class [test.SomeBean]: No default constructor found; nested
exception is java.lang.NoSuchMethodException: test.SomeBean.init()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Bind to specific network interface - configuration
On Feb 9, 2009, at 12:11 AM, Jarek Gawor wrote:
Hey,
To configure most our Geronimo services to bind to a specific network
interface the user sets the ServerHostname property. However, for
Corba services the user must also set COSNamingHost, ORBSSLHost,
and ORBHost properties. So, altogether the user must configure 4
different properties. I'm wondering if we can just get rid of the
COSNamingHost, ORBSSLHost, and ORBHost properties and just use
ServerHostname property for everything? That should make things a
little easier for the user.
Sounds good to me. I don't know why those corba-based Host properties
were separate from ServerHostname to begin with. I searched email list
and didn't see anything signficant, other than they were different.
I wonder if it would be best to have all of the host settings to be
seperately customizable, but default to ServerHostname. Something like:
ServerHostname=0.0.0.0
ORBSSLHostname={ServerHostname}
ActiveMQHostname={ServerHostname}
JettyHostname={ServerHostname}
...
Then customize the JettyHostname, when you want to alter the ip
address used by web container clients...
--kevan
[jira] Created: (GERONIMO-4533) Fix This is ridiculous error messages on command execution
Fix This is ridiculous error messages on command execution Key: GERONIMO-4533 URL: https://issues.apache.org/jira/browse/GERONIMO-4533 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.3, 2.2 Reporter: Kevan Miller Fix For: 2.1.4, 2.2 Depending on the terminal you're running from, some commands will display a This is ridiculous error message: bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Username: system system Password: *** Module com.test/testwar/1.0/war unloaded. Module com.test/testwar/1.0/war uninstalled. line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 Exception in thread main java.lang.IllegalArgumentException: This is ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 at org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4533) Fix This is ridiculous error messages on command execution
[ https://issues.apache.org/jira/browse/GERONIMO-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-4533: -- Assignee: Kevan Miller Fix This is ridiculous error messages on command execution Key: GERONIMO-4533 URL: https://issues.apache.org/jira/browse/GERONIMO-4533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.3, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.1.4, 2.2 Depending on the terminal you're running from, some commands will display a This is ridiculous error message: bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Username: system system Password: *** Module com.test/testwar/1.0/war unloaded. Module com.test/testwar/1.0/war uninstalled. line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 Exception in thread main java.lang.IllegalArgumentException: This is ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 at org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build fails with javax.el.ELException: Function 'f:length' not found
On Sun, Feb 8, 2009 at 2:43 AM, Jarek Gawor jga...@gmail.com wrote: Start with clean m2 repo. It's worked like a charm. Thanks! Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-4533) Fix This is ridiculous error messages on command execution
[ https://issues.apache.org/jira/browse/GERONIMO-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671917#action_12671917 ] Kevan Miller commented on GERONIMO-4533: Ooops. The above output contained some debug statements, but you get the gist... Some terminals are returning a terminal width of zero to JLine ConsoleReader (e.g. emacs shell). I added code to set a default terminal width, if the terminal width is zero. Fix This is ridiculous error messages on command execution Key: GERONIMO-4533 URL: https://issues.apache.org/jira/browse/GERONIMO-4533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.3, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.1.4, 2.2 Depending on the terminal you're running from, some commands will display a This is ridiculous error message: bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Username: system system Password: *** Module com.test/testwar/1.0/war unloaded. Module com.test/testwar/1.0/war uninstalled. line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 Exception in thread main java.lang.IllegalArgumentException: This is ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 at org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4533) Fix This is ridiculous error messages on command execution
[ https://issues.apache.org/jira/browse/GERONIMO-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4533. -- Resolution: Fixed Fix This is ridiculous error messages on command execution Key: GERONIMO-4533 URL: https://issues.apache.org/jira/browse/GERONIMO-4533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.3, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.1.4, 2.2 Depending on the terminal you're running from, some commands will display a This is ridiculous error message: bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Username: system system Password: *** Module com.test/testwar/1.0/war unloaded. Module com.test/testwar/1.0/war uninstalled. line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 Exception in thread main java.lang.IllegalArgumentException: This is ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 at org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bind to specific network interface - configuration
On Mon, Feb 9, 2009 at 9:48 AM, Kevan Miller kevan.mil...@gmail.com wrote:
On Feb 9, 2009, at 12:11 AM, Jarek Gawor wrote:
Hey,
To configure most our Geronimo services to bind to a specific network
interface the user sets the ServerHostname property. However, for
Corba services the user must also set COSNamingHost, ORBSSLHost,
and ORBHost properties. So, altogether the user must configure 4
different properties. I'm wondering if we can just get rid of the
COSNamingHost, ORBSSLHost, and ORBHost properties and just use
ServerHostname property for everything? That should make things a
little easier for the user.
Sounds good to me. I don't know why those corba-based Host properties were
separate from ServerHostname to begin with. I searched email list and didn't
see anything signficant, other than they were different.
I wonder if it would be best to have all of the host settings to be
seperately customizable, but default to ServerHostname. Something like:
ServerHostname=0.0.0.0
ORBSSLHostname={ServerHostname}
ActiveMQHostname={ServerHostname}
JettyHostname={ServerHostname}
...
Then customize the JettyHostname, when you want to alter the ip address used
by web container clients...
Yes, that would be nice but we don't support this type of variable
expansion in config-substitutions.properties right now AFAIK.
Something we might need to add first.
Jarek
Re: Bind to specific network interface - configuration
On Feb 9, 2009, at 9:03 AM, Jarek Gawor wrote:
On Mon, Feb 9, 2009 at 9:48 AM, Kevan Miller
kevan.mil...@gmail.com wrote:
On Feb 9, 2009, at 12:11 AM, Jarek Gawor wrote:
Hey,
To configure most our Geronimo services to bind to a specific
network
interface the user sets the ServerHostname property. However, for
Corba services the user must also set COSNamingHost, ORBSSLHost,
and ORBHost properties. So, altogether the user must configure 4
different properties. I'm wondering if we can just get rid of the
COSNamingHost, ORBSSLHost, and ORBHost properties and just use
ServerHostname property for everything? That should make things a
little easier for the user.
Sounds good to me. I don't know why those corba-based Host
properties were
separate from ServerHostname to begin with. I searched email list
and didn't
see anything signficant, other than they were different.
I wonder if it would be best to have all of the host settings to be
seperately customizable, but default to ServerHostname. Something
like:
ServerHostname=0.0.0.0
ORBSSLHostname={ServerHostname}
ActiveMQHostname={ServerHostname}
JettyHostname={ServerHostname}
...
Then customize the JettyHostname, when you want to alter the ip
address used
by web container clients...
Yes, that would be nice but we don't support this type of variable
expansion in config-substitutions.properties right now AFAIK.
Something we might need to add first.
I think we can use ServerHostName for all of them ... this involves
changing the plugin metadata in the poms for the plugins.
If someone wants to use different host names for the different plugins
they can change the config.xml for the gbeans to use a different
substitution variable name. There's an automated way to do this using
an overrides file if you are assembling a custom server using maven,
otherwise I think anyone wanting to do this will be sophisticated
enough to edit config.xml by hand.
thanks
david jencks
Jarek
[jira] Commented: (GERONIMO-4533) Fix This is ridiculous error messages on command execution
[ https://issues.apache.org/jira/browse/GERONIMO-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671939#action_12671939 ] Jeff Lu commented on GERONIMO-4533: --- Thanks Kevan for fixing this so quickly. You've provided me with excellent support. Fix This is ridiculous error messages on command execution Key: GERONIMO-4533 URL: https://issues.apache.org/jira/browse/GERONIMO-4533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.3, 2.2 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.1.4, 2.2 Depending on the terminal you're running from, some commands will display a This is ridiculous error message: bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Username: system system Password: *** Module com.test/testwar/1.0/war unloaded. Module com.test/testwar/1.0/war uninstalled. line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 Exception in thread main java.lang.IllegalArgumentException: This is ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 at org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4485: - Assignee: Jarek Gawor (was: Kan Ogawa) Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4 Reporter: Kan Ogawa Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4 Attachments: activemq-portlets.patch, console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671978#action_12671978 ] Jarek Gawor commented on GERONIMO-4485: --- Committed the following patches to branches/2.1 (revision 742700): activemq-portlets.patch, console-base-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch, debugviews-portlets.patch, and console-portal-driver.patch. Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4 Reporter: Kan Ogawa Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4 Attachments: activemq-portlets.patch, console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671996#action_12671996 ] Jarek Gawor commented on GERONIMO-4485: --- Committed the following patches to branches/2.1 (revision 742717): mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, and plancreator-portlets.patch. Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4 Reporter: Kan Ogawa Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4 Attachments: activemq-portlets.patch, console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671994#action_12671994
]
Jason Warner commented on GERONIMO-3759:
If you're still having trouble with this, please post the config.xml that you
are using. I just attempted to start the server using the configuration
provided here and had no issues.
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4485. --- Resolution: Fixed Committed some changes I missed in my initial commit (revision 742723). All patches should be committed now. If I missed anything please re-open or create a new bug. Thanks a lot for porting these patches! Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4 Reporter: Kan Ogawa Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4 Attachments: activemq-portlets.patch, console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bind to specific network interface - configuration
On Mon, Feb 9, 2009 at 12:17 PM, David Jencks david_jen...@yahoo.com wrote:
On Feb 9, 2009, at 9:03 AM, Jarek Gawor wrote:
On Mon, Feb 9, 2009 at 9:48 AM, Kevan Miller kevan.mil...@gmail.com
wrote:
On Feb 9, 2009, at 12:11 AM, Jarek Gawor wrote:
Hey,
To configure most our Geronimo services to bind to a specific network
interface the user sets the ServerHostname property. However, for
Corba services the user must also set COSNamingHost, ORBSSLHost,
and ORBHost properties. So, altogether the user must configure 4
different properties. I'm wondering if we can just get rid of the
COSNamingHost, ORBSSLHost, and ORBHost properties and just use
ServerHostname property for everything? That should make things a
little easier for the user.
Sounds good to me. I don't know why those corba-based Host properties
were
separate from ServerHostname to begin with. I searched email list and
didn't
see anything signficant, other than they were different.
I wonder if it would be best to have all of the host settings to be
seperately customizable, but default to ServerHostname. Something like:
ServerHostname=0.0.0.0
ORBSSLHostname={ServerHostname}
ActiveMQHostname={ServerHostname}
JettyHostname={ServerHostname}
...
Then customize the JettyHostname, when you want to alter the ip address
used
by web container clients...
Yes, that would be nice but we don't support this type of variable
expansion in config-substitutions.properties right now AFAIK.
Something we might need to add first.
I think we can use ServerHostName for all of them ... this involves changing
the plugin metadata in the poms for the plugins.
If someone wants to use different host names for the different plugins they
can change the config.xml for the gbeans to use a different substitution
variable name. There's an automated way to do this using an overrides file
if you are assembling a custom server using maven, otherwise I think anyone
wanting to do this will be sophisticated enough to edit config.xml by hand.
Right. That's what I was thinking too. I'll go ahead and make
everything use ServerHostname property for now. We can switch to what
Kevan suggested once/if we have support for it.
Jarek
Re: Bind to specific network interface - configuration
On Feb 9, 2009, at 4:52 PM, Jarek Gawor wrote: On Mon, Feb 9, 2009 at 12:17 PM, David Jencks david_jen...@yahoo.com wrote: On Feb 9, 2009, at 9:03 AM, Jarek Gawor wrote: snip I think we can use ServerHostName for all of them ... this involves changing the plugin metadata in the poms for the plugins. If someone wants to use different host names for the different plugins they can change the config.xml for the gbeans to use a different substitution variable name. There's an automated way to do this using an overrides file if you are assembling a custom server using maven, otherwise I think anyone wanting to do this will be sophisticated enough to edit config.xml by hand. Right. That's what I was thinking too. I'll go ahead and make everything use ServerHostname property for now. We can switch to what Kevan suggested once/if we have support for it. Yep. Didn't mean to imply that my suggestion would just work... Just recording what I thought would be most useful to users... --kevan
[jira] Commented: (GERONIMO-4442) Unable to configure IP address for many listening ports
[ https://issues.apache.org/jira/browse/GERONIMO-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672047#action_12672047 ] Jarek Gawor commented on GERONIMO-4442: --- Btw, I updated the code so that ServerHostname property will configure the hostname for Corba services also (that is, got rid off COSNamingHost, ORBSSLHost, and ORBHost properties). Committed to trunk (revision 742781) and branches/2.1 (revision 742782). Unable to configure IP address for many listening ports --- Key: GERONIMO-4442 URL: https://issues.apache.org/jira/browse/GERONIMO-4442 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Critical Fix For: 2.1.4, 2.2 Attachments: G4222_ORBConfigAdapter.patch I tried to configure the listening IP address for our server sockets. I configured all 'host' properties in config-substitution.properties to be '127.0.0.1' and got the following results: Listening on Ports: 1050 127.0.0.1 CORBA Naming Service 1099 127.0.0.1 RMI Naming 1527 127.0.0.1 Derby Connector 2001 127.0.0.1 OpenEJB ORB Adapter 4201 127.0.0.1 OpenEJB Daemon 6882 127.0.0.1 OpenEJB ORB Adapter 8009 127.0.0.1 Tomcat Connector AJP AJP 8080 127.0.0.1 Tomcat Connector HTTP BIO HTTP 8443 127.0.0.1 Tomcat Connector HTTPS BIO HTTPS 127.0.0.1 JMX Remoting Connector 61613 127.0.0.1 ActiveMQ Transport Connector 61616 127.0.0.1 ActiveMQ Transport Connector Unfortunately, that's not accurate. netstat reveals the following actual results: $ netstat -an | grep LISTEN tcp4 0 0 *.6882 *.*LISTEN tcp4 0 0 *.2001 *.*LISTEN tcp4 0 0 *.63519*.*LISTEN tcp4 0 0 *.1050 *.*LISTEN tcp4 0 0 127.0.0.1.4201 *.*LISTEN tcp4 0 0 127.0.0.1.61613*.*LISTEN tcp4 0 0 127.0.0.1.61616*.*LISTEN tcp4 0 0 127.0.0.1.1527 *.*LISTEN tcp4 0 0 127.0.0.1.8443 *.*LISTEN tcp4 0 0 127.0.0.1.8009 *.*LISTEN tcp4 0 0 127.0.0.1.8080 *.*LISTEN tcp4 0 0 *. *.*LISTEN tcp4 0 0 *.1099 *.*LISTEN Configuring the host properties to be an actual ip address/hostname is a bit worse (not sure what's going on with ActiveMQ): Listening on Ports: 1050 10.0.1.196 CORBA Naming Service 1099 10.0.1.196 RMI Naming 1527 10.0.1.196 Derby Connector 2001 10.0.1.196 OpenEJB ORB Adapter 4201 10.0.1.196 OpenEJB Daemon 6882 10.0.1.196 OpenEJB ORB Adapter 8009 10.0.1.196 Tomcat Connector AJP AJP 8080 10.0.1.196 Tomcat Connector HTTP BIO HTTP 8443 10.0.1.196 Tomcat Connector HTTPS BIO HTTPS 10.0.1.196 JMX Remoting Connector 61613 0.0.0.0ActiveMQ Transport Connector 61616 0.0.0.0ActiveMQ Transport Connector Netstat shows: $ netstat -an | grep LISTEN tcp6 0 0 fe80::1%lo0.631*.*LISTEN tcp4 0 0 *.6882 *.*LISTEN tcp4 0 0 *.2001 *.*LISTEN tcp4 0 0 *.63569*.*LISTEN tcp4 0 0 *.1050 *.*LISTEN tcp4 0 0 10.0.1.196.4201*.*LISTEN tcp4 0 0 *.61613*.*LISTEN tcp4 0 0 *.61616*.*LISTEN tcp4 0 0 10.0.1.196.1527*.*LISTEN tcp4 0 0 10.0.1.196.8443*.*LISTEN tcp4 0 0 10.0.1.196.8009*.*LISTEN tcp4 0 0 10.0.1.196.8080*.*LISTEN tcp4 0 0 *. *.*LISTEN tcp4 0 0 *.1099 *.*LISTEN -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672099#action_12672099 ] Jarek Gawor commented on GERONIMO-4525: --- Committed all changes to service_pr.bat and committed the change at line 253 to geronimo.bat as you suggested (revision 742810). Can you explain why the change at 309 is necessary? I'm pretty sure that ERRORLEVEL will be reset when %_EXECJAVA% will be executed. As to 3) I'll experiment some more to be sure but @endlocal was not resetting the ERRORLEVEL for me. But @setlocal was. No effective exit code for all Windows commands --- Key: GERONIMO-4525 URL: https://issues.apache.org/jira/browse/GERONIMO-4525 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3 Environment: MS Windows Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525_Jack.patch There are multiple problems in the current Windows batch commands (including geronimo.bat, startup.bat, etc.) - It's not recommended to define an environment variable with the name ERRORLEVEL. See [1]. - Set a value to ERRORLEVEL has no effect to the exit code of the batch command (so the documented exit code 0 and 1 are not actually there). - The value of the ERRORLEVEL variable will also get unset when the @endlocal command is called. [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[
https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672104#action_12672104
]
Jarek Gawor commented on GERONIMO-4525:
---
Here's a simple batch and Java code that I used to experiment to whether
resetting ERRORLEVEL to 0 or calling is cmd /c exit /b %errorlevel%:
Test.java:
{code}
public class Test {
public static void main(String [] args) throws Exception {
System.out.println(args[0]);
System.exit(Integer.parseInt(args[0]));
}
}
{code}
Test.bat:
{code}
@echo off
@setlocal enableextensions
set foo=
echo %errorlevel%
java Test %1
echo %errorlevel%
@endlocal
echo %errorlevel%
{code}
Then when you execute Test.bat 0 or Test.bat 50 and check echo %ERRORLEVEL%
after executing it you should see that the %ERRORLEVEL% is set to the right
value without doing anything extra.
No effective exit code for all Windows commands
---
Key: GERONIMO-4525
URL: https://issues.apache.org/jira/browse/GERONIMO-4525
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.3
Environment: MS Windows
Reporter: Jack Cai
Assignee: Jarek Gawor
Fix For: 2.1.4, 2.2
Attachments: Geronimo-4525_Jack.patch
There are multiple problems in the current Windows batch commands (including
geronimo.bat, startup.bat, etc.)
- It's not recommended to define an environment variable with the name
ERRORLEVEL. See [1].
- Set a value to ERRORLEVEL has no effect to the exit code of the batch
command (so the documented exit code 0 and 1 are not actually there).
- The value of the ERRORLEVEL variable will also get unset when the
@endlocal command is called.
[1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx
--
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-4525) No effective exit code for all Windows commands
[
https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672104#action_12672104
]
ga...@mcs.anl.gov edited comment on GERONIMO-4525 at 2/9/09 5:33 PM:
---
Here's a simple batch and Java code that I used to experiment to whether
resetting ERRORLEVEL to 0 or calling is cmd /c exit /b %errorlevel%:
Test.java:
{code}
public class Test {
public static void main(String [] args) throws Exception {
System.out.println(args[0]);
System.exit(Integer.parseInt(args[0]));
}
}
{code}
Test.bat:
{code}
@echo off
@setlocal enableextensions
set foo=
echo %errorlevel%
java Test %1
echo %errorlevel%
@endlocal
echo %errorlevel%
{code}
Then when you execute Test.bat 0 or Test.bat 50 and check echo %ERRORLEVEL%
after executing it you should see that the %ERRORLEVEL% is set to the right
value without doing anything extra. So based on this I think resetting the
ERRORLEVEL or calling cmd /c exit /b %errorlevel%: at the end of the batch
file is unnecessary.
was (Author: ga...@mcs.anl.gov):
Here's a simple batch and Java code that I used to experiment to whether
resetting ERRORLEVEL to 0 or calling is cmd /c exit /b %errorlevel%:
Test.java:
{code}
public class Test {
public static void main(String [] args) throws Exception {
System.out.println(args[0]);
System.exit(Integer.parseInt(args[0]));
}
}
{code}
Test.bat:
{code}
@echo off
@setlocal enableextensions
set foo=
echo %errorlevel%
java Test %1
echo %errorlevel%
@endlocal
echo %errorlevel%
{code}
Then when you execute Test.bat 0 or Test.bat 50 and check echo %ERRORLEVEL%
after executing it you should see that the %ERRORLEVEL% is set to the right
value without doing anything extra.
No effective exit code for all Windows commands
---
Key: GERONIMO-4525
URL: https://issues.apache.org/jira/browse/GERONIMO-4525
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.3
Environment: MS Windows
Reporter: Jack Cai
Assignee: Jarek Gawor
Fix For: 2.1.4, 2.2
Attachments: Geronimo-4525_Jack.patch
There are multiple problems in the current Windows batch commands (including
geronimo.bat, startup.bat, etc.)
- It's not recommended to define an environment variable with the name
ERRORLEVEL. See [1].
- Set a value to ERRORLEVEL has no effect to the exit code of the batch
command (so the documented exit code 0 and 1 are not actually there).
- The value of the ERRORLEVEL variable will also get unset when the
@endlocal command is called.
[1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Fwd: ApacheCon Europe 2009: Early Bird Deadline Extended until 13th of February
All, FYI --kevan Begin forwarded message: From: Lars Eilebrecht l...@apache.org Date: February 9, 2009 8:35:18 PM EST To: annou...@apachecon.com Subject: ApacheCon Europe 2009: Early Bird Deadline Extended until 13th of February Here's some great news for everyone who's thinking of traveling to Amsterdam for this year's ApacheCon Europe. The Early Bird deadline has been extended to Friday, February 13th - and remember, there is a discount of 150 Euro on registration for anyone staying at the Mövenpick Hotel. Register at http://www.eu.apachecon.com. ApacheCon is a week of open source goodness straight from the source of The Apache Software Foundation: - More than 60 1-Hour Sessions on System Administration, Development, Data Mining and Search Technologies, Enterprise Web Services, SOA, and Cloud Technologies, Open Source Business and Community, and more - Over a dozen Training Workshops from industry experts (see below) - World-class Keynotes and vendor Expo - Lightning Talks and Birds-of-a-Feather sessions - New this year: Geeks for Geeks Track, BarCampApache, and Hackathon! ApacheCon Europe 2009 features 2-day, 1-day, and half-day Training Workshops on the following topics: Data Mining and Search Technologies --- - Lucene Boot Camp (Grant Ingersoll) - Solr Boot Camp (Erik Hatcher) The Next Generation of Web Data Storage --- - Building Standalone CouchDB Applications (J. Chris Anderson) - High Performance CouchDB (J. Chris Anderson) Cloud and Distributed Computing Technologies - Hadoop Tools and Tricks for Data Processing Pipelines (Christophe Bisciglia and Aaron Kimball) System Administration - - Apache HTTP Server - Nuts to Bolts (Jim Jagielski) - Everything Tomcat - Administering, Tuning, Troubleshooting and Developing (Mark Thomas) Developing State-of-the-Art Web Applications - A Day of REST (J Aaron Farr) - Apache CXF - Developing and Deploying Open Source SOA Endpoints (Adrian Trenaman) - Ajax on Struts 2: How a Second Generation Web Application Framework Meets the Demands of RIA (Chad Michael Davis) - Behavior-Driving Your Apache Wicket Application: Making the Most of Webdriver and JDave-Wicket (Timo Rantalaiho) Building and Managing Java-based Projects - - Maven Workshop (Zeger Hendrikse) Professional Media Trainings - Media Analyst Training (Sally Khudairi) - Intermediate Media Analyst Training (Sally Khudairi) We hope to see you on the 23-27 March at the Mövenpick Hotel in Amsterdam! Visit http://www.eu.apachecon.com for further information and registration details. Interested in sponsoring the ApacheCon conferences? Please contact Delia Frees at de...@apachecon.com for further information. -- ApacheCon Europe 2009 Team planners-2009-eu at apachecon.com http://www.eu.apachecon.com - To unsubscribe, e-mail: announce-unsubscr...@apachecon.com For additional commands, e-mail: announce-h...@apachecon.com
[BUILD] branches/2.0: Failed for Revision: 742794
Geronimo Revision: 742794 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/build-2000.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 34 minutes 57 seconds [INFO] Finished at: Mon Feb 09 20:42:00 EST 2009 [INFO] Final Memory: 216M/859M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/logs-2000-tomcat/test.log [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.273 sec FAILURE! -- [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.259 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.612 sec FAILURE! -- [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.282 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090209/logs-2000-jetty/test.log [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.338 sec FAILURE! -- [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.661 sec FAILURE! -- [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.319 sec FAILURE!
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[
https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672124#action_12672124
]
Jack Cai commented on GERONIMO-4525:
Why reset errorlevel at line 309 in geronimo.bat -
because issuing geronimo.bat run will call start java.exe ..., which will
not reset errorlevel.
Why call cmd /c exit /b %errorlevel% at the end of each batch script -
to set the exit code of the SCRIPT. For example, the below Java code calls the
gsh.bat and then check its exit code. Without cmd /c exit /b %errorlevel%,
the gsh.bat will always exit with code 0 (I already explained the reason in the
previous comment), and there is NO way to read the errorlevel value because the
process executing the script already ends.
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
public class ProcessTest {
static class StreamGobbler extends Thread
{
InputStream is;
String type;
StreamGobbler(InputStream is, String type)
{
this.is = is;
this.type = type;
}
public void run()
{
try
{
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String line=null;
while ( (line = br.readLine()) != null)
System.out.println(type + + line);
} catch (IOException e) {
e.printStackTrace();
}
}
}
/**
* @param args
*/
public static void main(String[] args) throws Exception {
String[] cmds = new String[] {
D:\\Dev\\wasce-server-2.1.1.1\\bin\\gsh.bat,
-c,
geronimo/wait-for-server -u system -w manager -t 10 };
Process ps = Runtime.getRuntime().exec(cmds, null,
new File(D:\\Dev\\wasce-server-2.1.1.1\\bin));
StreamGobbler errorGobbler = new
StreamGobbler(ps.getErrorStream(), ERROR);
StreamGobbler outputGobbler = new
StreamGobbler(ps.getInputStream(), OUTPUT);
errorGobbler.start();
outputGobbler.start();
// Print the exit code
int exitVal = ps.waitFor();
System.out.println(ExitValue: + exitVal);
}
}
Hope this helps. Thanks again Jarek!
No effective exit code for all Windows commands
---
Key: GERONIMO-4525
URL: https://issues.apache.org/jira/browse/GERONIMO-4525
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.3
Environment: MS Windows
Reporter: Jack Cai
Assignee: Jarek Gawor
Fix For: 2.1.4, 2.2
Attachments: Geronimo-4525_Jack.patch
There are multiple problems in the current Windows batch commands (including
geronimo.bat, startup.bat, etc.)
- It's not recommended to define an environment variable with the name
ERRORLEVEL. See [1].
- Set a value to ERRORLEVEL has no effect to the exit code of the batch
command (so the documented exit code 0 and 1 are not actually there).
- The value of the ERRORLEVEL variable will also get unset when the
@endlocal command is called.
[1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx
--
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-4525) No effective exit code for all Windows commands
[
https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672124#action_12672124
]
caijunj edited comment on GERONIMO-4525 at 2/9/09 6:38 PM:
Why reset errorlevel at line 309 in geronimo.bat -
because issuing geronimo.bat run will call start java.exe ..., which will
not reset errorlevel.
Why call cmd /c exit /b %errorlevel% at the end of each batch script -
to set the exit code of the SCRIPT. For example, the below Java code calls the
gsh.bat and then check its exit code. Without cmd /c exit /b %errorlevel%,
the gsh.bat will always exit with code 0 (I already explained the reason in the
previous comment), and there is NO way to read the errorlevel value because the
process executing the script already ends.
{code}
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
public class ProcessTest {
static class StreamGobbler extends Thread
{
InputStream is;
String type;
StreamGobbler(InputStream is, String type)
{
this.is = is;
this.type = type;
}
public void run()
{
try
{
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String line=null;
while ( (line = br.readLine()) != null)
System.out.println(type + + line);
} catch (IOException e) {
e.printStackTrace();
}
}
}
/**
* @param args
*/
public static void main(String[] args) throws Exception {
String[] cmds = new String[] {
D:\\Dev\\wasce-server-2.1.1.1\\bin\\gsh.bat,
-c,
geronimo/wait-for-server -u system -w manager -t 10 };
Process ps = Runtime.getRuntime().exec(cmds, null,
new File(D:\\Dev\\wasce-server-2.1.1.1\\bin));
StreamGobbler errorGobbler = new
StreamGobbler(ps.getErrorStream(), ERROR);
StreamGobbler outputGobbler = new
StreamGobbler(ps.getInputStream(), OUTPUT);
errorGobbler.start();
outputGobbler.start();
// Print the exit code
int exitVal = ps.waitFor();
System.out.println(ExitValue: + exitVal);
}
}
{code}
Hope this helps. Thanks again Jarek!
was (Author: caijunj):
Why reset errorlevel at line 309 in geronimo.bat -
because issuing geronimo.bat run will call start java.exe ..., which will
not reset errorlevel.
Why call cmd /c exit /b %errorlevel% at the end of each batch script -
to set the exit code of the SCRIPT. For example, the below Java code calls the
gsh.bat and then check its exit code. Without cmd /c exit /b %errorlevel%,
the gsh.bat will always exit with code 0 (I already explained the reason in the
previous comment), and there is NO way to read the errorlevel value because the
process executing the script already ends.
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
public class ProcessTest {
static class StreamGobbler extends Thread
{
InputStream is;
String type;
StreamGobbler(InputStream is, String type)
{
this.is = is;
this.type = type;
}
public void run()
{
try
{
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String line=null;
while ( (line = br.readLine()) != null)
System.out.println(type + + line);
} catch (IOException e) {
e.printStackTrace();
}
}
}
/**
* @param args
*/
public static void main(String[] args) throws Exception {
String[] cmds = new String[] {
D:\\Dev\\wasce-server-2.1.1.1\\bin\\gsh.bat,
-c,
geronimo/wait-for-server -u system -w manager -t 10 };
Process ps = Runtime.getRuntime().exec(cmds, null,
new File(D:\\Dev\\wasce-server-2.1.1.1\\bin));
StreamGobbler errorGobbler = new
StreamGobbler(ps.getErrorStream(), ERROR);
StreamGobbler outputGobbler = new
StreamGobbler(ps.getInputStream(), OUTPUT);
errorGobbler.start();
outputGobbler.start();
// Print the exit code
int exitVal = ps.waitFor();
System.out.println(ExitValue: + exitVal);
}
}
Hope this helps. Thanks again
[BUILD] trunk: Failed for Revision: 742809
Geronimo Revision: 742809 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090209/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090209
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 27 seconds
[INFO] Finished at: Mon Feb 09 21:48:52 EST 2009
[INFO] Final Memory: 633M/954M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090209/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:41.166
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:00:59.751)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.334)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.661)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.523)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:21.598)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:24.776)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:42.508)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:47.282)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:01:10.740)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:39.767)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.901)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.814)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.954)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:52.183)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:53.650)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:03.994)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.230)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.290)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.683) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.410)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672145#action_12672145 ] Jarek Gawor commented on GERONIMO-4525: --- Yes, this was very helpful. It's weird how this works Anyway, I'll add those cmd /e exit /b calls in. Thanks for helping me to understand this! No effective exit code for all Windows commands --- Key: GERONIMO-4525 URL: https://issues.apache.org/jira/browse/GERONIMO-4525 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3 Environment: MS Windows Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525_Jack.patch There are multiple problems in the current Windows batch commands (including geronimo.bat, startup.bat, etc.) - It's not recommended to define an environment variable with the name ERRORLEVEL. See [1]. - Set a value to ERRORLEVEL has no effect to the exit code of the batch command (so the documented exit code 0 and 1 are not actually there). - The value of the ERRORLEVEL variable will also get unset when the @endlocal command is called. [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672149#action_12672149 ] Jarek Gawor commented on GERONIMO-4525: --- Added the cmd /c exit /b %errorlevel% calls to the end of all scripts and added cmd /c exit 0 to geronimo.bat (revision 742843). Thanks again! I'll work on merging these changes to branches/2.1. Let me know if I missed anything. No effective exit code for all Windows commands --- Key: GERONIMO-4525 URL: https://issues.apache.org/jira/browse/GERONIMO-4525 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3 Environment: MS Windows Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525_Jack.patch There are multiple problems in the current Windows batch commands (including geronimo.bat, startup.bat, etc.) - It's not recommended to define an environment variable with the name ERRORLEVEL. See [1]. - Set a value to ERRORLEVEL has no effect to the exit code of the batch command (so the documented exit code 0 and 1 are not actually there). - The value of the ERRORLEVEL variable will also get unset when the @endlocal command is called. [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4525) No effective exit code for all Windows commands
[ https://issues.apache.org/jira/browse/GERONIMO-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672165#action_12672165 ] Jack Cai commented on GERONIMO-4525: Looks good to me now. Thanks Jarek! No effective exit code for all Windows commands --- Key: GERONIMO-4525 URL: https://issues.apache.org/jira/browse/GERONIMO-4525 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3 Environment: MS Windows Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525_Jack.patch There are multiple problems in the current Windows batch commands (including geronimo.bat, startup.bat, etc.) - It's not recommended to define an environment variable with the name ERRORLEVEL. See [1]. - Set a value to ERRORLEVEL has no effect to the exit code of the batch command (so the documented exit code 0 and 1 are not actually there). - The value of the ERRORLEVEL variable will also get unset when the @endlocal command is called. [1] http://blogs.msdn.com/oldnewthing/archive/2008/09/26/8965755.aspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4534) Can't secure connect to JMX with JConsole.
Can't secure connect to JMX with JConsole. -- Key: GERONIMO-4534 URL: https://issues.apache.org/jira/browse/GERONIMO-4534 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: management Affects Versions: 2.1.4, 2.2 Environment: Windows XP Sun JDK 1.5 geronimo_tomcat6_2.1.4_snapshot/20090209/ Reporter: Shawn Jiang Priority: Blocker I'm trying to use jconsole to securely connect to the JMX server of geronimo 2.1.4 snapshot according to the guide here: http://cewiki.cn.ibm.com:7080/confluence/display/V21Docs/Working+with+the+secure+JMX+server * 1, Change the config.xml and start the server. * 2, use jconsole -J-Djavax.net.ssl.keyStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret start the jconsole. * 3, in the jconsole interface-advanced, input: JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector user name: system password: manager * 4, click the connect button. expected result: could connect to the JMX server. actual result: CAN NOT connect to the JMX server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4534) Can't secure connect to JMX with JConsole.
[ https://issues.apache.org/jira/browse/GERONIMO-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang updated GERONIMO-4534: -- Priority: Major (was: Blocker) update to major from blocker and some investigation result here: This defect is caused by a recent change in class JMXSecureConnector to use org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory to replace javax.rmi.ssl.SslRMIClientSocketFactory. JConsole need the client socket factory class locally to connect to the JMX server. That's why this defect happened. Two possible solutions. * 1, Put the geronimo-kernel-2.1.4-SNAPSHOT.jar to the classpath when starting the jconsole so that jconsole could find org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory. * 2, Revert the client socket factory to javax.rmi.ssl.SslRMIClientSocketFactory. Solution #1 just needs to update the document. But it has a limitation when user can't use jconsole at a machine without the geronimo-kernel-2.1.4-SNAPSHOT.jar to connect to the JMX server. Solution #2 needs review because there's no JIRA related to the client socket factory replacement in the svn commit. * path: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/framework/modules/geronimo-kernel/ * revision 727268. * log: RMI client socket factories that set socket timeouts - should prevent automatic builds from getting stuck Can't secure connect to JMX with JConsole. -- Key: GERONIMO-4534 URL: https://issues.apache.org/jira/browse/GERONIMO-4534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: management Affects Versions: 2.1.4, 2.2 Environment: Windows XP Sun JDK 1.5 geronimo_tomcat6_2.1.4_snapshot/20090209/ Reporter: Shawn Jiang I'm trying to use jconsole to securely connect to the JMX server of geronimo 2.1.4 snapshot according to the guide here: http://cewiki.cn.ibm.com:7080/confluence/display/V21Docs/Working+with+the+secure+JMX+server * 1, Change the config.xml and start the server. * 2, use jconsole -J-Djavax.net.ssl.keyStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret start the jconsole. * 3, in the jconsole interface-advanced, input: JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector user name: system password: manager * 4, click the connect button. expected result: could connect to the JMX server. actual result: CAN NOT connect to the JMX server. -- 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-4534) Can't secure connect to JMX with JConsole.
[ https://issues.apache.org/jira/browse/GERONIMO-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672183#action_12672183 ] genspring edited comment on GERONIMO-4534 at 2/9/09 11:10 PM: update to major from blocker and some investigation result here: This defect is caused by a recent change in class JMXSecureConnector to use org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory to replace javax.rmi.ssl.SslRMIClientSocketFactory. JConsole need the client socket factory class locally to connect to the JMX server. That's why this defect happened. Two possible solutions. * 1, Put the geronimo-kernel-2.1.4-SNAPSHOT.jar to the classpath when starting the jconsole so that jconsole could find org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory. * 2, Revert the client socket factory to javax.rmi.ssl.SslRMIClientSocketFactory. Solution #1 just needs to update the document. But it has a limitation that user can't use jconsole at a machine without the geronimo-kernel-2.1.4-SNAPSHOT.jar to connect to the JMX server. Solution #2 needs review because there's no JIRA related to the client socket factory replacement in the svn commit. * path: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/framework/modules/geronimo-kernel/ * revision 727268. * log: RMI client socket factories that set socket timeouts - should prevent automatic builds from getting stuck was (Author: genspring): update to major from blocker and some investigation result here: This defect is caused by a recent change in class JMXSecureConnector to use org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory to replace javax.rmi.ssl.SslRMIClientSocketFactory. JConsole need the client socket factory class locally to connect to the JMX server. That's why this defect happened. Two possible solutions. * 1, Put the geronimo-kernel-2.1.4-SNAPSHOT.jar to the classpath when starting the jconsole so that jconsole could find org.apache.geronimo.kernel.rmi.GeronimoSslRMIClientSocketFactory. * 2, Revert the client socket factory to javax.rmi.ssl.SslRMIClientSocketFactory. Solution #1 just needs to update the document. But it has a limitation when user can't use jconsole at a machine without the geronimo-kernel-2.1.4-SNAPSHOT.jar to connect to the JMX server. Solution #2 needs review because there's no JIRA related to the client socket factory replacement in the svn commit. * path: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/framework/modules/geronimo-kernel/ * revision 727268. * log: RMI client socket factories that set socket timeouts - should prevent automatic builds from getting stuck Can't secure connect to JMX with JConsole. -- Key: GERONIMO-4534 URL: https://issues.apache.org/jira/browse/GERONIMO-4534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: management Affects Versions: 2.1.4, 2.2 Environment: Windows XP Sun JDK 1.5 geronimo_tomcat6_2.1.4_snapshot/20090209/ Reporter: Shawn Jiang I'm trying to use jconsole to securely connect to the JMX server of geronimo 2.1.4 snapshot according to the guide here: http://cewiki.cn.ibm.com:7080/confluence/display/V21Docs/Working+with+the+secure+JMX+server * 1, Change the config.xml and start the server. * 2, use jconsole -J-Djavax.net.ssl.keyStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret start the jconsole. * 3, in the jconsole interface-advanced, input: JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector user name: system password: manager * 4, click the connect button. expected result: could connect to the JMX server. actual result: CAN NOT connect to the JMX server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4534) Can't secure connect to JMX with JConsole.
[ https://issues.apache.org/jira/browse/GERONIMO-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672185#action_12672185 ] Shawn Jiang commented on GERONIMO-4534: --- Solution #1: Update the document http://cewiki.cn.ibm.com:7080/confluence/display/V21Docs/Working+with+the+secure+JMX+server In the step to start jconsole change the command from jconsole -J-Djavax.net.ssl.keyStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret To jconsole -J-Djavax.net.ssl.keyStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%GERONIMO_HOME%\repository\org\apache\geronimo\framework\geronimo-kernel\2.1.4\geronimo-kernel-2.1.4.jar Can't secure connect to JMX with JConsole. -- Key: GERONIMO-4534 URL: https://issues.apache.org/jira/browse/GERONIMO-4534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: management Affects Versions: 2.1.4, 2.2 Environment: Windows XP Sun JDK 1.5 geronimo_tomcat6_2.1.4_snapshot/20090209/ Reporter: Shawn Jiang I'm trying to use jconsole to securely connect to the JMX server of geronimo 2.1.4 snapshot according to the guide here: http://cewiki.cn.ibm.com:7080/confluence/display/V21Docs/Working+with+the+secure+JMX+server * 1, Change the config.xml and start the server. * 2, use jconsole -J-Djavax.net.ssl.keyStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret start the jconsole. * 3, in the jconsole interface-advanced, input: JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector user name: system password: manager * 4, click the connect button. expected result: could connect to the JMX server. actual result: CAN NOT connect to the JMX server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
