[jira] Updated: (GERONIMO-4462) Allow JAVA_HOME to point to a JRE in Windows OS
[ https://issues.apache.org/jira/browse/GERONIMO-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4462: --- Attachment: GERONIMO-4462_Jack.patch Providing a fix. Tested in Windows XP. > Allow JAVA_HOME to point to a JRE in Windows OS > --- > > Key: GERONIMO-4462 > URL: https://issues.apache.org/jira/browse/GERONIMO-4462 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: commands >Affects Versions: 2.1.3, 2.2 > Environment: Windows OS >Reporter: Jack Cai >Priority: Minor > Attachments: GERONIMO-4462_Jack.patch > > > Currently the setjavaenv.bat script will set JRE_HOME=JAVA_HOME if JRE_HOME > is not set. This requires JAVA_HOME to point to a JDK installation. Otherwise > the geronimo.bat script will fail to launch because JAVA_HOME\jre is not a > valid dir. This is an unnecessary requirement. We should allow user to point > JAVA_HOME to a JRE installation, as what we do in Linux script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4462) Allow JAVA_HOME to point to a JRE in Windows OS
Allow JAVA_HOME to point to a JRE in Windows OS --- Key: GERONIMO-4462 URL: https://issues.apache.org/jira/browse/GERONIMO-4462 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.3, 2.2 Environment: Windows OS Reporter: Jack Cai Priority: Minor Currently the setjavaenv.bat script will set JRE_HOME=JAVA_HOME if JRE_HOME is not set. This requires JAVA_HOME to point to a JDK installation. Otherwise the geronimo.bat script will fail to launch because JAVA_HOME\jre is not a valid dir. This is an unnecessary requirement. We should allow user to point JAVA_HOME to a JRE installation, as what we do in Linux script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4457) Add testcases about dynamic webservice interface Provider
[ https://issues.apache.org/jira/browse/GERONIMO-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4457: --- Attachment: Geronimo-4457.patch I made some changes about the Provider testing. If Geronimo-4459 is fixed, all the cases would pass on tomcat + axis2 For CXF, those httpbinding cases still failed, I have comment out them. Please help to review the testcase, and thanks for any comment ! > Add testcases about dynamic webservice interface Provider > - > > Key: GERONIMO-4457 > URL: https://issues.apache.org/jira/browse/GERONIMO-4457 > Project: Geronimo > Issue Type: Test > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan >Priority: Minor > Attachments: Geronimo-4457.patch > > > Provider interface is an important part for web service, especially for > Restful web service. Currently, no related testcases exist in our testsuite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.0: Failed for Revision: 725593
Geronimo Revision: 725593 built with tests included See the full build-0200.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081211/build-0200.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081211/unit-test-reports mvn install:install-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:0.8.1 -- 2 required artifacts are missing. for artifact: org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), openqa (http://maven.openqa.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.openqa.selenium.server:selenium-server:jar:0.8.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.server:selenium-server:jar:0.8.1 2) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:0.8.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:0.8.1 -- 2 required artifacts are missing. for artifact: org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT from the s
[BUILD] trunk: Failed for Revision: 725542
Geronimo Revision: 725542 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/build-2100.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 34 minutes 56 seconds [INFO] Finished at: Wed Dec 10 21:39:35 EST 2008 [INFO] Final Memory: 633M/1014M [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/20081210/logs-2100-tomcat/test.log [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] [INFO] snapshot org.codehaus.mojo:selenium-maven-plugin:1.0-rc-1-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/selenium-maven-plugin/1.0-rc-1-SNAPSHOT/selenium-maven-plugin-1.0-rc-1-SNAPSHOT.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/selenium-maven-plugin/1.0-rc-1-SNAPSHOT/selenium-maven-plugin-1.0-rc-1-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/logs-2100-jetty/test.log [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/selenium-maven-plugin/1.0-rc-1-SNAPSHOT/selenium-maven-plugin-1.0-rc-1-SNAPSHOT.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/selenium-maven-plugin/1.0-rc-1-SNAPSHOT/selenium-maven-plugin-1.0-rc-1-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR Samples: trunk = Log: http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/samples-2100.log Build status: OK
[BUILD] branches/2.0: Failed for Revision: 725498
Geronimo Revision: 725498 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081210/build-2000.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081210/unit-test-reports mvn install:install-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.server:selenium-server:jar:0.8.1 -- 2 required artifacts are missing. for artifact: org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), openqa (http://maven.openqa.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:0.8.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.client-drivers -DartifactId=selenium-java-client-driver \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.client-drivers:selenium-java-client-driver:jar:0.8.1 2) org.openqa.selenium.server:selenium-server:jar:0.8.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.openqa.selenium.server -DartifactId=selenium-server \ -Dversion=0.8.1 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT 2) org.openqa.selenium.server:selenium-server:jar:0.8.1 -- 2 required artifacts are missing. for artifact: org.apache.geronimo.testsupport:testsupport-selenium:jar:2.0.3-SNAPSHOT from the specified remote repositories: central (http://repo1
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655408#action_12655408 ] jfassad edited comment on GERONIMODEVTOOLS-537 at 12/10/08 3:14 PM: --- Im having the same "javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table" problem And it doesnt happen only with the GEP , for me it happens with the geronimo bin/deploy.sh tool too. ./deploy.sh -host 192.168.200.3 deploy ~/Desktop/RemoteDeployTest.ear Using GERONIMO_BASE: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_HOME: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/local/jdk1.6.0_10 Username: system Password: *** Error: Unable to connect to server at deployer:geronimo:jmx://192.168.200.3 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:199) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:95) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2312) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:182) ... 8 more Im attaching the EAR Geronimo 2.1.3 mini both on local and remote machine jdk1.6.0_10 was (Author: jfassad): Im having the same "javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table" problem And it doesnt happen only with the GEP , for me it happens with the geronimo bin/deploy.sh tool too. ./deploy.sh -host 192.168.200.3 deploy ~/Desktop/RemoteDeployTest.ear Using GERONIMO_BASE: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_HOME: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/local/jdk1.6.0_10 Username: system Password: *** Error: Unable to connect to server at deployer:geronimo:jmx://192.168.200.3 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:199) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:95) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCa
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655408#action_12655408 ] jfassad edited comment on GERONIMODEVTOOLS-537 at 12/10/08 3:13 PM: --- Im having the same "javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table" problem And it doesnt happen only with the GEP , for me it happens with the geronimo bin/deploy.sh tool too. ./deploy.sh -host 192.168.200.3 deploy ~/Desktop/RemoteDeployTest.ear Using GERONIMO_BASE: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_HOME: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/local/jdk1.6.0_10 Username: system Password: *** Error: Unable to connect to server at deployer:geronimo:jmx://192.168.200.3 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:199) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:95) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2312) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:182) ... 8 more Im attaching the EAR Geronimo 2.1.3 jdk1.6.0_10 was (Author: jfassad): Im having the same "javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table" problem And it doesnt happen only with the GEP , for me it happens with the geronimo bin/deploy.sh tool too. ./deploy.sh -host 192.168.200.3 deploy ~/Desktop/RemoteDeployTest.ear Using GERONIMO_BASE: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_HOME: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/local/jdk1.6.0_10 Username: system Password: *** Error: Unable to connect to server at deployer:geronimo:jmx://192.168.200.3 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:199) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:95) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:2
[jira] Updated: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] João Assad updated GERONIMODEVTOOLS-537: Attachment: RemoteDeployTestEA.ear > Remote server deployment fails with connection exception > > > Key: GERONIMODEVTOOLS-537 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Tim McConnell > Attachments: RemoteDeployTestEA.ear > > > Distribution of module failed. See log for details. > Connection refused: connect > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at sun.net.NetworkClient.doConnect(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.connectToServer(FileUploadServletClient.java:266) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.uploadFilesToServer(FileUploadServletClient.java:115) > at > org.apache.geronimo.deployment.plugin.remote.RemoteDeployUtil.uploadFilesToServer(RemoteDeployUtil.java:33) > at > org.apache.geronimo.deployment.plugin.remote.DistributeCommand.massageFileNames(DistributeCommand.java:43) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) > at > org.apache.geronimo.deployment.plugin.remote.DistributeCommand.run(DistributeCommand.java:50) > at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655408#action_12655408 ] João Assad commented on GERONIMODEVTOOLS-537: - Im having the same "javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table" problem And it doesnt happen only with the GEP , for me it happens with the geronimo bin/deploy.sh tool too. ./deploy.sh -host 192.168.200.3 deploy ~/Desktop/RemoteDeployTest.ear Using GERONIMO_BASE: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_HOME: /usr/local/octopoker/geronimo-tomcat6-minimal-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/local/jdk1.6.0_10 Username: system Password: *** Error: Unable to connect to server at deployer:geronimo:jmx://192.168.200.3 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:199) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:95) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) 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) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2312) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:182) ... 8 more Im attaching the EAR > Remote server deployment fails with connection exception > > > Key: GERONIMODEVTOOLS-537 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Tim McConnell > > Distribution of module failed. See log for details. > Connection refused: connect > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at sun.net.NetworkClient.doConnect(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.connectToServer(FileUploadServletClient.java:266) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.uploadFilesToServer(FileUploadServletClient.java:115) > at > org.apache.geronimo.deployment.plugin.remote.RemoteDeployUtil.uploadFilesToServer(RemoteDeployUtil.java:33) > at > org.apache.geronimo.deployment.plugin.remote.DistributeCommand.massageFileNames(DistributeCommand.java:43) >
[jira] Commented: (GERONIMO-4461) Improve exception during transaction manager one phase commit
[ https://issues.apache.org/jira/browse/GERONIMO-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655402#action_12655402 ] David Jencks commented on GERONIMO-4461: We might seek more guidance from experts on this, but I would think that we don't want to automatically forget anything associated with a tx that is completed heuristically. That means that something went very seriously wrong and IMO we shouldn't erase any info that bears on it -- hopefully someone will be along soon to try to figure out what happened. For XAException.XA_HEURCOM, doesn't that mean that the tm could not figure out if some of the resource managers committed, but committed all the ones it could? If so, the state of at least one resource manager is unknown so we should definitely inform the tx originator. As far as your proposed tx mapping, it looks good to me. Also I don't think there are any cases right now where we would get a heuristic exception here that would mean the single resource is a remote tm, something that we don't support directly ourselves at the moment. > Improve exception during transaction manager one phase commit > - > > Key: GERONIMO-4461 > URL: https://issues.apache.org/jira/browse/GERONIMO-4461 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.2 > > > Currently, during transaction manager one phase commit, if there is > XAException arise from XAResource.commit, the code just throws > RollbackException. > We should provide a more detailed Exceptions, that is: > 1. If the XAException is XAException.XA_HEURRB, we throw > HeuristicRollbackException, and call XAResource to forget > 2. If the XAException is XAException.XA_HEURMIX, we throw > HeuristicMixedException, and call XAResource to forget > 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the > transaction originator, but we want to call XAResource to forget. > 4. Other XAException, throw RollbackException, same as the current code. > Thoughts? > Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4461) Improve exception during transaction manager one phase commit
Improve exception during transaction manager one phase commit - Key: GERONIMO-4461 URL: https://issues.apache.org/jira/browse/GERONIMO-4461 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.2 Currently, during transaction manager one phase commit, if there is XAException arise from XAResource.commit, the code just throws RollbackException. We should provide a more detailed Exceptions, that is: 1. If the XAException is XAException.XA_HEURRB, we throw HeuristicRollbackException, and call XAResource to forget 2. If the XAException is XAException.XA_HEURMIX, we throw HeuristicMixedException, and call XAResource to forget 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the transaction originator, but we want to call XAResource to forget. 4. Other XAException, throw RollbackException, same as the current code. Thoughts? Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4449) Transaction.rollback method also calls beforeCompletion
[
https://issues.apache.org/jira/browse/GERONIMO-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun resolved GERONIMO-4449.
---
Resolution: Fixed
see subversion commit tab. fixes in 2.1.2 and 2.2 (txmanager)
> Transaction.rollback method also calls beforeCompletion
> ---
>
> Key: GERONIMO-4449
> URL: https://issues.apache.org/jira/browse/GERONIMO-4449
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2
>Reporter: Lin Sun
>Assignee: Lin Sun
>
> Per JTA 1.1 spec, page 33:
> The beforeCompletion method is called by the transaction manager prior to the
> start of the two-phase
> transaction commit process.This call is executed with the transaction context
> of the transaction that is being
> committed. An unchecked exception thrown by a registered Synchronization
> object causes the transaction to
> be aborted. That is, upon encountering an unchecked exception thrown by a
> registered synchronization
> object, the transaction manager must mark the transaction for rollback.
> The spec seems to indicate that beforeCompletion is not called during
> rollback, but afterCompletion is called during(or after) both rollback and
> commit.
> So I expect the following to pass:
> {code}
> public void testNormalSynchIsNotCalledOnRollback() throws Exception {
> normalSync = new CountingSync();
> tm.begin();
> tm.getTransaction().registerSynchronization(normalSync);
> tm.rollback();
> assertFalse(normalSync.beforeCompletionCalled());
> assertTrue(normalSync.afterCompletionCalled());
> }
> {code}
> In geronimo, we call beforeCompletion inside of the rollback method in
> TransactionImpl.java, which seems incorrect to me.
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4448) TransactionManager resume method should only resume valid transaction
[
https://issues.apache.org/jira/browse/GERONIMO-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun resolved GERONIMO-4448.
---
Resolution: Fixed
Fixed in txmanager 2.1.2 + 2.2. (see subversion commit). Added 4 resume test
to document suggested test cases from this JIRA and all tests pass now.
> TransactionManager resume method should only resume valid transaction
> -
>
> Key: GERONIMO-4448
> URL: https://issues.apache.org/jira/browse/GERONIMO-4448
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2
>Reporter: Lin Sun
>Assignee: Lin Sun
> Fix For: 2.2
>
>
> Currently, the resume manager resumes pretty much any transaction as long as
> the transaction is not null and is an instance of TransactionImpl.
> I think this is incorrect. Per the jTA 1.1 spec, page 13:
> Suspending and Resuming a Transaction
> A call to theTransactionManager.suspend method temporarily suspends the
> transaction that is currently associated with the calling thread. If the
> thread is not
> associated with any transaction, anull object reference is returned;
> otherwise, a valid
> Transaction object is returned. TheTransactionobject can later be passed to
> the
> resume method to reinstate the transaction context association with the
> calling thread.
> TheTransactionManager.resumemethod re-associates the specified transaction
> context with the calling thread. If the transaction specified is a valid
> transaction, the
> transaction context is associated with the calling thread; otherwise, the
> thread is
> associated with no transaction.
> Transaction tobj = TransactionManager.suspend();
> ..
> TransactionManager.resume(tobj);
> A simple test below would reveal the prob:
> {code}
> public void testResume1() throws Exception {
> Transaction tx;
> assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
> tm.begin();
> assertEquals(Status.STATUS_ACTIVE, tm.getStatus());
> tx = tm.getTransaction();
> assertNotNull(tx);
> assertEquals(Status.STATUS_ACTIVE, tx.getStatus());
>
> tm.commit();
> assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
> assertNull(tm.getTransaction());
>
> try {
> tm.resume(tx);
> fail();
> } catch (InvalidTransactionException e) {
> // expected
> }
> }
> {code}
--
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: 725409
Geronimo Revision: 725409 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/build-1500.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/unit-test-reports [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )
[jira] Commented: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655326#action_12655326 ] Tim McConnell commented on GERONIMODEVTOOLS-537: Hi Antoine, what versions of the Geronimo server are you using on both the remote and local machines ?? Also, can you provide me with the artifact that you're trying to deploy so that I can see if I can duplicate the problem ?? > Remote server deployment fails with connection exception > > > Key: GERONIMODEVTOOLS-537 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Tim McConnell > > Distribution of module failed. See log for details. > Connection refused: connect > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at sun.net.NetworkClient.doConnect(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.connectToServer(FileUploadServletClient.java:266) > at > org.apache.geronimo.deployment.plugin.remote.FileUploadServletClient.uploadFilesToServer(FileUploadServletClient.java:115) > at > org.apache.geronimo.deployment.plugin.remote.RemoteDeployUtil.uploadFilesToServer(RemoteDeployUtil.java:33) > at > org.apache.geronimo.deployment.plugin.remote.DistributeCommand.massageFileNames(DistributeCommand.java:43) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) > at > org.apache.geronimo.deployment.plugin.remote.DistributeCommand.run(DistributeCommand.java:50) > at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4458) Another ClassLoader deadlock during server startup
[
https://issues.apache.org/jira/browse/GERONIMO-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655293#action_12655293
]
Kevan Miller commented on GERONIMO-4458:
So, looks like to me that our use of AspectJ is introducing cycles in
ClassLoading -- creating the potential for this type of deadlock...
Will need to try and workout what ClassLoaders the AspectJ weaving is going to
invoke. Don't know how we're going to fix, yet.
> Another ClassLoader deadlock during server startup
> --
>
> Key: GERONIMO-4458
> URL: https://issues.apache.org/jira/browse/GERONIMO-4458
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.2
>Reporter: Kevan Miller
>Priority: Critical
> Fix For: 2.2
>
>
> G 2.2 TCK testing is running into a ClassLoader deadlock. Here are the
> stacktraces:
> {noformat}
> Found one Java-level deadlock:
> =
> "RMI TCP Connection(4)-9.42.75.229":
> waiting to lock monitor 0x0849be70 (object 0xd57192c8, a
> org.apache.geronimo.kernel.config.MultiParentClassLoader),
> which is held by "main"
> "main":
> waiting to lock monitor 0x0849bed4 (object 0xd50ca400, a
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader),
> which is held by "RMI TCP Connection(4)-9.42.75.229"
> Java stack information for the threads listed above:
> ===
> "RMI TCP Connection(4)-9.42.75.229":
>at
> org.aspectj.weaver.tools.WeavingAdaptor$WeavingAdaptorMessageHolder.(WeavingAdaptor.java:498)
>at
> org.aspectj.weaver.tools.WeavingAdaptor.createMessageHandler(WeavingAdaptor.java:179)
>at
> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:111)
>at
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
>at
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
>at
> org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
>at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
>- locked <0xd4f23b40> (a
> org.apache.geronimo.kernel.config.MultiParentClassLoader)
>at
> org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
>at
> org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:43)
>at
> sun.instrument.TransformerManager.transform(TransformerManager.java:169)
>at
> sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
>at java.lang.ClassLoader.defineClass1(Native Method)
>at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
>at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:455)
>- locked <0xd4f23b40> (a
> org.apache.geronimo.kernel.config.MultiParentClassLoader)
>at
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
>- locked <0xd4ea35c8> (a
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
>at
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
>at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
>- locked <0xd50ca440> (a
> org.apache.geronimo.kernel.config.MultiParentClassLoader)
>at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:441)
>- locked <0xd50ca440> (a
> org.apache.geronimo.kernel.config.MultiParentClassLoader)
>at
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
>- locked <0xd50ca400> (a
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
>at
> org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
>at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
>-
[jira] Closed: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-4460. -- Resolution: Fixed > Upgrade Spring plugin to 2.5.6 artifacts > > > Key: GERONIMO-4460 > URL: https://issues.apache.org/jira/browse/GERONIMO-4460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ, console, dependencies >Affects Versions: 2.2 >Reporter: Donald Woods >Assignee: Donald Woods >Priority: Minor > Fix For: 2.2 > > > ActiveMQ was using springframework 2.5.5 at build time, so upgrading > plugins/spring to 2.5.6 allows us to use the same level for pluto and > activemq. > This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655287#action_12655287 ] Donald Woods commented on GERONIMO-4460: Dan, thanks for the info. > Upgrade Spring plugin to 2.5.6 artifacts > > > Key: GERONIMO-4460 > URL: https://issues.apache.org/jira/browse/GERONIMO-4460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ, console, dependencies >Affects Versions: 2.2 >Reporter: Donald Woods >Assignee: Donald Woods >Priority: Minor > Fix For: 2.2 > > > ActiveMQ was using springframework 2.5.5 at build time, so upgrading > plugins/spring to 2.5.6 allows us to use the same level for pluto and > activemq. > This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655279#action_12655279 ] Daniel Kulp commented on GERONIMO-4460: --- CXF can use 2.5.x as well. We have a profile that tests CXF with 2.5.5. Also, the FUSE version of CXF (from Progress) does ship with 2.5.5 and is built/tested with it. > Upgrade Spring plugin to 2.5.6 artifacts > > > Key: GERONIMO-4460 > URL: https://issues.apache.org/jira/browse/GERONIMO-4460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ, console, dependencies >Affects Versions: 2.2 >Reporter: Donald Woods >Assignee: Donald Woods >Priority: Minor > Fix For: 2.2 > > > ActiveMQ was using springframework 2.5.5 at build time, so upgrading > plugins/spring to 2.5.6 allows us to use the same level for pluto and > activemq. > This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655271#action_12655271 ] Donald Woods commented on GERONIMO-4460: The testsuite passed using the Jetty assembly. Haven't verified Tomcat yet... Know of any reasons why CXF needs the old 2.0.x level of Spring? > Upgrade Spring plugin to 2.5.6 artifacts > > > Key: GERONIMO-4460 > URL: https://issues.apache.org/jira/browse/GERONIMO-4460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ, console, dependencies >Affects Versions: 2.2 >Reporter: Donald Woods >Assignee: Donald Woods >Priority: Minor > Fix For: 2.2 > > > ActiveMQ was using springframework 2.5.5 at build time, so upgrading > plugins/spring to 2.5.6 allows us to use the same level for pluto and > activemq. > This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655260#action_12655260 ] Jarek Gawor commented on GERONIMO-4460: --- This needs to be done carefully since both the admin console and CXF relies on Spring - an older version of Spring. The commons-logging issue is really independent of Spring version. Just need to find the right place to exclude it. > Upgrade Spring plugin to 2.5.6 artifacts > > > Key: GERONIMO-4460 > URL: https://issues.apache.org/jira/browse/GERONIMO-4460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ, console, dependencies >Affects Versions: 2.2 >Reporter: Donald Woods >Assignee: Donald Woods >Priority: Minor > Fix For: 2.2 > > > ActiveMQ was using springframework 2.5.5 at build time, so upgrading > plugins/spring to 2.5.6 allows us to use the same level for pluto and > activemq. > This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4459) Provider does not work correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4459: --- Attachment: Geronimo-4459.patch While in the newest Axis2 snapshot, Provider is supported. a. For Geronimo, we need the update the geronima-axis2.xml file for server side configuration, add the message builder for DataSource block. b. But for client side, it seems that the client side configuration file located in modules\kernel\src\org\apache\axis2\deployment\axis2-default.xml file should also add the message builder for DataSource block. Please help to review it, thank ! > Provider does not work correctly > - > > Key: GERONIMO-4459 > URL: https://issues.apache.org/jira/browse/GERONIMO-4459 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan > Attachments: Geronimo-4459.patch > > > The Provider interface with DataSource does not work correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
Upgrade Spring plugin to 2.5.6 artifacts Key: GERONIMO-4460 URL: https://issues.apache.org/jira/browse/GERONIMO-4460 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: ActiveMQ, console, dependencies Affects Versions: 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.2 ActiveMQ was using springframework 2.5.5 at build time, so upgrading plugins/spring to 2.5.6 allows us to use the same level for pluto and activemq. This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4459) Provider does not work correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4459: --- Component/s: webservices > Provider does not work correctly > - > > Key: GERONIMO-4459 > URL: https://issues.apache.org/jira/browse/GERONIMO-4459 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan > > The Provider interface with DataSource does not work correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4459) Provider does not work correctly
Provider does not work correctly - Key: GERONIMO-4459 URL: https://issues.apache.org/jira/browse/GERONIMO-4459 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Ivan The Provider interface with DataSource does not work correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4457) Add testcases about dynamic webservice interface Provider
[ https://issues.apache.org/jira/browse/GERONIMO-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655254#action_12655254 ] Ivan commented on GERONIMO-4457: Jarek, just find the reason why the Provider DataSource failed on the tomcat + axis2. I will create another JIRA for it, so I temporary removed the testcases. > Add testcases about dynamic webservice interface Provider > - > > Key: GERONIMO-4457 > URL: https://issues.apache.org/jira/browse/GERONIMO-4457 > Project: Geronimo > Issue Type: Test > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan >Priority: Minor > > Provider interface is an important part for web service, especially for > Restful web service. Currently, no related testcases exist in our testsuite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-4457) Add testcases about dynamic webservice interface Provider
Jarek, just find the reason why the Provider DataSource failed on the tomcat + axis2.I will create another JIRA for it, so I temporary removed the testcases. 2008/12/10 Jarek Gawor (JIRA) <[EMAIL PROTECTED]> > >[ > https://issues.apache.org/jira/browse/GERONIMO-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655253#action_12655253] > > Jarek Gawor commented on GERONIMO-4457: > --- > > What happened to the patch? Was something wrong with it? > > > > Add testcases about dynamic webservice interface Provider > > - > > > > Key: GERONIMO-4457 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4457 > > Project: Geronimo > > Issue Type: Test > > Security Level: public(Regular issues) > > Components: webservices > >Reporter: Ivan > >Priority: Minor > > > > Provider interface is an important part for web service, especially for > Restful web service. Currently, no related testcases exist in our testsuite. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Ivan
[jira] Commented: (GERONIMO-4457) Add testcases about dynamic webservice interface Provider
[ https://issues.apache.org/jira/browse/GERONIMO-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655253#action_12655253 ] Jarek Gawor commented on GERONIMO-4457: --- What happened to the patch? Was something wrong with it? > Add testcases about dynamic webservice interface Provider > - > > Key: GERONIMO-4457 > URL: https://issues.apache.org/jira/browse/GERONIMO-4457 > Project: Geronimo > Issue Type: Test > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan >Priority: Minor > > Provider interface is an important part for web service, especially for > Restful web service. Currently, no related testcases exist in our testsuite. -- 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: 725027
Geronimo Revision: 725027 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/build-0300.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081210/unit-test-reports
[INFO] Compiling 4 source files to
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-transaction/target/classes
[INFO] [resources:testResources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-transaction/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-transaction/target/surefire-reports
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-transaction/target/geronimo-transaction-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: geronimo-transaction-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-transaction/target/geronimo-transaction-2.2-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-transaction/2.2-SNAPSHOT/geronimo-transaction-2.2-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo Plugins, Connector :: Core
[INFO]task-segment: [install]
[INFO]
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/geronimo/components/geronimo-connector/2.1.1/geronimo-connector-2.1.1.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/geronimo/components/geronimo-connector/2.1.1/geronimo-connector-2.1.1.jar
96K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/geronimo/components/geronimo-connector/2.1.1/geronimo-connector-2.1.1-tests.jar
83K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 25 source files to
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/target/classes
[INFO] [resources:testResources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.connector.outbound.security.GBeanTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.14 sec
Running
org.apache.geronimo.connector.outbound.GenericConnectionManagerGBeanSerializationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.401 sec
Running org.apache.geronimo.connector.AdminObjectWrapperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec
Running
org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrapperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec
Results :
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/target/geronimo-connector-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: geronimo-connector-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/connector/geronimo-connector/target/geronimo-connector-2.2
[BUILD] branches/2.0: Failed for Revision: 725005
Geronimo Revision: 725005 built with tests included
See the full build-0200.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.0/20081210/build-0200.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/2.0/20081210/unit-test-reports
424b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/doxia/doxia/1.0-alpha-7/doxia-1.0-alpha-7.pom
3K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-profile/2.0.5/maven-profile-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-artifact/2.0.5/maven-artifact-2.0.5.pom
727b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-repository-metadata/2.0.5/maven-repository-metadata-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-error-diagnostics/2.0.5/maven-error-diagnostics-2.0.5.pom
854b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-project/2.0.5/maven-project-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-artifact-manager/2.0.5/maven-artifact-manager-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-plugin-registry/2.0.5/maven-plugin-registry-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.pom
2K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-plugin-api/2.0.5/maven-plugin-api-2.0.5.pom
605b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/wagon/wagon-ssh-external/1.0-beta-2/wagon-ssh-external-1.0-beta-2.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-plugin-descriptor/2.0.5/maven-plugin-descriptor-2.0.5.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-monitor/2.0.5/maven-monitor-2.0.5.pom
404b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/classworlds/classworlds/1.1/classworlds-1.1.pom
3K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-lang/commons-lang/2.3/commons-lang-2.3.pom
10K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/maven-enforcer-rule-api/1.0-alpha-1/maven-enforcer-rule-api-1.0-alpha-1.pom
3K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/maven-shared-components/7/maven-shared-components-7.pom
2K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
239K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/maven-enforcer-rule-api/1.0-alpha-1/maven-enforcer-rule-api-1.0-alpha-1.jar
9K downloaded
[INFO] [enforcer:enforce {execution: default}]
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/mojo/plugin-support/1.0-alpha-1/plugin-support-1.0-alpha-1.pom
4K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/mojo/mojo/13/mojo-13.pom
8K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.pom
643b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven/2.0.4/maven-2.0.4.pom
11K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/ant/ant/1.6.5/ant-1.6.5.pom
764b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom
5K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-jexl/commons-jexl/1.1/commons-jexl-1.1.pom
4K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.pom
866b downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-project/2.0.4/maven-project-2.0.4.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-settings/2.0.4/maven-settings-2.0.4.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-model/2.0.4/maven-model-2.0.4.pom
2K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-profile/2.0.4/maven-profile-2.0.4.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-artifact-manager/2.0.4/maven-artifact-manager-2.0.4.pom
1K downloaded
Downloading:
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.pom
1K
[jira] Created: (GERONIMO-4458) Another ClassLoader deadlock during server startup
Another ClassLoader deadlock during server startup
--
Key: GERONIMO-4458
URL: https://issues.apache.org/jira/browse/GERONIMO-4458
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Reporter: Kevan Miller
Priority: Critical
Fix For: 2.2
G 2.2 TCK testing is running into a ClassLoader deadlock. Here are the
stacktraces:
{noformat}
Found one Java-level deadlock:
=
"RMI TCP Connection(4)-9.42.75.229":
waiting to lock monitor 0x0849be70 (object 0xd57192c8, a
org.apache.geronimo.kernel.config.MultiParentClassLoader),
which is held by "main"
"main":
waiting to lock monitor 0x0849bed4 (object 0xd50ca400, a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader),
which is held by "RMI TCP Connection(4)-9.42.75.229"
Java stack information for the threads listed above:
===
"RMI TCP Connection(4)-9.42.75.229":
at
org.aspectj.weaver.tools.WeavingAdaptor$WeavingAdaptorMessageHolder.(WeavingAdaptor.java:498)
at
org.aspectj.weaver.tools.WeavingAdaptor.createMessageHandler(WeavingAdaptor.java:179)
at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:111)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
at org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
- locked <0xd4f23b40> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
at
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:43)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:455)
- locked <0xd4f23b40> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
- locked <0xd4ea35c8> (a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
- locked <0xd50ca440> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:441)
- locked <0xd50ca440> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
- locked <0xd50ca400> (a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
- locked <0xd51f63e8> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:392)
- locked <0xd51f63e8> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:255)
- locked <0xd51f63e8> (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
- locked <0xd51f63e8> (a
org.apache.geronimo.kernel.con
[jira] Commented: (GERONIMODEVTOOLS-537) Remote server deployment fails with connection exception
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655237#action_12655237 ] Antoine commented on GERONIMODEVTOOLS-537: -- Hi, As said Tim, I am still experiencing problems. I run Ubuntu 8.10, JDK 1.5 from Sun, Eclipse Ganymede for JEE developpers on a clean installation. Following the 4 steps described by Tim above, I have the following error : "Connection to the deployment manager failed". I happens when the plugin try to synchronize with the remote server. Everything is working fine on localhost. The associated exception is the following one: javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:190) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:140) at org.apache.geronimo.st.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectionFactory.java:64) at org.apache.geronimo.st.core.commands.DeploymentCommandFactory.getDeploymentManager(DeploymentCommandFactory.java:106) at org.apache.geronimo.st.core.DeploymentUtils.getLastKnownConfigurationId(DeploymentUtils.java:208) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.doNoChange(GeronimoServerBehaviourDelegate.java:507) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.invokeCommand(GeronimoServerBehaviourDelegate.java:404) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModule(GeronimoServerBehaviourDelegate.java:284) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:944) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModules(GeronimoServerBehaviourDelegate.java:250) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:868) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:707) at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2404) at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:261) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2312) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:182) ... 14 more So I guess this is a different problem from the one originally reported. Do you have any idea what I can do to solve it ? > Remote server deployment fails with connection exception > > > Key: GERONIMODEVTOOLS-537 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-537 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Tim McConnell > > Distribution of module failed. See log for details. > Connection refused: connect > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at sun.net.NetworkClient.doConnect(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.http.HttpClient.New(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unkn
Re: Naming conventions for our adapter code and plugins for external projects
I agree that we could use artifact alias to solve some of the problems, but how do we track/manage which artifact aliases are required? Wouldn't this be a time consuming and error prone task, given we'd have to add entries in every new release for all prior releases, like: Geronimo 2.2 - From: org.apache.geronimo.modules.geronimo-activemq-ra/2.0/car org.apache.geronimo.modules.geronimo-activemq-ra/2.0.1/car org.apache.geronimo.modules.geronimo-activemq-ra/2.0.2/car org.apache.geronimo.modules.geronimo-activemq-ra/2.1/car org.apache.geronimo.modules.geronimo-activemq-ra/2.1.1/car org.apache.geronimo.modules.geronimo-activemq-ra/2.1.2/car org.apache.geronimo.modules.geronimo-activemq-ra/2.1.3/car To: org.apache.geronimo.modules.geronimo-activemq5-ra//car But, as soon as we release 2.1.4, we'd have to update the 2.2.x branch with another mapping for - From: org.apache.geronimo.modules.geronimo-activemq-ra/2.1.4/car Would we say applications are only guaranteed to be deployable within a given major release (2.x) but not on a future major release (like 3.0)? -Donald Joe Bohn wrote: Donald Woods wrote: I guess the ral problem, is that we have two competing goals: 1) Custom Server Assemblies via car-maven-plugin - To provide multiple levels of modules/plugins to allow users to choose the level of components hey need, like Jetty6 vs. Jetty7. This is sort of what ServiceMix allows, by starting with the SMX4 Kernel and adding which features or individual OSGi plugins you want. It would be a great goal to finally implement in Geronimo 3.0, so users could choose between JEE5 and JEE6 components. 2) Preserving application compatibility on newer servers - If a user has an app working on Geronimo 2.0.x or 2.1.x, then we shouldn't require them to modify the app (source or plans) for it to work on future releases. Scenario #2 is the one I'm trying to preserve, as users expect this of us. I agree with both goals and particularly this second goal. Can't we just use the artifact alias as a way to manage the compatibility issues until we have a better solution? Including the major version in the name as David recommends and adding an artifact alias entry when the new component should be compatible with the old seems to achieve both goals. We would not include the alias entry in the event that the newer component is incompatible with the older one. The deploy failure a user would see if they failed to update their deployment plan would perhaps be a good way to alter them to the fact that some changes are necessary if they had not yet prepared for them. Joe -Donald David Jencks wrote: Both Donald and I seem to feel the answer to this is obvious but we have diametrically opposed points of view so maybe its time for discussion. After endless discussion we answered a related question for our specs with the following principal: The artifactId will contain the version number of the spec The version will only contain the geronimo version. I'm happy with this decision for specs. We include a lot of other projects in geronimo, such as activemq, axis, cxf, jetty, tomcat, etc etc. These projects evolve over the years and when they get to a fairly incompatible change level they generally change the major version number, such as jetty 6 to jetty 7, activemq 4 to activemq 5, etc etc. 1. Do we want to give our users a clue about which version of the external project they are using? If so, it has to be in the maven id for our plugin that, through dependencies, installs the external project. 2. If so, how? We get groupId, artifactId, version. I don't see a plausible way to use the groupId, leaving us with artifactId and version. 2.a. If so, how much detail? E.g. do we want to tell users they are getting some flavor of jetty 6 or do we want to tell them they are getting jetty 6.1.14? 2.b should the version numbering relate to the external project integration or to the geronimo version it fits with? My answers to these questions: (1) definitely YES. We may want to offer support for more than one level of the external project, and I don't think concealing major changes in an external code base is a good idea. (2) - Putting the first digit of the external version in the artifact Id clearly indicates the general level of external project support while allowing easy upgrades to later external versions within that major version. These are likely to be fairly compatible so may work find with artifact-aliases support rather than recompiling. This also clearly separates the geronimo portion of the version from the external project version since the external project version is not part of the maven version. - Changing major version of an external project may well require changes in code that uses the project. It's almost certain to require repackaging of plugins that run against the project; e.g. the
Re: Naming conventions for our adapter code and plugins for external projects
Donald Woods wrote: I guess the ral problem, is that we have two competing goals: 1) Custom Server Assemblies via car-maven-plugin - To provide multiple levels of modules/plugins to allow users to choose the level of components hey need, like Jetty6 vs. Jetty7. This is sort of what ServiceMix allows, by starting with the SMX4 Kernel and adding which features or individual OSGi plugins you want. It would be a great goal to finally implement in Geronimo 3.0, so users could choose between JEE5 and JEE6 components. 2) Preserving application compatibility on newer servers - If a user has an app working on Geronimo 2.0.x or 2.1.x, then we shouldn't require them to modify the app (source or plans) for it to work on future releases. Scenario #2 is the one I'm trying to preserve, as users expect this of us. I agree with both goals and particularly this second goal. Can't we just use the artifact alias as a way to manage the compatibility issues until we have a better solution? Including the major version in the name as David recommends and adding an artifact alias entry when the new component should be compatible with the old seems to achieve both goals. We would not include the alias entry in the event that the newer component is incompatible with the older one. The deploy failure a user would see if they failed to update their deployment plan would perhaps be a good way to alter them to the fact that some changes are necessary if they had not yet prepared for them. Joe -Donald David Jencks wrote: Both Donald and I seem to feel the answer to this is obvious but we have diametrically opposed points of view so maybe its time for discussion. After endless discussion we answered a related question for our specs with the following principal: The artifactId will contain the version number of the spec The version will only contain the geronimo version. I'm happy with this decision for specs. We include a lot of other projects in geronimo, such as activemq, axis, cxf, jetty, tomcat, etc etc. These projects evolve over the years and when they get to a fairly incompatible change level they generally change the major version number, such as jetty 6 to jetty 7, activemq 4 to activemq 5, etc etc. 1. Do we want to give our users a clue about which version of the external project they are using? If so, it has to be in the maven id for our plugin that, through dependencies, installs the external project. 2. If so, how? We get groupId, artifactId, version. I don't see a plausible way to use the groupId, leaving us with artifactId and version. 2.a. If so, how much detail? E.g. do we want to tell users they are getting some flavor of jetty 6 or do we want to tell them they are getting jetty 6.1.14? 2.b should the version numbering relate to the external project integration or to the geronimo version it fits with? My answers to these questions: (1) definitely YES. We may want to offer support for more than one level of the external project, and I don't think concealing major changes in an external code base is a good idea. (2) - Putting the first digit of the external version in the artifact Id clearly indicates the general level of external project support while allowing easy upgrades to later external versions within that major version. These are likely to be fairly compatible so may work find with artifact-aliases support rather than recompiling. This also clearly separates the geronimo portion of the version from the external project version since the external project version is not part of the maven version. - Changing major version of an external project may well require changes in code that uses the project. It's almost certain to require repackaging of plugins that run against the project; e.g. the jetty gbean wrappers changed dramatically from jetty 5 to 6 and are changing again from 6 to 7. - using the external project version would result in something like a version of 5.2.2.2-SNAPSHOT for our current amq 5 integration. However, there are some bugs so we'll need amq 5.3 or at least 5.2.1 before we release. So we'll need 5.3.2.2-SNAPSHOT even though our integration code didn't change. I guess we could use 5.2.2-SNAPSHOT although this seems very confusing compared to the amq version. So I'm having a lot of trouble seeing how any scheme other than stuff like activemq5 for the artifactId is remotely plausible. Thoughts? david jencks
Re: Naming conventions for our adapter code and plugins for external projects
I guess the ral problem, is that we have two competing goals: 1) Custom Server Assemblies via car-maven-plugin - To provide multiple levels of modules/plugins to allow users to choose the level of components hey need, like Jetty6 vs. Jetty7. This is sort of what ServiceMix allows, by starting with the SMX4 Kernel and adding which features or individual OSGi plugins you want. It would be a great goal to finally implement in Geronimo 3.0, so users could choose between JEE5 and JEE6 components. 2) Preserving application compatibility on newer servers - If a user has an app working on Geronimo 2.0.x or 2.1.x, then we shouldn't require them to modify the app (source or plans) for it to work on future releases. Scenario #2 is the one I'm trying to preserve, as users expect this of us. -Donald David Jencks wrote: Both Donald and I seem to feel the answer to this is obvious but we have diametrically opposed points of view so maybe its time for discussion. After endless discussion we answered a related question for our specs with the following principal: The artifactId will contain the version number of the spec The version will only contain the geronimo version. I'm happy with this decision for specs. We include a lot of other projects in geronimo, such as activemq, axis, cxf, jetty, tomcat, etc etc. These projects evolve over the years and when they get to a fairly incompatible change level they generally change the major version number, such as jetty 6 to jetty 7, activemq 4 to activemq 5, etc etc. 1. Do we want to give our users a clue about which version of the external project they are using? If so, it has to be in the maven id for our plugin that, through dependencies, installs the external project. 2. If so, how? We get groupId, artifactId, version. I don't see a plausible way to use the groupId, leaving us with artifactId and version. 2.a. If so, how much detail? E.g. do we want to tell users they are getting some flavor of jetty 6 or do we want to tell them they are getting jetty 6.1.14? 2.b should the version numbering relate to the external project integration or to the geronimo version it fits with? My answers to these questions: (1) definitely YES. We may want to offer support for more than one level of the external project, and I don't think concealing major changes in an external code base is a good idea. (2) - Putting the first digit of the external version in the artifact Id clearly indicates the general level of external project support while allowing easy upgrades to later external versions within that major version. These are likely to be fairly compatible so may work find with artifact-aliases support rather than recompiling. This also clearly separates the geronimo portion of the version from the external project version since the external project version is not part of the maven version. - Changing major version of an external project may well require changes in code that uses the project. It's almost certain to require repackaging of plugins that run against the project; e.g. the jetty gbean wrappers changed dramatically from jetty 5 to 6 and are changing again from 6 to 7. - using the external project version would result in something like a version of 5.2.2.2-SNAPSHOT for our current amq 5 integration. However, there are some bugs so we'll need amq 5.3 or at least 5.2.1 before we release. So we'll need 5.3.2.2-SNAPSHOT even though our integration code didn't change. I guess we could use 5.2.2-SNAPSHOT although this seems very confusing compared to the amq version. So I'm having a lot of trouble seeing how any scheme other than stuff like activemq5 for the artifactId is remotely plausible. Thoughts? david jencks
Re: svn commit: r724818 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
You are correct, sir.
On Tue, Dec 9, 2008 at 11:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Hey, you really should not rely on system environment variables here, as
> that kinda defeats the purpose of using the svn-based controllers for all
> configuration.
>
> I'd recommend you revert this and setup defaults in the controllers.
>
> --jason
>
>
>
> On Dec 10, 2008, at 1:50 AM, [EMAIL PROTECTED] wrote:
>
> Author: jawarner
>> Date: Tue Dec 9 10:50:26 2008
>> New Revision: 724818
>>
>> URL: http://svn.apache.org/viewvc?rev=724818&view=rev
>> Log:
>> Pull maven opts from agent environment
>>
>> Modified:
>>
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>>
>> Modified:
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> URL:
>> http://svn.apache.org/viewvc/geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy?rev=724818&r1=724817&r2=724818&view=diff
>>
>> ==
>> ---
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> (original)
>> +++
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> Tue Dec 9 10:50:26 2008
>> @@ -32,7 +32,7 @@
>>
>>def mavenHome = 'tools/maven'
>>
>> -def mavenOpts = null
>> +def mavenOpts = System.getenv('MAVEN_OPTS')
>>
>>def repoDir = 'repository'
>>
>>
>>
>>
>
--
~Jason Warner
Re: 2.2 (trunk) bucket-o-snapshots
Yep, looks like the activemq-broker is pulling in at least one of the commons-logging versions. I'll take a look at it today. -Donald Jason Dillon wrote: Commons-logging should not be included at all, we are using the slf4j adapters. --jason On Dec 10, 2008, at 2:18 AM, Donald Woods wrote: We also have multiple versions of some depends getting pulled into the assemblies right now, that needs to get fixed: commons-logging - 1.0.3 and 1.0.4 xpp3 and xpp3_min org.apache.ws.commons.schema.XmlSchema - 1.4.2 and SNAPSHOT Some new/questionable depends: com.envoisolutions.sxc.sxc-jaxb and sxc-runtime org.jvnet.staxex quartz.quartz And backport-util-concurrent is still in the distro... Also, can we remove com/sun/xml/ws/jaxws-rt and jaxws-tools, now that we are using CXF for wsgen? -Donald Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid-December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? OpenEJB 3.1-SNAPSHOT - Actually, OpenEJB 3.1 was released in late October. However, the trunk version was never updated and some additional changes have been included. Recent changes in Geronimo trunk now require this snapshot that is actually newer than the 3.1 release. IMO we should revert the trunk change and attempt to work with the released OpenEJB 3.1. Axis2 SNAPSHOT (yep, it's just SNAPSHOT without a number). IIUC correctly we need to get an Axis2 release before we can consider a Geronimo 2.2 release. Does anybody know how close we are to getting an Axis2 release? Axiom SNAPSHOT (yep. it's just SNAPSHOT too). I believe this is required by Axis2 ... so if Axis2 is released then they will have to get Axiom released as well (and we can pick up the released version). -xBean 3.5-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're still using 3.3. It looks like the latest released version is 3.4.3. I'll give that a shot if I don't hear from anybody that we really need 3.5. -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? -geronimo_j2ee-connector_1.6_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi_1.0_spec 1.0-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-servlet_3.0_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi 1.0-SNAPSHOT. This is a new geronimo component. How close is this to being able to be released? - geronimo-concurrent_1.0_spec 1.0-SNAPSHOT. How close is this to being able to be released? - XmlSchema SNAPSHOT (yep, it's just SNAPSHOT). I believe this is also related to Axis2 dependencies and will have to be resolved by Axis2 as they release. - woden* 1.0-SNAPSHOT. This is also related to Axis2 and will have to be resolved for an Axis2 release so we will pull in whatever they require. - selenium-maven-plugin 1.0-rc-1-SNAPSHOT. I believe that we pulled this in trying to resolve the FF3 issues. It's not clear to me if we would have to remove this SNAPSHOT prior to a release but I think it would be best to ensure that the tagged release can always be built and run with tests - therefore I think we should remove it. Any other opinions? - jspc-maven-plugin 2.0-alpha-2-SNAPSHOT. I'm not sure why this is updated (in branches/2.1 we use 2.0-alpha-1-20070806). Anybody know? We should remove it. - jspc-compiler-tomcat6 2.0-alpha-2-SNAPSHOT. I'm not sure why this was updated either. In branches/2.1 we updated the maven plugin (above) but not the compiler but in trunk both were updated to the alpha-2-SNAPSHOT. Anybody know why? - ianal-maven-plugin 1.0-alpha-1-SNAPSHOT. No doubt to support the new legal file processing. Is there a released version we can use instead of the SNAPSHOT or do we need to get a release here are well? Joe
[jira] Updated: (GERONIMO-4457) Add testcases about dynamic webservice interface Provider
[ https://issues.apache.org/jira/browse/GERONIMO-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4457: --- Attachment: (was: jaxws-provider-test.patch) > Add testcases about dynamic webservice interface Provider > - > > Key: GERONIMO-4457 > URL: https://issues.apache.org/jira/browse/GERONIMO-4457 > Project: Geronimo > Issue Type: Test > Security Level: public(Regular issues) > Components: webservices >Reporter: Ivan >Priority: Minor > > Provider interface is an important part for web service, especially for > Restful web service. Currently, no related testcases exist in our testsuite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
