[BUILD] trunk: Failed for Revision: 929865
Geronimo Revision: 929865 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/unit-test-reports [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/), java.net.2 (http://download.java.net/maven/1/), jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), openqa-releases (http://nexus.openqa.org/content/repositories/releases), smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) 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.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots
[jira] Created: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Attachment: HiThereSlow.ear HiThere.ear The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: HiThere.ear, HiThereSlow.ear Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852275#action_12852275 ] Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 7:51 AM: --- I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. was (Author: boes): The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: HiThere.ear, HiThereSlow.ear Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852275#action_12852275 ] Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 7:53 AM: --- I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed. was (Author: boes): I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: HiThere.ear, HiThereSlow.ear Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Attachment: getEnvironment.txt reorderModules.txt The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852281#action_12852281 ] Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 8:24 AM: --- The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient. was (Author: boes): The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852275#action_12852275 ] Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 8:25 AM: --- I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed. Turn on tracing and you see that the depencies tag is parsed more then a thousand times. was (Author: boes): I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Description: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. was: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL:
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Description: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. For me this works, but I don't know what the impact is for other users. In the code changes I attached I left it the way it was. was: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Description: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. was: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852281#action_12852281 ] Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 9:00 AM: --- I attached the two changed methods of the class org.apache.geronimo.st.core.internal.DependencyHelper that speed up publishing (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient. was (Author: boes): The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient. Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I return the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Description: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I returns the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. was: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Description: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.xml 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I returns the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. was: Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.mxl 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Attachment: reorderModules.txt Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.xml 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I returns the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boes updated GERONIMODEVTOOLS-608: -- Attachment: (was: reorderModules.txt) Publish with GEP takes minutes, while deploy takes seconds -- Key: GERONIMODEVTOOLS-608 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: GEP 2.2 installed in Eclipse (galileo-SR1). Reporter: Boes Assignee: Delos Dai Attachments: getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.xml 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. What I did to fix this problem and make GEP workable again for me is: - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I returns the result stored in the hashmap. After these two modifications GEP is up to speed again. Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r929741 - /geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
David,
This update is giving me a compile error on the latest trunk. The
OutboundResourceAdapter.isReauthenticationSupport() method returns null,
not a nullable object type. I checked against the latest from the
openejb project, that that still seems to be the case. Are you using a
different version of that class for your local builds?
Rick
On 3/31/2010 7:01 PM, djen...@apache.org wrote:
Author: djencks
Date: Wed Mar 31 23:01:38 2010
New Revision: 929741
URL: http://svn.apache.org/viewvc?rev=929741view=rev
Log:
GERONIMO-4360 glitch in merging annotations to ra.xml
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java?rev=929741r1=929740r2=929741view=diff
==
---
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
(original)
+++
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
Wed Mar 31 23:01:38 2010
@@ -653,7 +653,7 @@ public class ConnectorModuleBuilder impl
outboundResourceAdapter = new
OutboundResourceAdapter();
resourceAdapter.setOutboundResourceAdapter(outboundResourceAdapter);
}
-if (outboundResourceAdapter.isReauthenticationSupport()) {
+if (outboundResourceAdapter.isReauthenticationSupport() ==
null) {
outboundResourceAdapter.setReauthenticationSupport(ra.reauthenticationSupport());
}
if (outboundResourceAdapter.getTransactionSupport() ==
null) {
[BUILD] trunk: Failed for Revision: 929956
Geronimo Revision: 929956 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/build-0900.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/unit-test-reports [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/), java.net.2 (http://download.java.net/maven/1/), jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), openqa-releases (http://nexus.openqa.org/content/repositories/releases), smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) 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.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots
[jira] Created: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852396#action_12852396 ] Rick McGuire commented on GERONIMO-5221: This support is described section EE.5.16 of the Java EE 6 specification. This requires jndi lookup entries for java:comp/Validator and java:comp/ValidatorFactory. Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852398#action_12852398 ] Rick McGuire commented on GERONIMO-5222: Customization of the java:comp/ValidatorFactory lookup needs to be implemented using WEB-INF/validation.xml or META-INF/validation.xml descriptors as described in section EE.5.16 of the Java EE 6 specification. Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5223) Integrate the Bean Validation RI into Geronimo.
Integrate the Bean Validation RI into Geronimo. Key: GERONIMO-5223 URL: https://issues.apache.org/jira/browse/GERONIMO-5223 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5224) Add JNDI integration of Managed Beans.
Add JNDI integration of Managed Beans. --- Key: GERONIMO-5224 URL: https://issues.apache.org/jira/browse/GERONIMO-5224 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5224) Add JNDI integration of Managed Beans.
[ https://issues.apache.org/jira/browse/GERONIMO-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852401#action_12852401 ] Rick McGuire commented on GERONIMO-5224: Described in section EE.5.18 of Java EE 6 specification. Add JNDI integration of Managed Beans. --- Key: GERONIMO-5224 URL: https://issues.apache.org/jira/browse/GERONIMO-5224 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5225) Implement Bean Manager References (Java EE 6 spec section EE.5.19)
Implement Bean Manager References (Java EE 6 spec section EE.5.19) -- Key: GERONIMO-5225 URL: https://issues.apache.org/jira/browse/GERONIMO-5225 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5226) Pass container ValidationFactory to the persistance manager when creating an entity manager.
Pass container ValidationFactory to the persistance manager when creating an entity manager. - Key: GERONIMO-5226 URL: https://issues.apache.org/jira/browse/GERONIMO-5226 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5226) Pass container ValidationFactory to the persistance manager when creating an entity manager.
[ https://issues.apache.org/jira/browse/GERONIMO-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852405#action_12852405 ] Rick McGuire commented on GERONIMO-5226: Section 3.6.2 of the JPA 2.0 spec specifies that the in Java EE environments, a ValidatorFactory instance be made available by the Java EE container. This instance is passed to the persistence provider via a property on the createContainerEntityManagerFactory() call. This might require implementation/integration with OpenEJB. Pass container ValidationFactory to the persistance manager when creating an entity manager. - Key: GERONIMO-5226 URL: https://issues.apache.org/jira/browse/GERONIMO-5226 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Publish with GEP takes minutes, while deploy takes 10 seconds
Hello Delos, I created a JIRA: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 I made a fix for this issue to the GEP V2.2 code and now the GEP is publishing at full speed. See the JIRA for the details. And could you please remove my address and telephonenumber in your previous post. I didn't know the e-mail I sent to you, would be showed on the net directly :) Boes Hi Boes, I also found with eclipse 3.5+, the deployment seems slower than before. I'm still investigating the root cause. In deployment process, GEP will pass all artifacts(EAR,WAR,JAR) to WTP. As I know, WTP will analyze these artifacts, generate many objects, packageextract them. I've ever tried a big EAR and found most time is consumed by WTP. But I haven't further investigated the process in WTP. If possible, could you provide your app for me to double check the problem? Although we haven't found the root cause, there may be some workaround for you 1) To speed up the deployment of JSP, you can select No re-deployment when only JSP files are updated in Test environment section of server Overview page. You may find the page after double click server instance in Servers view. 2) Put all lib you will never change as shared library in Geronimo server 3) Avoid automatic publishing. If automatic publishing is enabled, any save action on an deployed artifact will trigger publishing. It's inconvenient for a big artifact. I suggest you disable it and manually publish it when all your changes have been completed. You can select Never publish automatically in Publishing section of server Overview page. Hope it helps! 2010/3/30 boes g...@xs4all.nl -- View this message in context: http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-tp684484p690321.html Sent from the Development mailing list archive at Nabble.com.
Re: svn commit: r929741 - /geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
Rick,
I had an uncommitted openejb change, now committed rev 930005.
thanks
david jencks
On Apr 1, 2010, at 3:31 AM, Rick McGuire wrote:
David,
This update is giving me a compile error on the latest trunk. The
OutboundResourceAdapter.isReauthenticationSupport() method returns null, not
a nullable object type. I checked against the latest from the openejb
project, that that still seems to be the case. Are you using a different
version of that class for your local builds?
Rick
On 3/31/2010 7:01 PM, djen...@apache.org wrote:
Author: djencks
Date: Wed Mar 31 23:01:38 2010
New Revision: 929741
URL: http://svn.apache.org/viewvc?rev=929741view=rev
Log:
GERONIMO-4360 glitch in merging annotations to ra.xml
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
Modified:
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java?rev=929741r1=929740r2=929741view=diff
==
---
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
(original)
+++
geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/src/main/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilder.java
Wed Mar 31 23:01:38 2010
@@ -653,7 +653,7 @@ public class ConnectorModuleBuilder impl
outboundResourceAdapter = new
OutboundResourceAdapter();
resourceAdapter.setOutboundResourceAdapter(outboundResourceAdapter);
}
-if
(outboundResourceAdapter.isReauthenticationSupport()) {
+if (outboundResourceAdapter.isReauthenticationSupport()
== null) {
outboundResourceAdapter.setReauthenticationSupport(ra.reauthenticationSupport());
}
if (outboundResourceAdapter.getTransactionSupport() ==
null) {
[jira] Created: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
[ https://issues.apache.org/jira/browse/GERONIMO-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852429#action_12852429 ] Rick McGuire commented on GERONIMO-5227: In JSF spec section 3.5.6.2, it specifies that Java EE runtime should pass the ValidatorFactory instance to the JSF runtime by setting an attribute named javax.faces.validator.beanValidator in the servlet context. Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4990) Add serialVersionUID to serializable spec classes from javadoc
[ https://issues.apache.org/jira/browse/GERONIMO-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-4990. Resolution: Fixed I believe this work is complete now. If additional areas are found, then this should be handled by individual Jiras. Add serialVersionUID to serializable spec classes from javadoc -- Key: GERONIMO-4990 URL: https://issues.apache.org/jira/browse/GERONIMO-4990 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, specs Affects Versions: 3.0 Reporter: David Jencks Assignee: Delos Dai Fix For: 3.0 The javadoc for the spec jars seems to generally include serialVersionUID values for serializable classes. Not all of our spec jars have specified these according to the javadoc. We should review the javadoc for all the specs and add serialVersionUID where they are missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5228) Add classes for parsing a validation.xml descriptor
Add classes for parsing a validation.xml descriptor --- Key: GERONIMO-5228 URL: https://issues.apache.org/jira/browse/GERONIMO-5228 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Rick McGuire -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5229) PropertyEditors is too willing to pull in editors we don'e necessarly want
PropertyEditors is too willing to pull in editors we don'e necessarly want -- Key: GERONIMO-5229 URL: https://issues.apache.org/jira/browse/GERONIMO-5229 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: common Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 AMQ just added a StringArrayEditor that uses spring classes so we can't load it. For some reason this is getting pulled in when loading j2ee-deployer. There's something wrong with the visibility rules in PropertyEditors. -- 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: 930064
Geronimo Revision: 930064 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/build-1500.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/unit-test-reports [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/), java.net.2 (http://download.java.net/maven/1/), jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), openqa-releases (http://nexus.openqa.org/content/repositories/releases), smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) 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.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots
[BUILD] trunk: Failed for Revision: 930144
Geronimo Revision: 930144 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100401/unit-test-reports [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/), java.net.2 (http://download.java.net/maven/1/), jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), openqa-releases (http://nexus.openqa.org/content/repositories/releases), smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) 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.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -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.apache.aries -DartifactId=org.apache.aries.util -Dversion=0.1-incubating-20100312.185411-2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT 2) org.apache.felix.karaf:org.apache.felix.karaf.client:jar:1.5.0-SNAPSHOT 3) org.apache.aries:org.apache.aries.util:jar:0.1-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.bundles:karaf-client:jar:1.5.0-SNAPSHOT_1-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots
[jira] Updated: (GERONIMO-4592) Upgrade to OpenEJB 3.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4592: --- Fix Version/s: (was: 2.1.4) Upgrade to OpenEJB 3.0.1 Key: GERONIMO-4592 URL: https://issues.apache.org/jira/browse/GERONIMO-4592 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.5 Upgrade to newly released OpenEJB 3.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4592) Upgrade to OpenEJB 3.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4592. -- Will update to OpenEJB 3.0.2 Upgrade to OpenEJB 3.0.1 Key: GERONIMO-4592 URL: https://issues.apache.org/jira/browse/GERONIMO-4592 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.5 Upgrade to newly released OpenEJB 3.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4592) Upgrade to OpenEJB 3.0.2
[ https://issues.apache.org/jira/browse/GERONIMO-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4592: --- Description: Upgrade to newly released OpenEJB 3.0.2 (was: Upgrade to newly released OpenEJB 3.0.1) Summary: Upgrade to OpenEJB 3.0.2 (was: Upgrade to OpenEJB 3.0.1) Upgrade to OpenEJB 3.0.2 Key: GERONIMO-4592 URL: https://issues.apache.org/jira/browse/GERONIMO-4592 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.5 Upgrade to newly released OpenEJB 3.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4593) Upgrade to OpenJPA 1.2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852634#action_12852634 ] Rex Wang commented on GERONIMO-4593: 1.2.2 in branch21 @ rev 906328 1.2.2 in branch22 @ rev 908198 Upgrade to OpenJPA 1.2.1 Key: GERONIMO-4593 URL: https://issues.apache.org/jira/browse/GERONIMO-4593 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.4, 2.1.5, 2.2 Upgrade to OpenJPA 1.2.1 when released -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4593) Upgrade to OpenJPA 1.2.2
[ https://issues.apache.org/jira/browse/GERONIMO-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4593: --- Description: Upgrade to OpenJPA 1.2.1 when released Upgrade to OpenJPA 1.2.2 when released was:Upgrade to OpenJPA 1.2.1 when released Fix Version/s: (was: 2.1.4) (was: 2.2) 2.2.1 Summary: Upgrade to OpenJPA 1.2.2 (was: Upgrade to OpenJPA 1.2.1) Upgrade to OpenJPA 1.2.2 Key: GERONIMO-4593 URL: https://issues.apache.org/jira/browse/GERONIMO-4593 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.5, 2.2.1 Upgrade to OpenJPA 1.2.1 when released Upgrade to OpenJPA 1.2.2 when released -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4243) EAR Deploy Error
[
https://issues.apache.org/jira/browse/GERONIMO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-4243.
--
closing it
EAR Deploy Error
Key: GERONIMO-4243
URL: https://issues.apache.org/jira/browse/GERONIMO-4243
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: console, deployment, Jetty, Tomcat, webservices
Affects Versions: 2.1.2, 2.1.3, 2.2
Environment: Java
java.awt.graphicsenv sun.awt.X11GraphicsEnvironment
java.awt.printerjob sun.print.PSPrinterJob
java.class.path
/usr/local/geronimo/bin/server.jar
/usr/local/geronimo/bin/jpa.jar
java.class.version49.0
java.endorsed.dirs
/usr/local/geronimo/lib/endorsed
/usr/local/java/jre/lib/endorsed
java.ext.dirs
/usr/local/geronimo/lib/ext
/usr/local/java/jre/lib/ext
java.home /home/oxseed/jdk1.5.0_15/jre
java.io.tmpdir/home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/temp
java.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386/server
/home/oxseed/jdk1.5.0_15/jre/lib/i386
/home/oxseed/jdk1.5.0_15/jre/../lib/i386
java.runtime.name Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version 1.5.0_15-b04
java.specification.name Java Platform API Specification
java.specification.vendor Sun Microsystems Inc.
java.specification.version1.5
java.util.prefs.PreferencesFactory
java.vendor- Sun Microsystems Inc.
java.vendor.url http://java.sun.com/
java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi
java.version- 1.5.0_15
Virtual Machine
java.vm.info mixed mode
java.vm.name Java HotSpot(TM) Server VM
java.vm.specification.nameJava Virtual Machine Specification
java.vm.specification.vendor Sun Microsystems Inc.
java.vm.specification.version 1.0
java.vm.vendorSun Microsystems Inc.
java.vm.version 1.5.0_15-b04
Operating System
os.arch i386
os.name Linux
os.version2.6.16.33-xen
Sun
sun.arch.data.model 32
sun.boot.class.path
/usr/local/geronimo/lib/endorsed/yoko-spec-corba-1.0.jar
/usr/local/geronimo/lib/endorsed/yoko-rmi-spec-1.0.jar
/home/oxseed/jdk1.5.0_15/jre/lib/rt.jar
/home/oxseed/jdk1.5.0_15/jre/lib/i18n.jar
/home/oxseed/jdk1.5.0_15/jre/lib/sunrsasign.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jsse.jar
/home/oxseed/jdk1.5.0_15/jre/lib/jce.jar
/home/oxseed/jdk1.5.0_15/jre/lib/charsets.jar
/home/oxseed/jdk1.5.0_15/jre/classes
sun.boot.library.path
/home/oxseed/jdk1.5.0_15/jre/lib/i386
sun.cpu.endianlittle
sun.cpu.isalist
sun.io.unicode.encoding UnicodeLittle
sun.java2d.fontpath
sun.os.patch.levelunknown
User
user.country US
user.dir /home/oxseed
user.home /home/oxseed
user.language en
user.name oxseed
user.timezone Europe/Berlin
user.variant
Etc
admin.disabledtrue
catalina.base /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.home /home/oxseed/geronimo-tomcat6-javaee5-2.1.2/var/catalina
catalina.useNamingfalse
com.sun.management.jmxremote
com.sun.management.jmxremote.authenticate false
com.sun.management.jmxremote.port 8004
com.sun.management.jmxremote.ssl false
common.loader ${catalina.home}/lib ${catalina.home}/lib/*.jar
derby.storage.fileSyncTransactionLog true
derby.system.home /home/oxseed
duct tape
file.encoding ANSI_X3.4-1968
file.encoding.pkg sun.io
file.separator/
java.naming.factory.initial
org.apache.xbean.naming.global.GlobalContextManager
java.naming.factory.url.pkgs org.apache.xbean.naming
java.naming.provider.url rmi://0.0.0.0:1099
java.net.preferIPv4Stack true
java.rmi.server.RMIClassLoaderSpi
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
java.rmi.server.randomIDs true
java.security.ProviderSUN
javax.rmi.CORBA.PortableRemoteObjectClass
org.apache.yoko.rmi.impl.PortableRemoteObjectImpl
javax.rmi.CORBA.StubClass org.apache.yoko.rmi.impl.StubImpl
javax.rmi.CORBA.UtilClass org.apache.geronimo.corba.util.UtilDelegateImpl
javax.security.jacc.PolicyConfigurationFactory.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicyConfigurationFactory
javax.security.jacc.policy.provider
org.apache.geronimo.security.jacc.mappingprovider.GeronimoPolicy
javax.xml.soap.MessageFactory
org.apache.geronimo.webservices.saaj.GeronimoMessageFactory
javax.xml.soap.MetaFactory
org.apache.geronimo.webservices.saaj.GeronimoMetaFactory
javax.xml.soap.SOAPConnectionFactory
org.apache.geronimo.webservices.saaj.GeronimoSOAPConnectionFactory
javax.xml.soap.SOAPFactory
org.apache.geronimo.webservices.saaj.GeronimoSOAPFactory
line.separator
[jira] Closed: (GERONIMO-4593) Upgrade to OpenJPA 1.2.2
[ https://issues.apache.org/jira/browse/GERONIMO-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4593. -- Upgrade to OpenJPA 1.2.2 Key: GERONIMO-4593 URL: https://issues.apache.org/jira/browse/GERONIMO-4593 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.5, 2.2.1 Upgrade to OpenJPA 1.2.1 when released Upgrade to OpenJPA 1.2.2 when released -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-3003.
--
closing it
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Assignee: Shawn Jiang
Priority: Minor
Fix For: 2.1.5, 2.2.1, 3.0
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.cmd.21.patch,
GERONIMO-3003.cmd.22.patch, GERONIMO-3003.gshell.cmd 30.patch,
GERONIMO-3003.patch, GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4588) Adding multiple server with the same host in monitoring portlet results in a sql error
[ https://issues.apache.org/jira/browse/GERONIMO-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4588. -- closing it Adding multiple server with the same host in monitoring portlet results in a sql error -- Key: GERONIMO-4588 URL: https://issues.apache.org/jira/browse/GERONIMO-4588 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4, 2.2 Environment: Windows XP, Geronimo V2.1.4 Reporter: Ashish Jain Assignee: Joe Bohn Fix For: 2.1.4, 2.1.5, 2.2 Attachments: geronimo-4588.patch, Geronimo-4588_Jack.patch Adding multiple server with same host in monitoring portlet results in a sql error. It seems the IP attribute in Servers table is defined to be unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4545) TomcatJAASRealm keeps reference to undeployed EAR/WAR's classloader
[
https://issues.apache.org/jira/browse/GERONIMO-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-4545.
--
closing it
TomcatJAASRealm keeps reference to undeployed EAR/WAR's classloader
---
Key: GERONIMO-4545
URL: https://issues.apache.org/jira/browse/GERONIMO-4545
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Memory Leaks, security, Tomcat
Affects Versions: 2.2
Reporter: Janko Heilgeist
Assignee: Ivan
Priority: Blocker
Fix For: 2.1.5, 2.2
Another issue where an undeployed WAR's classloader is not GCed.
{code}
-- org.apache.geronimo.tomcat.realm.tomcatjaasre...@0x2aaab10ab438 (180
bytes) (field container:) exclude
-- org.apache.geronimo.tomcat.geronimostandardcont...@0x2aaab322d390 (749
bytes) (field parentClassLoader:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2e9b2e0
(156 bytes) (field parents:) exclude
-- [Ljava.lang.ClassLoader;@0x2aaab0b97958 (88 bytes) (Element 1 of
[Ljava.lang.ClassLoader;@0x2aaab0b97958:) exclude
--
org.apache.geronimo.kernel.config.childrenconfigurationclassloa...@0x2aaab05e8bc0
(115 bytes) (field parent:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2e9b230
(156 bytes) exclude
{code}
It looks to me like the TomcatJAASRealm (its name is DefaultJAASRealm) is a
standard realm that is used by all WARs without explicit configuration.
Setting the realm of a GeronimoStandardContext makes the context store a
reference to its realm AND makes the realm store a reference to the context
(see org.apache.catalina.core.ContainerBase#setRealm() which
GeronimoStandardContext inherits). Thus, the default realm's reference is
always directed to the context of the WAR deployed most recently. This
reference keeps the context from being GCed even if the corresponding WAR has
been undeployed in the meantime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4597) Validate Web Admin Console input - address admin console security vulnerabilities
[ https://issues.apache.org/jira/browse/GERONIMO-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4597. -- closing it Validate Web Admin Console input - address admin console security vulnerabilities - Key: GERONIMO-4597 URL: https://issues.apache.org/jira/browse/GERONIMO-4597 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.4, 2.1.5, 2.2 Attachments: G4597_branch_20.patch This JIRA addresses the following security vulnerabilities in the web admin console: CVE-2008-5518: Apache Geronimo web administration console directory traversal vulnerabilities. A vulnerability was found in several portlets including Services/Repository, Embedded DB/DB Manager, and Security/Keystores when running the Apache Geronimo server on Windows. This issue may allow a remote attacker to upload any file in any directory. This affects all full JavaEE Geronimo assemblies or other distributions which include the administration web console up to and including Apache Geronimo 2.1.3. An alternative workaround (if you choose to not upgrade to Apache Geronimo 2.1.4) would be to stop or undeploy the administration web console application in the server. Credit: The Apache Geronimo project would like to thank Digital Security Research Group (dsecrg.com) for responsibly reporting this issue and assisting us with validating our fixes. CVE-2009-0038: Apache Geronimo web administration console XSS vulnerabilities Various linked and stored cross-site scripting (XSS) vulnerabilities were found in the Apache Geronimo administrative console and related utilities. Using this vulnerability an attacker can steal an administrator's cookie and then authenticate as administrator or perform certain administrative actions. For example, a user can inject XSS in some URLs or in several input fields in various portlets. This affects all full JavaEE Geronimo assemblies or other distributions which include the administration web console up to and including Apache Geronimo 2.1.3. An alternative workaround (if you choose to not upgrade to Apache Geronimo 2.1.4) would be to stop or undeploy the administration web console application in the server. Credit: The Apache Geronimo project would like to thank Digital Security Research Group (dsecrg.com) and Marc Schoenefeld (Red Hat Security Response Team) for responsibly reporting this issue and assisting us with validating our fixes. CVE-2009-0039: Apache Geronimo web administration console XSRF vulnerabilities Various cross-site request forgery (XSRF or CSRF) vulnerabilities were identified in the Apache Geronimo web administration console. Exploiting these issues may allow a remote attacker to perform certain administrative actions, e.g. change web administration password, upload applications, etc... using predictable URL requests once the user has authenticated and obtained a valid session with the server. This affects all full JavaEE Geronimo assemblies or other distributions which include the administration web console up to and including Apache Geronimo 2.1.3. An alternative workaround (if you choose to not upgrade to Apache Geronimo 2.1.4) would be to stop or undeploy the administration web console application in the server. Credit: The Apache Geronimo project would like to thank Digital Security Research Group (dsecrg.com) for responsibly reporting this issue and assisting us with validating our fixes. It corrects the issues with the addition of directory checks and a servlet filter to check for XSS and XSRF vulnerabilities -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4664) OpenSSO Deployment fails with WSDL generation failed
[ https://issues.apache.org/jira/browse/GERONIMO-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4664. -- closing it OpenSSO Deployment fails with WSDL generation failed -- Key: GERONIMO-4664 URL: https://issues.apache.org/jira/browse/GERONIMO-4664 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1.5, 2.2 Deployment of the OpenSSO war (see https://opensso.dev.java.net/public/use/ for download) will result in a WSDL generation failed error. OpenSSO has also identified an XBean bug, see XBEAN-126. However, this problem is not causing the WSDL generation error. I don't think that XBEAN-126 actually causes a failure -- it just generates a lot of stacktraces to STDOUT. In addition to fixing the wsdl generation error, should we consider capturing more information about the generation failure? Info on what might actually be wrong would sure be useful... I'm running this on G 2.1.4 (Tomcat/Axis2). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4722) XSS/XSRF filters are triggering Session object creation for unknown URLs
[ https://issues.apache.org/jira/browse/GERONIMO-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4722. -- closing it XSS/XSRF filters are triggering Session object creation for unknown URLs Key: GERONIMO-4722 URL: https://issues.apache.org/jira/browse/GERONIMO-4722 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.4, 2.2 Reporter: Kevan Miller Assignee: Joe Bohn Priority: Minor Fix For: 2.1.5, 2.2 The XSS/XSRF filters are causing session objects to be created for unknown urls. For instance, a request for localhost:8080/nonexistenturl creates a session, as indicated in following stack trace: http-0.0.0.0-808...@10 daemon, priority=5, in group 'main', status: 'RUNNING' at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:284) at org.apache.catalina.connector.Request.doGetSession(Request.java:2,312) at org.apache.catalina.connector.Request.getSession(Request.java:2,075) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at org.apache.geronimo.console.filter.XSRFHandler.isInvalidSession(XSRFHandler.java:79) at org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:613) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4865) Login module to enable Kerberos authentication
[ https://issues.apache.org/jira/browse/GERONIMO-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4865. -- closing it Login module to enable Kerberos authentication --- Key: GERONIMO-4865 URL: https://issues.apache.org/jira/browse/GERONIMO-4865 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: security Reporter: Ashish Jain Assignee: Ashish Jain Fix For: 2.1.5, 2.2, 3.0 Attachments: KerberosLoginModule.java, KerberosLoginModule.java_initial A new login module for using the kerberos authentication mechanism in geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4643) Geronimo LDAP realm follow referrals
[ https://issues.apache.org/jira/browse/GERONIMO-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-4643. -- closing it Geronimo LDAP realm follow referrals Key: GERONIMO-4643 URL: https://issues.apache.org/jira/browse/GERONIMO-4643 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1.4 Environment: Windows XP, Java 1.5.0_06 Reporter: Bobby Lawrence Assignee: Jarek Gawor Priority: Critical Fix For: 2.1.5, 2.2 After setting up an LDAP realm and testing a login, the server throws the following error: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); ... I have even set the system property java.naming.referral=follow and I get the same problems. It would also be great if I could test login modules AFTER they are deployed. I really like being able to test when I'm setting them up, but after the deployment would really be useful in diagnosing problems. Also - it would be nice if I could delete a realm from the console. And..sorry for everything at onceit would be helpful if I could deploy an application from the console and not have to do it from the command line -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4896) Commands to a Secure JMX Connector require the SSL keyStorePassword to be specified on command line
[
https://issues.apache.org/jira/browse/GERONIMO-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-4896.
--
closing it
Commands to a Secure JMX Connector require the SSL keyStorePassword to be
specified on command line
---
Key: GERONIMO-4896
URL: https://issues.apache.org/jira/browse/GERONIMO-4896
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.5, 2.2, 3.0
Reporter: Kevan Miller
Assignee: Shawn Jiang
Fix For: 2.1.5, 2.2.1, 3.0, Wish List
Attachments: 4896.patch, 4896_21.patch, 4896_updated.patch,
4896_updated_21.patch, JavaAgent.jar, JvmOpts.java
To my knowledge, it is not possible to run a Geronimo command (e.g. deploy.sh
deploy or gsh geronimo/stop-server) to a server with a secure JMX Connector
(running SSL, without specifying the following Java system properties on the
command line:
javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword
For example:
{code}
export GERONIMO_HOME=~/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
export
JAVA_OPTS=-Djavax.net.ssl.keyStore=$GERONIMO_HOME/var/security/keystores/geronimo-default
-Djavax.net.ssl.keyStorePassword=secret
-Djavax.net.ssl.trustStore=$GERONIMO_HOME/var/security/keystores/geronimo-default
-Djavax.net.ssl.trustStorePassword=secret
$GERONIMO_HOME/bin/deploy.sh -u system -p manager --secure list-modules
--stopped
{code}
javax.net.ssl.keyStorePassword causes a problem, since this means the
keyStorePassword is available, in-the-clear, to someone inspecting executing
processes. For example while a deploy command was active, someone could run
'ps auxww | grep deployer.jar' and discover the keyStorePassword for the
KeyStore.
Geronimo should provide a mechanism, whereby users can specify the
keyStorePassword without making that secret available to anyone inspecting
processes running on the current system. Ideally, the password could be
encrypted/obfuscated within a file (just as passwords can be
encrypted/obfuscated in var/config/config.xml).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4614) Overloaded WSDL operations are not supported
[
https://issues.apache.org/jira/browse/GERONIMO-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-4614.
--
closing it
Overloaded WSDL operations are not supported
Key: GERONIMO-4614
URL: https://issues.apache.org/jira/browse/GERONIMO-4614
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.1.4
Reporter: Christopher James Blythe
Assignee: Jarek Gawor
Priority: Blocker
Fix For: 2.1.5
Performing certification testing for SpecjEnt benchmark on Geronimo 2.1.4,
ran in the following issue.
2009-04-03 15:39:16,576 ERROR [Axis2WebServiceContainer] Exception occurred
while trying to invoke service method doService()
javax.xml.ws.WebServiceException: More than one operation found. Overloaded
WSDL operations are not supported. WSDL Operation name:
{http://session.mfg.ejb.jappserver.spec.org/}checkForRequestedWork
at
org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:172)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:117)
at
org.apache.geronimo.axis2.ejb.EJBMessageReceiver.getOperationDescription(EJBMessageReceiver.java:138)
at
org.apache.geronimo.axis2.ejb.EJBMessageReceiver.receive(EJBMessageReceiver.java:68)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.processXMLRequest(Axis2WebServiceContainer.java:404)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.processPOSTRequest(Axis2WebServiceContainer.java:353)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService2(Axis2WebServiceContainer.java:282)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService(Axis2WebServiceContainer.java:217)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.invoke(Axis2WebServiceContainer.java:177)
at
org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:182)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:735)
Based on some feedback from colleagues, the issues stems from...
the problem was that the application uses 3 levels of inheritence...
interface 1 (annotated web service)
interface 2 (extends interface1, not a web service)
implementor (web service)
it can handle the
interface 1 (web service)
implementor (web service)
case, but the non-web-service in the middle caused it to blow up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5027) Redeploy option for farming
[ https://issues.apache.org/jira/browse/GERONIMO-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-5027. -- closing it Redeploy option for farming --- Key: GERONIMO-5027 URL: https://issues.apache.org/jira/browse/GERONIMO-5027 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4, 2.2 Environment: Windows XP g214 Reporter: Ashish Jain Assignee: Shawn Jiang Fix For: 2.1.5, 2.2.1, 3.0 Attachments: 5027_21.patch, 5027_21_updated.patch Redeploy feature for farming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5200) high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader
[ https://issues.apache.org/jira/browse/GERONIMO-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-5200. -- closing it high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader -- Key: GERONIMO-5200 URL: https://issues.apache.org/jira/browse/GERONIMO-5200 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.1.4, 2.2 Environment: Linux 64 bits, geronimo 2.2 build 2009.12.07-18:20:06.045-0800 Reporter: Marco Laponder Assignee: Kevan Miller Fix For: 2.1.5, 2.2.1 Attachments: thread.dump Sometimes during the use of our webapplication the cpu of our server has extereme high load caused by geronimo which stays high forever untillI stop geronimo. I have created a thread dump when the cpu load is high (attached to this jira). Suspicious in this thread dump are multiple thread in the containsKey. As not all the access of the resourcesNotFOund map is not synchronized this could be the cause of the problem as this might result in a infinite loop when the contains method is called during a map resize. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5162) CXF adds a key mapping for WebServiceContext
[ https://issues.apache.org/jira/browse/GERONIMO-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-5162. -- closing it CXF adds a key mapping for WebServiceContext Key: GERONIMO-5162 URL: https://issues.apache.org/jira/browse/GERONIMO-5162 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.5 Reporter: Ivan Assignee: Ivan Fix For: 2.1.5 In the cxf 2.0.12, it maintanes a key mapping in the webservicecontext, Geronimo needs to change to cxf keys. Like HTTP.REQUEST, not the MessageContext.SERVLET_REQUEST, etc. Also need to check whether other cxf builds are affected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5156) Command line utility to unlock a keystore and private key
[ https://issues.apache.org/jira/browse/GERONIMO-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-5156. -- closing it Command line utility to unlock a keystore and private key - Key: GERONIMO-5156 URL: https://issues.apache.org/jira/browse/GERONIMO-5156 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: security Environment: geronimo tomcat assembly Reporter: Ashish Jain Assignee: Ivan Fix For: 2.1.5, 2.2.1, 3.0 Attachments: 5156_21.patch, 5156_21_updated.patch, 5156_one_line_of_code.patch, CommandUnlockKeystore.java, UnlockKeystoreCommandMetaData.java A command line utility to unlock a keystore and private key. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5155) Locking a keystore under Available results in exception
[ https://issues.apache.org/jira/browse/GERONIMO-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang closed GERONIMO-5155. -- closing it Locking a keystore under Available results in exception -- Key: GERONIMO-5155 URL: https://issues.apache.org/jira/browse/GERONIMO-5155 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1.4, 2.2 Environment: geronimo tomcat assembly Reporter: Ashish Jain Assignee: Ashish Jain Fix For: 2.1.5, 2.2.1, 3.0 Attachments: 5155_21.patch Llocking a keystore under Available tab in Keystore portlet results in a null pointer on the web browser for 2.1. Here is the exception on 2.1 java.lang.NullPointerException org.apache.geronimo.console.keystores.LockKeystoreHandler.actionBeforeView(LockKeystoreHandler.java:43) org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:112) org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) javax.servlet.http.HttpServlet.service(HttpServlet.java:693) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) javax.servlet.http.HttpServlet.service(HttpServlet.java:693) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.geronimo.console.filter.PlutoUrlRebuildFilter.doFilter(PlutoUrlRebuildFilter.java:48) org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) For 2.2 the error thrown is 2010-02-23 23:00:56,062 ERROR [MultiPagePortlet] Unrecognized portlet action 'lockKeystore' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4616) Update xmlbeans plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4616: --- Issue Type: Improvement (was: Bug) Update xmlbeans plugin -- Key: GERONIMO-4616 URL: https://issues.apache.org/jira/browse/GERONIMO-4616 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.5, 2.2 Reporter: David Jencks Assignee: Rex Wang Fix For: 2.1.5, 2.2 See http://jira.codehaus.org/browse/MXMLBEANS-54 We have some hacks in our build to copy the xmlbeans generated source directory to somewhere eclipse will find it in order to make eclipse:eclipse work properly. We should check that this hack is no longer needed with the updated xmlbeans plugin, currently 2.3.3-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4628) Console plan wizards need to save plans
[ https://issues.apache.org/jira/browse/GERONIMO-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4628: --- Issue Type: Improvement (was: Bug) Console plan wizards need to save plans --- Key: GERONIMO-4628 URL: https://issues.apache.org/jira/browse/GERONIMO-4628 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.5, 2.2 Attachments: Geronimo-4628-b21-new.patch, GERONIMO-4628-b21-updated.patch, GERONIMO-4628-b21.patch Currently we have a lot of console wizards that are great at creating basic plans for datasources, security realms, etc etc. However once you've deployed the plan through the wizard the plan is gone gone gone never to be seen again. The wizards need to do _something_ so the plans are saved on disk somehow. One possibliity is that deployment could always save the plan into the car file, like the car-maven-plugin does. I'm not certain but I think this would fix the admin console wizard problem as well. Also it would be very handy if the wizard inserted a comment mentioning the intended target artifact, such as which tranql adapter to use for a datasource plan. Furthermore you ought to be able to specify all components of the artifact id (groupId, etc) in all the wizards. In fact you should be able to set the default groupId for the whole admin console -- probably your company wants all the groupIds the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4716: --- Issue Type: Improvement (was: Bug) Upgrade HTTPComponent HTTPCore to released version 4.0.1 Key: GERONIMO-4716 URL: https://issues.apache.org/jira/browse/GERONIMO-4716 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Fix For: 2.1.5, 2.2 Attachments: GERONIMO-4716_21.patch, GERONIMO-4716_trunk.patch We using 4.0 alpha or beta versions of HTTPComponent's HTTPCore in 2.1 and 2.2 code. Might want to upgrade the latest release version which 4.0.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4929) Upgrade to latest tranql wrappers
[ https://issues.apache.org/jira/browse/GERONIMO-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4929: --- Issue Type: Improvement (was: Bug) Upgrade to latest tranql wrappers - Key: GERONIMO-4929 URL: https://issues.apache.org/jira/browse/GERONIMO-4929 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.1.4, 2.2, 3.0 Reporter: David Jencks Assignee: Ashish Jain Fix For: 2.1.5, 2.2, 3.0 Tranql has just released new wrappers that recognize some non-fatal sql exceptions and use ConnectionPoolDatasource rather than Driver or Datasource when we have figured out how. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-4929) Upgrade to latest tranql wrappers
[ https://issues.apache.org/jira/browse/GERONIMO-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838241#action_12838241 ] Rex Wang edited comment on GERONIMO-4929 at 4/2/10 2:11 AM: if no objections, I will update these for G2.1.5 branch 21 with rev. 916184 branch 22 with rev. 920239 was (Author: rwonly): if no objections, I will update these for G2.1.5 Upgrade to latest tranql wrappers - Key: GERONIMO-4929 URL: https://issues.apache.org/jira/browse/GERONIMO-4929 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.1.4, 2.2, 3.0 Reporter: David Jencks Assignee: Ashish Jain Fix For: 2.1.5, 2.2, 3.0 Tranql has just released new wrappers that recognize some non-fatal sql exceptions and use ConnectionPoolDatasource rather than Driver or Datasource when we have figured out how. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-5122) Upgrade Tomcat to 6.0.26
[ https://issues.apache.org/jira/browse/GERONIMO-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai resolved GERONIMO-5122. - Resolution: Fixed #930152, update tomcat to 6.0.26.0 in 2.2 branch Upgrade Tomcat to 6.0.26 Key: GERONIMO-5122 URL: https://issues.apache.org/jira/browse/GERONIMO-5122 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.5, 2.2.1 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.1.5, 2.2.1 Upgrade Tomcat to version 6.0.26 1) Pull in the source code into geronimo external directory 2) Commit necessary patches for geronimo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5122) Upgrade Tomcat to 6.0.26
[ https://issues.apache.org/jira/browse/GERONIMO-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai closed GERONIMO-5122. --- Upgrade Tomcat to 6.0.26 Key: GERONIMO-5122 URL: https://issues.apache.org/jira/browse/GERONIMO-5122 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.5, 2.2.1 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.1.5, 2.2.1 Upgrade Tomcat to version 6.0.26 1) Pull in the source code into geronimo external directory 2) Commit necessary patches for geronimo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
