[jira] Updated: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4251: --- Attachment: Geronimo-4251.patch Please help to review the patch. Currently, it allows the relative URLs in the class-path attribute. Thanks ! Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Attachments: Geronimo-4251.patch Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669664#action_12669664 ] David Jencks commented on GERONIMO-4251: Someone needs to look at the spec again my recollection is that relative urls are relative to the location of the module in the ear. So if your module is at the ear root relative and absolute mean the same thing but if your module is at /foo/bar/myModule.jar then ../baz/myLib.jar would be the same as /foo/baz/myLib.jar Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Attachments: Geronimo-4251.patch Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669610#action_12669610 ] Ivan commented on GERONIMO-4251: Thanks, Frank One thing I want to confirm is that whether all the entries in the class-path be relative URLs, which means /myLibs and /x/aDirectory in your example should be something like myLibs and x/aDirectory ? Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669535#action_12669535 ] Guillaume Nodet commented on GSHELL-156: Though it would not harm to have a system property to control that. We can leave the current behavior as is in gshell and switch it off in servicemix ... Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4426) Add a new Log Level portlet to the Server Logs page to allow dynamic changing of Logger levels
[ https://issues.apache.org/jira/browse/GERONIMO-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4426: --- Fix Version/s: (was: 2.2) Wish List Assignee: (was: Donald Woods) moving to wish list Add a new Log Level portlet to the Server Logs page to allow dynamic changing of Logger levels -- Key: GERONIMO-4426 URL: https://issues.apache.org/jira/browse/GERONIMO-4426 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, Logging Reporter: Donald Woods Priority: Minor Fix For: Wish List Create a new portlet that will allow users to dynamically change the Logger level for any logger class in the server. The changes will not be preserved after a server restart, as this is only geared towards helping with runtime debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669616#action_12669616 ] Frank Meilinger commented on GERONIMO-4251: --- Hi Ivan, Yes. I think the path / means the root of the ear-file. So I think you are right, the directory /myLibs should have the same meaning as the directory name myLibs becaue the current directory makes sense to be the root of the acual ear-file. example of ear-file structure: / /lib /META-INF /myLibs In this sample, an class-path entry of myLibs should be the same as /myLibs because / is the root of the ear. Greetings, Frank Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669850#action_12669850 ] Ivan commented on GERONIMO-4251: Thanks, David. From my view, Geronimo behaviors correctly, it does handle those URLs relative to the module, not the ear root directory. I will post an example that I used to test this patch, and the updated geronimo-deployment.jar file. If anyone has time, please help to reivew it. Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Attachments: Geronimo-4251.patch Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.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-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4251: --- Attachment: my-ear-1.0-SNAPSHOT.ear I combined an example of Geronimo testcase and a JPA example in the 4468. Please access the http://localhost:8080/mtom-war/. I will show whether those jars are loaded. Thanks! Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Attachments: Geronimo-4251.patch, my-ear-1.0-SNAPSHOT.ear Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.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-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4251: --- Attachment: geronimo-deployment-2.2-SNAPSHOT.jar Please replace this file in the repository\org\apache\geronimo\framework\geronimo-deployment\2.2-SNAPSHOT\geronimo-deployment-2.2-SNAPSHOT.jar. It contains the patch to allow directories in the class-path attribute. Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Attachments: Geronimo-4251.patch, geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4499) can't use PortOffset in var\config\config-substitutions.properties to start two geronimo instance at the same machine.
[
https://issues.apache.org/jira/browse/GERONIMO-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669854#action_12669854
]
Ivan commented on GERONIMO-4499:
I include a customized spring placeholder bean in Geronimo-4475.
a. the bean will read the config-substitutions.properties, so that the
PortOffSet and ActiveMQPort could be used in the borker's configuration file.
b. Make it support the placeholder like ${${ActiveMQPort} + ${PortOffset}}
Maybe we should create an injectable properties placeholder spring bean to
avoid reference the config-substitutions.xml directly in the future.
Thanks !
can't use PortOffset in var\config\config-substitutions.properties to start
two geronimo instance at the same machine.
--
Key: GERONIMO-4499
URL: https://issues.apache.org/jira/browse/GERONIMO-4499
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.2
Environment: Windows XP SP 2 + IBM SDK 1.5.0
Reporter: Shawn Jiang
Priority: Minor
I'm trying to use PortOffset in var\config\config-substitutions.properties to
start two geronimo instance at the same machine.
1, install two geronimo server serverA, serverB.
2, update the PortOffset in var\config\config-substitutions.properties from 0
to 10 for serverB.
3, start serverA.
4, start serverB.
*expected result*: Both serverA and serverB could be started without
problems.
*actual result*: serverA started, but server B failed to start with a
exception below in log:
-
2009-01-07 17:23:08,562 ERROR [BrokerService] Failed to start ActiveMQ JMS
Message Broker. Reason: java.io.IOException: Transport Connector could not be
registered in JMX: Failed to bind to server socket: tcp://localhost:61616 due
to: java.net.BindException: Address already in use: JVM_Bind
java.io.IOException: Transport Connector could not be registered in JMX:
Failed to bind to server socket: tcp://localhost:61616 due to:
java.net.BindException: Address already in use: JVM_Bind
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at
org.apache.activemq.broker.BrokerService.registerConnectorMBean(BrokerService.java:1427)
at
org.apache.activemq.broker.BrokerService.startTransportConnector(BrokerService.java:1886)
at
org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerService.java:1837)
at
org.apache.activemq.broker.BrokerService.start(BrokerService.java:473)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 740177
Geronimo Revision: 740177 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090202/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090202
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 27 seconds
[INFO] Finished at: Mon Feb 02 21:43:11 EST 2009
[INFO] Final Memory: 634M/978M
[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/20090202/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:42.745
[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:01:00.012)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.900)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.060)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.819)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:22.691)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:21.065)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:44.190)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:48.199)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:47.443)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.353)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:31.614)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.601)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.967)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:47.872)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:53.425)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:05.889)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.490)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.091)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:35.961) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.399)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Created: (GERONIMO-4524) Can't start the 2.2 server with Sun JDK 1.5, IBM JDK 1.5, or IBM JDK 6.0.
Can't start the 2.2 server with Sun JDK 1.5, IBM JDK 1.5, or IBM JDK 6.0. - Key: GERONIMO-4524 URL: https://issues.apache.org/jira/browse/GERONIMO-4524 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.2 Environment: Windows XP + IBM JDK 1.5 Windows XP + SUN JDK 1.5 Windows XP + IBM JDK 6.0 Reporter: Shawn Jiang Priority: Blocker I can only start the server successfully with SUN JDK 6.0. Or there will be exceptions thrown: * For *JDK 1.5*, the exceptions was - Could not load gbean org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car,j2eeType=GBean,name=LoginConfiguration org.apache.geronimo.gbean.InvalidConfigurationException: Could not load attribute class: javax.security.auth.login.Configuration$Parameters at org.apache.geronimo.gbean.runtime.GBeanAttribute.init(GBeanAttribute.java:199) at org.apache.geronimo.gbean.runtime.GBeanInstance.buildAttributes(GBeanInstance.java:366) at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:240) .. Caused by: java.lang.ClassNotFoundException: Could not load class javax.security.auth.login.Configuration$Parameters from classloader: org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car, destroyed state: false at org.apache.geronimo.kernel.ClassLoading.loadClass(ClassLoading.java:213) at org.apache.geronimo.gbean.runtime.GBeanAttribute.init(GBeanAttribute.java:197) ... 22 more * For *IBM JDK 6.0* , the exception was: -- ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/activemq-broker/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.2-SNAPSHOT/car,j2eeType=JMSServer,name=DefaultActiveMQBroker org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in file [C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\var\activemq\conf\activemq.xml]: Cannot create inner bean '(inner bean)' of type [org.apache.activemq.store.amq.AMQPersistenceAdapter] while setting bean property 'persistenceAdapter'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#3' defined in file [C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\var\activemq\conf\activemq.xml]: Initialization of bean failed; nested exception is java.lang.UnsatisfiedLinkError: com/ibm/jvm/ClassLoader.getClassContext()[Ljava/lang/Class; at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:230) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:122) . Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#3' defined in file [C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\var\activemq\conf\activemq.xml]: Initialization of bean failed; nested exception is java.lang.UnsatisfiedLinkError: com/ibm/jvm/ClassLoader.getClassContext()[Ljava/lang/Class; at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(AccessController.java:224) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:219) ... 53 more Caused by: java.lang.UnsatisfiedLinkError: com/ibm/jvm/ClassLoader.getClassContext()[Ljava/lang/Class; at com.ibm.jvm.ClassLoader.getLastClassLoader(ClassLoader.java:55) at java.net.URL.getURLStreamHandler(URL.java:1141) at java.net.URL.init(URL.java:572) . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669872#action_12669872 ] Shawn Jiang commented on GERONIMO-4518: --- I just verified that this is fixed in the latest 2.2 snapshot and 2.1.4 snapshot. Thank Jarek ! Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties --- Key: GERONIMO-4518 URL: https://issues.apache.org/jira/browse/GERONIMO-4518 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1.4, 2.2 Environment: Windows XP + Sun JDK 1.5 Reporter: Shawn Jiang Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: G4518_Shawn.patch 1, change the host in config-substitutions.properties to 127.0.0.1 2, start the server. 3, shutdown the server. *expected result*: the server could be shutdown. *actual result*: the sever can't be shutdown with exception: java.net.ConnectException: Connection refused: connect -- C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\binshutdown --host 127.0.0.1 Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre log4j:WARN No appenders could be found for logger (org.apache.geronimo.kernel.basic.BasicKernel). log4j:WARN Please initialize the log4j system properly. Username: system Password: *** Locating server on 127.0.0.1:1099... Could not communicate with the server. The server may not be running or the port number may be inco rrect (Connection refused to host: 6.153.277.58; nested exception is: java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4404) ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang reopened GERONIMO-4404:
---
This defect happens again with trunk code.
I found that the class patched were removed in the latest code and the unit
testing were commented out.
ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost
--
Key: GERONIMO-4404
URL: https://issues.apache.org/jira/browse/GERONIMO-4404
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 2.1.4
Attachments: G4404_branch21.patch, G4404_truck.patch
Ron Staerker reported that if you change ServerHostname in
config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
the new ServerHostname value. This seems to b caused by several pom.xml
problems, where:
config-property-setting
name=ServerUrltcp://${PlanServerHostname}:${PlanActiveMQPort}/config-property-setting
where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
attribute name=host#{ServerHostname}/attribute
is being substituted in at build time to be 0.0.0.0 instead of putting
${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4404) ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost or actual IP.
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4404:
--
Summary: ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set
to localhost or actual IP. (was: ActiveMQ connectors default to 0.0.0.0 when
ServerHostname is set to localhost)
I updated the title to
ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost
*or* actual IP.
from
ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost.
Because I found that when the ServerHostname was set to the actual IP of the
machine. The ActiveMQ will still bind to 0.0.0.0.
* ActiveMQ works only with localhost and 127.0.0.1
** 61613 0.0.0.0 ActiveMQ Transport Connector
** 61616 0.0.0.0 ActiveMQ Transport Connector
GERONIMO-4404 fixed the localhost to 0.0.0.0 problem, but the real connector \
creation code in activemq is: \
{code:title=org.apache.activemq.transport.tcp.TcpTransportServer}
InetAddress addr = InetAddress.getByName(host);
try {
if (host.trim().equals(localhost) || \
addr.equals(InetAddress.getLocalHost())) { //#1 start the socket with 0.0.0.0
this.serverSocket = \
serverSocketFactory.createServerSocket(bind.getPort(), backlog); }
else {
//#2 start the socket with the ip spcified in addr.
this.serverSocket = \
serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr); }
{code}
Since if you config the real IP as a host setting, \
addr.equals(InetAddress.getLocalHost()) will allways be true so that the #1
will be \
used to start the socket with 0.0.0.0. I'm not sure if it's a bug of activemq, \
there's nothing we can do from geronimo side for now to fix this.
ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to
localhost or actual IP.
Key: GERONIMO-4404
URL: https://issues.apache.org/jira/browse/GERONIMO-4404
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 2.1.4
Attachments: G4404_branch21.patch, G4404_truck.patch
Ron Staerker reported that if you change ServerHostname in
config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
the new ServerHostname value. This seems to b caused by several pom.xml
problems, where:
config-property-setting
name=ServerUrltcp://${PlanServerHostname}:${PlanActiveMQPort}/config-property-setting
where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
attribute name=host#{ServerHostname}/attribute
is being substituted in at build time to be 0.0.0.0 instead of putting
${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[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=12669880#action_12669880 ] Shawn Jiang commented on GERONIMO-4442: --- Except the ActiveMQ, Others host binding problems have been fixed in both 2.1.4 snapshot and 2.2 snapshot build. Since It seems that the ActiveMQ host binding problem can't be fixed in geronimo side, I reopened https://issues.apache.org/jira/browse/GERONIMO-4404 to continue to track the remaining ActiveMQ binding problem. Can you please close this one ? Thanks. 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-4404) ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to localhost or actual IP.
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669881#action_12669881
]
Shawn Jiang commented on GERONIMO-4404:
---
I've created a ActiveMQ JIRA here:
https://issues.apache.org/activemq/browse/AMQ-2094
ActiveMQ connectors default to 0.0.0.0 when ServerHostname is set to
localhost or actual IP.
Key: GERONIMO-4404
URL: https://issues.apache.org/jira/browse/GERONIMO-4404
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
Fix For: 2.1.4
Attachments: G4404_branch21.patch, G4404_truck.patch
Ron Staerker reported that if you change ServerHostname in
config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
the new ServerHostname value. This seems to b caused by several pom.xml
problems, where:
config-property-setting
name=ServerUrltcp://${PlanServerHostname}:${PlanActiveMQPort}/config-property-setting
where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
attribute name=host#{ServerHostname}/attribute
is being substituted in at build time to be 0.0.0.0 instead of putting
${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4250) Wrong path to access JAR files in EAR from WAR modules with getResourceAsStream
[ https://issues.apache.org/jira/browse/GERONIMO-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669885#action_12669885 ] Ivan commented on GERONIMO-4250: All the jars in the lib folder are visible for each modules in the ear, for they are loaded by ear classloader. I list the urls for a typical ear classloader : 0 = [file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/lib/my-entities1-1.0-SNAPSHOT.jar] 1 = [file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/lib/my-pu-1.0-SNAPSHOT.jar] 2 = [file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/mtom-ejb-2.2-SNAPSHOT.jar] 3 = [file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/] 4 = [file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/872056915/] The reason that we could not load the resource with sample.jar is that the URL file:/D:/geronimo-all/20090121/g/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/lib is not inculded in the ear. IMO, the spec you refer all JAR-Files in the EARs lib/ directory should be available in all (also WAR) Modules classloaders means that we could load the class from those jars in the lib directory, not we could access those jar files without lib prefix. About the access path, it seems that spec does not specify it explicitly. Thanks for any comment ! Wrong path to access JAR files in EAR from WAR modules with getResourceAsStream --- Key: GERONIMO-4250 URL: https://issues.apache.org/jira/browse/GERONIMO-4250 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Hi, I've tryed to build an EAR with the default lib/ bundle directory without using the manifest Class-Path entry in all WAR's which references the jar files in the lib/ directory. This EAR should be standard JEE5 compliant and should be deployable without any change in Geronimo 2.1.2 and GlassFish (latest Version). Now I found a difference in how to access the jar files located in the EARs lib/ directory from within an WAR module. In Geronimo I have to use: getClass().getClassLoader().getResourceAsStream(lib/sample.jar) to get the jar file content. In GlassFish I have to use: getClass().getClassLoader().getResourceAsStream(sample.jar) notice - without the lib/ prefix. As far as I understand the JEE5 specification (section 8.2.1 Bundled Libraries), all JAR-Files in the EARs lib/ directory should be available in all (also WAR) Modules classloaders. So the lib/ prefix should not be specified. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4525) No effective exit code for all Windows commands
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 Fix For: 2.1.4, 2.2 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] Updated: (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:all-tabpanel ] Jack Cai updated GERONIMO-4525: --- Attachment: Geronimo-4525.patch This patch uses the real errorlevel to check error conditions. It also ensures all commands exit with a meaningful code: 0 means success, and non-zero means failure. 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 Fix For: 2.1.4, 2.2 Attachments: Geronimo-4525.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.
