Re: admin console and prompting
I checked the codes of ConfirmMessageTag, its main purpose is to import Dojo js file and some styles for showing Dojo box. 1. When dojo is not installed, I do not think the confirm box could work. For the showConfirmMessage function uses some Dojo components. 2. The name seems not conformable with its function. I agree that we should change it to be more valid. Ivan 2009/6/30 Jarek Gawor jga...@gmail.com Hi, While debugging the console testsuites I realized that the admin console was no longer prompting when uninstalling a given module (or stopping or restarting). I tracked down the problem to ConfirmMessageTag.java where it was pointing to wrong locations for Dojo resources. Now, I have a few of questions about this ConfirmMessageTag that I'm hoping somebody will be able to answer: 1) Is it necessary for ConfirmMessageTag to use Dojo? Or at least can we make it so that it still works (displays prompts) when Dojo is not installed? 2) The ConfirmMessageTag injects a style/ element into the page body (within body/). But from what I can tell (and I checked this with jslint) the style/ elements only should appear within the head/ element. Things seems to work the way they are now but I'm wondering if we should change this to be more valid. Jarek -- Ivan
[jira] Updated: (GERONIMODEVTOOLS-581) GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai updated GERONIMODEVTOOLS-581: --- Attachment: 581_missingfile.patch Hi, I can reproduce Donald's problem on Suse Linux 10. After investigation, I found the reason for missing Messages.properties is the targetPath value in pom.xml. The value is /org/apache/geronimo/st/v20/ui/internal, which seems a absolute path. On Suse Linux and Mac, the path can't be found, as a result, the file is missing. But it works on Windows and Ubuntu. So the solution is to remove the first / to make it a relative path. Attached 581_missingfile.patch for this. BTW, interestingly, the targetPath in other plugins are all relative path, we only need to change the pom.xml in plugin org.apache.geronimo.st.ui. Thanks! GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo - Key: GERONIMODEVTOOLS-581 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.2.0 Attachments: 581.patch, 581_missingfile.patch, 581new.patch, gep-trunk-788843.wep22.patch GEP 2.2 can't be installed on WTP 3.1, which is used by Eclipse 3.5 ,Galileo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-581) GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12725497#action_12725497 ] Delos Dai commented on GERONIMODEVTOOLS-581: Johannes, Can you take a look at GERONIMODEVTOOLS-575? Is the patch there you want ? Tim, Johannes attached a patch related to the JIRA 575, could you help to review it when you review the patch for JIRA 575? His patch is gep-trunk-788843.wep22.patch. Thanks! GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo - Key: GERONIMODEVTOOLS-581 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.2.0 Attachments: 581.patch, 581_missingfile.patch, 581new.patch, gep-trunk-788843.wep22.patch GEP 2.2 can't be installed on WTP 3.1, which is used by Eclipse 3.5 ,Galileo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem when deploy CXF WebService (Service resource injection failed)
Collect the usage of org.apache.geronimo.jaxws.builder.useSimpleFinder as followed into (1): org.apache.geronimo.jaxws.builder.useSimpleFinder Applied commands: TODO Option: true, false Default: not set Description: Use SimpleWARWebServiceFinder to locate WebServiceInfo objects,otherwise use AdvancedWARWebServiceFinder. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Command+Geronimo+Options Anything incorrect, please let me know. Jeff C Jarek Gawor-2 wrote: If you are deploying a web application that contains its own CXF and Spring jars, try doing the following: 1) Set the following system property before starting the server: export GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true 2) Add the following hidden-classes/filters to geronimo-web.xml file: dep:hidden-classes dep:filterorg.apache.cxf/dep:filter dep:filterorg.springframework/dep:filter dep:filterMETA-INF/spring/dep:filter /dep:hidden-classes However, if your web service is just a standard JAX-WS web service you can let Geronimo to deploy it. Just remove all CXF and Spring jars from your application and deploy it and Geronimo should be able to find your web service class. Jarek On Mon, Jun 29, 2009 at 5:22 AM, Westhvegwesthstud...@gmail.com wrote: More details about the exception: Caused by: org.apache.xbean.recipe.MissingFactoryMethodException: Constructor has 5 arugments but expected 0 arguments: public org.apache.cxf.js.rhino.DOMMessageProvider(org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.String,boolean,boolean) at org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:546) at org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:532) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:270) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:173) at org.apache.geronimo.jaxws.annotations.AnnotationHolder.newInstance(AnnotationHolder.java:39) at org.apache.geronimo.cxf.pojo.POJOEndpoint.init(POJOEndpoint.java:76) ... 75 more -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24250919.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24260402.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-4216) Examine setters methods in connector builder
[ https://issues.apache.org/jira/browse/GERONIMO-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4216: --- Attachment: GERONIMO-4216-b21-updated.patch Use the updated patch to eliminate using the switchCase, this can make the the code logic more readable. However, we still should always decapitalize the property name first in this builder. -Rex Examine setters methods in connector builder Key: GERONIMO-4216 URL: https://issues.apache.org/jira/browse/GERONIMO-4216 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Rex Wang Attachments: GERONIMO-4216-b21-updated.patch Currently, the connector builder uses the getter methods to figure out the types for the attributes for the dynamic gbeans created for the various connector classes. The connector builder should use the setter methods instead (for example, in cases where there is a write-only property, i.e. setter method is present but getter is not). This is related to [GERONIMO-4131]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4216) Examine setters methods in connector builder
[ https://issues.apache.org/jira/browse/GERONIMO-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4216: --- Attachment: (was: GERONIMO-4216-b21.patch) Examine setters methods in connector builder Key: GERONIMO-4216 URL: https://issues.apache.org/jira/browse/GERONIMO-4216 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Rex Wang Attachments: GERONIMO-4216-b21-updated.patch Currently, the connector builder uses the getter methods to figure out the types for the attributes for the dynamic gbeans created for the various connector classes. The connector builder should use the setter methods instead (for example, in cases where there is a write-only property, i.e. setter method is present but getter is not). This is related to [GERONIMO-4131]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Geronimo] - Build Error
Hi Rahul.soa,
Could you let me know how you bypass the error, your tips might be
contributed to our doc.
Thanks in advance.
Jeff C
On Sat, Jun 27, 2009 at 1:15 AM, rahul.soa rahul@googlemail.com wrote:
Hello all,
You can ignore this email as I built a new server.
Thanks.
Best Regards,
Rahul
On Fri, Jun 26, 2009 at 1:05 AM, rahul.soa rahul@googlemail.comwrote:
Hello Devs,
While building the Geronimo from the scratch, I have got the build error
due to the following error
Embedded error: org.apache.geronimo.gbean.GBeanInfoFactoryException: *
Cannot create a GBeanInfo for*
[org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
*
Full trace:*
[INFO]
[INFO] Building Geronimo Plugins, OpenEJB :: Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [remote-resources:process {execution: default}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [dependency:unpack {execution: default}]
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.org
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.nexus.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/rahul/server/plugins/openejb/openejb-deployer/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
[ERROR] Deployment failed due to
org.apache.geronimo.gbean.GBeanInfoFactoryException: Cannot create a
GBeanInfo for [org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
org.apache.geronimo.gbean.MultiGBeanInfoFactory.getGBeanInfo(MultiGBeanInfoFactory.java:64)
org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:112)
org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:107)
org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:46)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:240)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
sun.reflect.GeneratedMethodAccessor145.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309)
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:209)
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
Re: [Geronimo] - Build Error
Hello Jeff,
I did *build new trunk* as I had an old one and was getting a few different
errors too. Thus, did nothing to bypass that particular error.
Thanks.
Rahul
On Tue, Jun 30, 2009 at 9:48 AM, chi runhua chirun...@gmail.com wrote:
Hi Rahul.soa,
Could you let me know how you bypass the error, your tips might be
contributed to our doc.
Thanks in advance.
Jeff C
On Sat, Jun 27, 2009 at 1:15 AM, rahul.soa rahul@googlemail.comwrote:
Hello all,
You can ignore this email as I built a new server.
Thanks.
Best Regards,
Rahul
On Fri, Jun 26, 2009 at 1:05 AM, rahul.soa rahul@googlemail.comwrote:
Hello Devs,
While building the Geronimo from the scratch, I have got the build error
due to the following error
Embedded error: org.apache.geronimo.gbean.GBeanInfoFactoryException: *
Cannot create a GBeanInfo for*
[org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
*
Full trace:*
[INFO]
[INFO] Building Geronimo Plugins, OpenEJB :: Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [remote-resources:process {execution: default}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [dependency:unpack {execution: default}]
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.org
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.nexus.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/rahul/server/plugins/openejb/openejb-deployer/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
[ERROR] Deployment failed due to
org.apache.geronimo.gbean.GBeanInfoFactoryException: Cannot create a
GBeanInfo for [org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
org.apache.geronimo.gbean.MultiGBeanInfoFactory.getGBeanInfo(MultiGBeanInfoFactory.java:64)
org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:112)
org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:107)
org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:46)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:240)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
sun.reflect.GeneratedMethodAccessor145.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
Re: [Geronimo] - Build Error
Got it. thanks for your prompt reply.
Jeff
On Tue, Jun 30, 2009 at 4:00 PM, rahul.soa rahul@googlemail.com wrote:
Hello Jeff,
I did *build new trunk* as I had an old one and was getting a few different
errors too. Thus, did nothing to bypass that particular error.
Thanks.
Rahul
On Tue, Jun 30, 2009 at 9:48 AM, chi runhua chirun...@gmail.com wrote:
Hi Rahul.soa,
Could you let me know how you bypass the error, your tips might be
contributed to our doc.
Thanks in advance.
Jeff C
On Sat, Jun 27, 2009 at 1:15 AM, rahul.soa rahul@googlemail.comwrote:
Hello all,
You can ignore this email as I built a new server.
Thanks.
Best Regards,
Rahul
On Fri, Jun 26, 2009 at 1:05 AM, rahul.soa rahul@googlemail.comwrote:
Hello Devs,
While building the Geronimo from the scratch, I have got the build error
due to the following error
Embedded error: org.apache.geronimo.gbean.GBeanInfoFactoryException: *
Cannot create a GBeanInfo for*
[org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
*
Full trace:*
[INFO]
[INFO] Building Geronimo Plugins, OpenEJB :: Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [remote-resources:process {execution: default}]
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $
license.name is not a valid reference.
[INFO] [dependency:unpack {execution: default}]
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.org
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache.nexus.snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-openejb-builder:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/rahul/server/plugins/openejb/openejb-deployer/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/rahul/server/plugins/openejb/openejb-deployer/target/resources/META-INF/plan.xml
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
[ERROR] Deployment failed due to
org.apache.geronimo.gbean.GBeanInfoFactoryException: Cannot create a
GBeanInfo for [org.apache.geronimo.openejb.deployment.EjbModuleBuilder]
org.apache.geronimo.gbean.MultiGBeanInfoFactory.getGBeanInfo(MultiGBeanInfoFactory.java:64)
org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:112)
org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:107)
org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:46)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:240)
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
sun.reflect.GeneratedMethodAccessor145.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
Re: [jira] Closed: (GERONIMO-4715) Make tomcat use our thread pools
Hi David, One question here. As I remember, Geronimo has 2 thread pools: * ConnectorThreadPool* is used in J2EE Connector Architecture (JCA), and * DefaultThreadPool* is used by Jetty and System database. Both of them have no connection with Tomcat Web connector prior to this change. What the differences would be for this information? I'd like to update our document(1) accordingly. Thanks in advance. (1). http://cwiki.apache.org/confluence/display/GMOxDOC22/Monitoring+thread+pools Jeff C On Sat, Jun 27, 2009 at 3:55 AM, David Jencks (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/GERONIMO-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] David Jencks closed GERONIMO-4715. -- Resolution: Fixed rev 788834. Make tomcat use our thread pools Key: GERONIMO-4715 URL: https://issues.apache.org/jira/browse/GERONIMO-4715 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 With the server.xml processing it's not very hard to wrap our thread pool in something tomcat likes. -- 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: 789569
Geronimo Revision: 789569 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/build-0300.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 46 minutes 21 seconds
[INFO] Finished at: Tue Jun 30 03:50:26 EDT 2009
[INFO] Final Memory: 433M/972M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-0300-tomcat/
Assembly: jetty
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-0300-jetty/
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty7-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty7-javaee5/2.2-SNAPSHOT/geronimo-jetty7-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:49.496
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:15.155)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:35.344)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:41.019)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:21.908)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:25.111)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:21.494) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:02:10.822)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:52.639)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:56.424)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:47.036)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:34.636)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:34.160)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:36.712)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.063)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:01.477)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:45.900)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:31.991)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests FAILURE (0:00:49.328) Java
returned: 1
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:51.791)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:33.620)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:32.539)
[INFO] web-testsuite/test-jetty RUNNING
[INFO] web-testsuite/test-jetty SUCCESS (0:00:24.734
Re: Problem when deploy CXF WebService (Service resource injection failed)
Hello RunHua Chi, I'm using windows so I edit geronimo.bat (that is executed by eclipse plugin) by this way: set GERONIMO_OPTS=%GERONIMO_OPTS% %JPDA_OPTS% to set GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true Thanks, Westhveg RunHua Chi wrote: Collect the usage of org.apache.geronimo.jaxws.builder.useSimpleFinder as followed into (1): org.apache.geronimo.jaxws.builder.useSimpleFinder Applied commands: TODO Option: true, false Default: not set Description: Use SimpleWARWebServiceFinder to locate WebServiceInfo objects,otherwise use AdvancedWARWebServiceFinder. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Command+Geronimo+Options Anything incorrect, please let me know. Jeff C Jarek Gawor-2 wrote: If you are deploying a web application that contains its own CXF and Spring jars, try doing the following: 1) Set the following system property before starting the server: export GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true 2) Add the following hidden-classes/filters to geronimo-web.xml file: dep:hidden-classes dep:filterorg.apache.cxf/dep:filter dep:filterorg.springframework/dep:filter dep:filterMETA-INF/spring/dep:filter /dep:hidden-classes However, if your web service is just a standard JAX-WS web service you can let Geronimo to deploy it. Just remove all CXF and Spring jars from your application and deploy it and Geronimo should be able to find your web service class. Jarek On Mon, Jun 29, 2009 at 5:22 AM, Westhvegwesthstud...@gmail.com wrote: More details about the exception: Caused by: org.apache.xbean.recipe.MissingFactoryMethodException: Constructor has 5 arugments but expected 0 arguments: public org.apache.cxf.js.rhino.DOMMessageProvider(org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.String,boolean,boolean) at org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:546) at org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:532) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:270) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:173) at org.apache.geronimo.jaxws.annotations.AnnotationHolder.newInstance(AnnotationHolder.java:39) at org.apache.geronimo.cxf.pojo.POJOEndpoint.init(POJOEndpoint.java:76) ... 75 more -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24250919.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24260402.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24268388.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Closed: (GERONIMO-4689) Cleanup code in jetty7 integration
[ https://issues.apache.org/jira/browse/GERONIMO-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4689. -- Resolution: Fixed After rev 785478 (implementation improvements) and 789622 (moving stuff around and renaming) I don't anticipate doing more on this soon. Cleanup code in jetty7 integration -- Key: GERONIMO-4689 URL: https://issues.apache.org/jira/browse/GERONIMO-4689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 - replace the chain of immutable handlers with a more java like template/handler pattern - use annotations for gbeans - move classes to more sensible packages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4645) jetty7 ejb web service authentication is turned off
[ https://issues.apache.org/jira/browse/GERONIMO-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4645. -- Resolution: Fixed Reimplemented the web services security stuff in rev 789622. Generally this uses more of built-in jetty functionality. The security stuff is handled in a SecurityHandler subclass, and the web service is called from a ServletHandler subclass. Also the security checks are done with a WebUserDataPermission object. My guess is that it would be fairly easy to extend this to allow use of jaspi for ejb web services. jetty7 ejb web service authentication is turned off --- Key: GERONIMO-4645 URL: https://issues.apache.org/jira/browse/GERONIMO-4645 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 See JettyContainerImpl.addWebService. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trunk Builds
I've worked on GERONIMO-4645, however I'm getting strange results from running the testsuite. When I look at build.log for a test bit I don't see errors but the console output claims a lot of bits failed. So hopefully your automated tests won't have this problem and we can see how successful I was BTW my new code secures access to the ?wsdl for the web service. This seems like a good idea to me, WDYT? thanks david jencks On Jun 25, 2009, at 8:58 AM, Jarek Gawor wrote: Based on running the testsuite yesterday and with fixes committed last night I *think* we should be passing all tests on Tomcat and fail enterprise-testsuite/sec-tests and webservices-testsuite/jaxws-tests on Jetty. The webservices-testsuite/jaxws-tests fails because of GERONIMO-4645. Not sure what's going on with enterprise-testsuite/sec-tests. Jarek On Thu, Jun 25, 2009 at 11:00 AM, Kevan Millerkevan.mil...@gmail.com wrote: A search of emails shows that our last successful automated build of trunk was on May 26th. I know that there have been increasing frustration with these recent build issues. We seem to be closing in on getting these issues resolved. I built last night. I built successfully, last night, but had 7 testsuite failures -- 3 jetty, 4 tomcat. I think it would do us a lot of good to have a concerted effort to get these final issues resolved. Here are the test failures that I'm seeing: 3 common errors: [INFO] The following tests failed: [INFO] * console-testsuite/advanced - /Users/kevan/geronimo/server/trunk/testsuite/console-testsuite/ advanced/build.log [INFO] * enterprise-testsuite/sec-tests - /Users/kevan/geronimo/server/trunk/testsuite/enterprise-testsuite/ sec-tests/build.log [INFO] * webservices-testsuite/jaxws-tests - /Users/kevan/geronimo/server/trunk/testsuite/webservices-testsuite/ jaxws-tests/build.log 1 Tomcat unique failure: [INFO] * web-testsuite/test-tomcat - /Users/kevan/geronimo/server/trunk/testsuite/web-testsuite/test- tomcat/build.log Is this consistent with what others are seeing? --kevan
[jira] Updated: (GERONIMO-4216) Examine setters methods in connector builder
[ https://issues.apache.org/jira/browse/GERONIMO-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4216: --- Attachment: GERONIMO-4216-b21-updated.patch Examine setters methods in connector builder Key: GERONIMO-4216 URL: https://issues.apache.org/jira/browse/GERONIMO-4216 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Rex Wang Attachments: GERONIMO-4216-b21-updated.patch Currently, the connector builder uses the getter methods to figure out the types for the attributes for the dynamic gbeans created for the various connector classes. The connector builder should use the setter methods instead (for example, in cases where there is a write-only property, i.e. setter method is present but getter is not). This is related to [GERONIMO-4131]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4216) Examine setters methods in connector builder
[ https://issues.apache.org/jira/browse/GERONIMO-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4216: --- Attachment: (was: GERONIMO-4216-b21-updated.patch) Examine setters methods in connector builder Key: GERONIMO-4216 URL: https://issues.apache.org/jira/browse/GERONIMO-4216 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Rex Wang Attachments: GERONIMO-4216-b21-updated.patch Currently, the connector builder uses the getter methods to figure out the types for the attributes for the dynamic gbeans created for the various connector classes. The connector builder should use the setter methods instead (for example, in cases where there is a write-only property, i.e. setter method is present but getter is not). This is related to [GERONIMO-4131]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Session creation triggered by XSS/XSRF filter
I was investigating a problem and happened to notice that our XSS/XSRF filters are triggering the creation of Session objects. I then noticed that they are creating a session when I hit an arbitrary url (I'm expecting a 404). This is plain wrong, IMO. This was on 2.1.4, but I would assume that 2.2 has the same behavior. 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) --kevan
Re: Problem when deploy CXF WebService (Service resource injection failed)
In order to give us more information, I'm following this tutorial: http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html But I don't use the same version for all libraries (I use the highest I found): commons-logging-1.1.jar · geronimo-activation_1.1_spec-1.0-M1.jar -- geronimo-activation_1.1_spec-1.0.2.jar · geronimo-annotation_1.0_spec-1.1.jar -- geronimo-annotation_1.0_spec-1.1.1.jar · geronimo-javamail_1.4_spec-1.0-M1.jar -- geronimo-javamail_1.4_spec-1.3.jar · geronimo-servlet_2.5_spec-1.1-M1.jar -- geronimo-servlet_2.5_spec-1.2.jar · geronimo-ws-metadata_2.0_spec-1.1.1.jar -- geronimo-ws-metadata_2.0_spec-1.1.2.jar jaxb-api-2.0.jar jaxb-impl-2.0.5.jar jaxws-api-2.0.jar · neethi-2.0.jar -- neethi-2.0.4.jar saaj-api-1.3.jar saaj-impl-1.3.jar stax-api-1.0.1.jar · wsdl4j-1.6.1.jar -- wsdl4j-1.6.2.jar · wstx-asl-3.2.1.jar -- wstx-asl-3.2.4.jar · XmlSchema-1.2.jar -- XmlSchema-1.4.2.jar xml-resolver-1.2.jar aopalliance-1.0.jar spring-core-2.0.8.jar -- spring 2.5.6 spring-beans-2.0.8.jar -- spring 2.5.6 spring-context-2.0.8.jar -- spring 2.5.6 spring-web-2.0.8.jar -- spring 2.5.6 cxf-2.1.jar -- cxf-2.0.8.jar - I use cxf-2.0.8.jar because if I use higher (2.2.2), I get a exception (I think Apache Geronimo 2.1.4 is only configured to run with cxf 2.0.8). - Additinally, I inform us that I export ALL of them in the WAR file. - I remmember my environtment: Windows Vista Home (don't kill me, please :P) Java 1.6 Apache Geronimo (Jetty) 2.1.4 Apache CXF 2.0.8 Spring 2.5.6 One thing more: I'm using Geronimo with Jetty because I read that it comes configured for CXF, while Geronimo with Tomcat comes configured for Axis2. Is it correct? Thanks again, Westhveg Westhveg wrote: Hello RunHua Chi, I'm using windows so I edit geronimo.bat (that is executed by eclipse plugin) by this way: set GERONIMO_OPTS=%GERONIMO_OPTS% %JPDA_OPTS% to set GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true Thanks, Westhveg RunHua Chi wrote: Collect the usage of org.apache.geronimo.jaxws.builder.useSimpleFinder as followed into (1): org.apache.geronimo.jaxws.builder.useSimpleFinder Applied commands: TODO Option: true, false Default: not set Description: Use SimpleWARWebServiceFinder to locate WebServiceInfo objects,otherwise use AdvancedWARWebServiceFinder. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Command+Geronimo+Options Anything incorrect, please let me know. Jeff C Jarek Gawor-2 wrote: If you are deploying a web application that contains its own CXF and Spring jars, try doing the following: 1) Set the following system property before starting the server: export GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true 2) Add the following hidden-classes/filters to geronimo-web.xml file: dep:hidden-classes dep:filterorg.apache.cxf/dep:filter dep:filterorg.springframework/dep:filter dep:filterMETA-INF/spring/dep:filter /dep:hidden-classes However, if your web service is just a standard JAX-WS web service you can let Geronimo to deploy it. Just remove all CXF and Spring jars from your application and deploy it and Geronimo should be able to find your web service class. Jarek On Mon, Jun 29, 2009 at 5:22 AM, Westhvegwesthstud...@gmail.com wrote: More details about the exception: Caused by: org.apache.xbean.recipe.MissingFactoryMethodException: Constructor has 5 arugments but expected 0 arguments: public org.apache.cxf.js.rhino.DOMMessageProvider(org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.String,boolean,boolean) at org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:546) at org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:532) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:270) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:173) at org.apache.geronimo.jaxws.annotations.AnnotationHolder.newInstance(AnnotationHolder.java:39) at org.apache.geronimo.cxf.pojo.POJOEndpoint.init(POJOEndpoint.java:76) ... 75 more -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24250919.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Problem-when-deploy-CXF-WebService-%28Service-resource-injection-failed%29-tp24245804s134p24260402.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- View this message
Re: Session creation triggered by XSS/XSRF filter
To catch XSS/XSRF attacks, the code is run as the first item in the filter chain before the web app's servlet is ever reached. The session has to be created before the request gets to the webapp, so we can register the session id and a unique value before a response is created to protect against the XSRF attacks. Not sure why you are seeing a session get created for a non-existent URI, given the filter is registered in the web.xml and should have the same mappings applied to it. But, for the console, anything under the root context is accepted, as there could be any number of portlets registered (is this your scenario?) If so, I don't know if there is an easy way to change this behavior without major changes to how we use Pluto (like integrating the protection into Pluto) and we would still need the filter for the stand-alone webapps -Donald Kevan Miller wrote: I was investigating a problem and happened to notice that our XSS/XSRF filters are triggering the creation of Session objects. I then noticed that they are creating a session when I hit an arbitrary url (I'm expecting a 404). This is plain wrong, IMO. This was on 2.1.4, but I would assume that 2.2 has the same behavior. 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) --kevan
[BUILD] branches/2.0: Failed for Revision: 789483
Geronimo Revision: 789483 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090630/build-2000.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/2.0/20090630/unit-test-reports Downloading: http://download.java.net/maven/1//xml-apis/jars/xml-apis-1.3.03.jar Downloading: http://people.apache.org/repo/m2-incubating-repository//xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar Downloading: http://repo.exist.com/maven2/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar 190K downloaded Downloading: file:///home/geronimo/geronimo/2.0/repository//org/apache/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.jar Downloading: http://download.java.net/maven/1//org.apache.axis/jars/axis-jaxrpc-1.4.jar Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.jar Downloading: http://repo1.maven.org/maven2/org/apache/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.jar 30K downloaded Downloading: file:///home/geronimo/geronimo/2.0/repository//org/apache/activemq/activemq-core/4.1.2-G647819/activemq-core-4.1.2-G647819.jar 1607K downloaded Downloading: file:///home/geronimo/geronimo/2.0/repository//org/apache/tomcat/jasper-el/6.0.18-G678601/jasper-el-6.0.18-G678601.jar 99K downloaded Downloading: file:///home/geronimo/geronimo/2.0/repository//xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar Downloading: http://download.java.net/maven/1//xerces/jars/xercesImpl-2.8.1.jar Downloading: http://people.apache.org/repo/m2-incubating-repository//xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar Downloading: http://repo1.maven.org/maven2/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar Full thread dump Java HotSpot(TM) Server VM (1.5.0_18-b02 mixed mode): Low Memory Detector daemon prio=1 tid=0x60da77f0 nid=0x61e8 runnable [0x..0x] CompilerThread1 daemon prio=1 tid=0x60da6410 nid=0x61e7 waiting on condition [0x..0x609f8248] CompilerThread0 daemon prio=1 tid=0x60da5490 nid=0x61e6 waiting on condition [0x..0x60a792c8] AdapterThread daemon prio=1 tid=0x60da44e0 nid=0x61e5 waiting on condition [0x..0x] Signal Dispatcher daemon prio=1 tid=0x60da36e0 nid=0x61e4 waiting on condition [0x..0x] Finalizer daemon prio=1 tid=0x60d9a840 nid=0x61e3 in Object.wait() [0x60bfc000..0x60bfce20] at java.lang.Object.wait(Native Method) - waiting on 0x7167bfd0 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120) - locked 0x7167bfd0 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x60d9a310 nid=0x61e2 in Object.wait() [0x60c7d000..0x60c7dea0] at java.lang.Object.wait(Native Method) - waiting on 0x715e29d0 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0x715e29d0 (a java.lang.ref.Reference$Lock) main prio=1 tid=0x0805cc08 nid=0x61d8 runnable [0xbfffc000..0xbfffd8f8] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0xab001a40 (a java.io.BufferedInputStream) at sun.net.www.MeteredStream.read(MeteredStream.java:116) - locked 0xab0041d0 (a sun.net.www.http.KeepAliveStream) at java.io.FilterInputStream.read(FilterInputStream.java:111) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2254) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:329) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:199) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:182) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:80) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:462) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:347) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:302) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java
Re: Session creation triggered by XSS/XSRF filter
I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. Joe Donald Woods wrote: To catch XSS/XSRF attacks, the code is run as the first item in the filter chain before the web app's servlet is ever reached. The session has to be created before the request gets to the webapp, so we can register the session id and a unique value before a response is created to protect against the XSRF attacks. Not sure why you are seeing a session get created for a non-existent URI, given the filter is registered in the web.xml and should have the same mappings applied to it. But, for the console, anything under the root context is accepted, as there could be any number of portlets registered (is this your scenario?) If so, I don't know if there is an easy way to change this behavior without major changes to how we use Pluto (like integrating the protection into Pluto) and we would still need the filter for the stand-alone webapps -Donald Kevan Miller wrote: I was investigating a problem and happened to notice that our XSS/XSRF filters are triggering the creation of Session objects. I then noticed that they are creating a session when I hit an arbitrary url (I'm expecting a 404). This is plain wrong, IMO. This was on 2.1.4, but I would assume that 2.2 has the same behavior. 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) --kevan
[jira] Resolved: (GERONIMODEVTOOLS-581) GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMODEVTOOLS-581. --- Resolution: Fixed Fix Version/s: 2.1.5 Patch for missing NLS messages applied. Thanks Delos for all the patches. GEP 2.2 can't be installed on WTP 3.1 used by Eclipse 3.5 Galileo - Key: GERONIMODEVTOOLS-581 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-581 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.1.5, 2.2.0 Attachments: 581.patch, 581_missingfile.patch, 581new.patch, gep-trunk-788843.wep22.patch GEP 2.2 can't be installed on WTP 3.1, which is used by Eclipse 3.5 ,Galileo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trunk Builds
David, Some errors on the console (or in the logs) are to be expected. The tests check if for example the service that requires security can be accessed without security. That should generate some errors and that's what the test expects. As to securing ?wsdl access, a while ago I added a feature where the user can specify which http methods should be secured or not. This was supposed to work just like for servlet-based web services. We got a few queries about this feature and I think we should continue to support it. In fact, I'm not sure how jaxws-ejb-sec tests would pass without it. Jarek On Tue, Jun 30, 2009 at 5:04 AM, David Jencksdavid_jen...@yahoo.com wrote: I've worked on GERONIMO-4645, however I'm getting strange results from running the testsuite. When I look at build.log for a test bit I don't see errors but the console output claims a lot of bits failed. So hopefully your automated tests won't have this problem and we can see how successful I was BTW my new code secures access to the ?wsdl for the web service. This seems like a good idea to me, WDYT? thanks david jencks On Jun 25, 2009, at 8:58 AM, Jarek Gawor wrote: Based on running the testsuite yesterday and with fixes committed last night I *think* we should be passing all tests on Tomcat and fail enterprise-testsuite/sec-tests and webservices-testsuite/jaxws-tests on Jetty. The webservices-testsuite/jaxws-tests fails because of GERONIMO-4645. Not sure what's going on with enterprise-testsuite/sec-tests. Jarek On Thu, Jun 25, 2009 at 11:00 AM, Kevan Millerkevan.mil...@gmail.com wrote: A search of emails shows that our last successful automated build of trunk was on May 26th. I know that there have been increasing frustration with these recent build issues. We seem to be closing in on getting these issues resolved. I built last night. I built successfully, last night, but had 7 testsuite failures -- 3 jetty, 4 tomcat. I think it would do us a lot of good to have a concerted effort to get these final issues resolved. Here are the test failures that I'm seeing: 3 common errors: [INFO] The following tests failed: [INFO] * console-testsuite/advanced - /Users/kevan/geronimo/server/trunk/testsuite/console-testsuite/advanced/build.log [INFO] * enterprise-testsuite/sec-tests - /Users/kevan/geronimo/server/trunk/testsuite/enterprise-testsuite/sec-tests/build.log [INFO] * webservices-testsuite/jaxws-tests - /Users/kevan/geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/build.log 1 Tomcat unique failure: [INFO] * web-testsuite/test-tomcat - /Users/kevan/geronimo/server/trunk/testsuite/web-testsuite/test-tomcat/build.log Is this consistent with what others are seeing? --kevan
Re: Session creation triggered by XSS/XSRF filter
On Jun 30, 2009, at 10:09 AM, Donald Woods wrote: To catch XSS/XSRF attacks, the code is run as the first item in the filter chain before the web app's servlet is ever reached. The session has to be created before the request gets to the webapp, so we can register the session id and a unique value before a response is created to protect against the XSRF attacks. Right. I don't have a problem with this... Not sure why you are seeing a session get created for a non-existent URI, given the filter is registered in the web.xml and should have the same mappings applied to it. But, for the console, anything under the root context is accepted, as there could be any number of portlets registered (is this your scenario?) If so, I don't know if there is an easy way to change this behavior without major changes to how we use Pluto (like integrating the protection into Pluto) and we would still need the filter for the stand-alone webapps I don't know why we're creating a session either. But we're definitely running the XSSXSRFFilter for the following url -- localhost:8080/ nonexistenturl Anybody interested in taking a look at this? --kevan
[BUILD] trunk: Failed for Revision: 789690
Geronimo Revision: 789690 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 46 minutes 28 seconds
[INFO] Finished at: Tue Jun 30 09:50:49 EDT 2009
[INFO] Final Memory: 403M/994M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-0900-tomcat/
Assembly: jetty
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-0900-jetty/
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty7-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty7-javaee5/2.2-SNAPSHOT/geronimo-jetty7-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:49.593
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:16.072)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:35.918)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:39.741)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:20.781)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:24.487)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:21.651) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:02:11.874)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:54.391)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:53.418)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:47.434)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:33.813)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:35.015)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:36.980)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.400)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:00.777)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:46.038)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:30.878)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests FAILURE (0:00:48.947) Java
returned: 1
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:52.031)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:33.797)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:32.172)
[INFO] web-testsuite/test-jetty RUNNING
[INFO] web-testsuite/test-jetty SUCCESS (0:00:24.621
Re: Session creation triggered by XSS/XSRF filter
On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote: I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. OK, that would explain it... So, is there any reason to run XSS filtering on the welcome app? --kevan
[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: --- Attachment: GERONIMO-4628-b21-updated.patch Thanks very much, David! That is a good way to solve this, here is the updated patch. -Rex Console plan wizards need to save plans --- Key: GERONIMO-4628 URL: https://issues.apache.org/jira/browse/GERONIMO-4628 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: David Jencks Assignee: Rex Wang Fix For: 2.1.5, 2.2 Attachments: 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] Commented: (GERONIMO-4628) Console plan wizards need to save plans
[ https://issues.apache.org/jira/browse/GERONIMO-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12725666#action_12725666 ] Rex Wang commented on GERONIMO-4628: and I will make a trunk patch later if this patch has np~ thanks. Console plan wizards need to save plans --- Key: GERONIMO-4628 URL: https://issues.apache.org/jira/browse/GERONIMO-4628 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: David Jencks Assignee: Rex Wang Fix For: 2.1.5, 2.2 Attachments: 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.
Re: javax.ws.xml.Holder not serializable
Thanks for going to test this Jarek. It sounds like I would need to being this up with JCP-224 then. --Kurt Jarek Gawor wrote: Kurt, I'm pretty sure that's what the spec mandates. I can test this out to see if it breaks the TCK signature tests but even if it doesn't you might still run into that problem on Java 6 or later since the javax.xml.ws API are now provided by the JVM. However, I think you could override these JVM API by placing the Geronimo spec jar into the JVM's lib/endorsed directory. I'll test this out and let you know. Jarek On Mon, Jun 29, 2009 at 7:56 PM, Kurt T Stamkurt.s...@gmail.com wrote: Hi guys, On the jUDDI project one of our APIs uses the javax.ws.xml.Holder class (which contains jUDDI specific data classes). We have a requirement to send the entire Holder class over RMI, but Holder is not Serializable. I think this is a short coming of the implementation. http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxws_2.2_spec/src/main/java/javax/xml/ws/Holder.java If you agree can this be fixed? Or do you believe that the spec dictates this? Thx, --Kurt kstam at apache.org
Re: javax.ws.xml.Holder not serializable
Thanks Jarek, I'll take it up the JCP. --Kurt Jarek Gawor wrote: Kurt, The signature tests fail with this change so we can't add Serializable to the Holder class. Jarek On Tue, Jun 30, 2009 at 12:00 AM, Jarek Gaworjga...@gmail.com wrote: Kurt, I'm pretty sure that's what the spec mandates. I can test this out to see if it breaks the TCK signature tests but even if it doesn't you might still run into that problem on Java 6 or later since the javax.xml.ws API are now provided by the JVM. However, I think you could override these JVM API by placing the Geronimo spec jar into the JVM's lib/endorsed directory. I'll test this out and let you know. Jarek On Mon, Jun 29, 2009 at 7:56 PM, Kurt T Stamkurt.s...@gmail.com wrote: Hi guys, On the jUDDI project one of our APIs uses the javax.ws.xml.Holder class (which contains jUDDI specific data classes). We have a requirement to send the entire Holder class over RMI, but Holder is not Serializable. I think this is a short coming of the implementation. http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxws_2.2_spec/src/main/java/javax/xml/ws/Holder.java If you agree can this be fixed? Or do you believe that the spec dictates this? Thx, --Kurt kstam at apache.org
Re: javax.ws.xml.Holder not serializable
On Tue June 30 2009 11:38:35 am Kurt T Stam wrote: Thanks for going to test this Jarek. It sounds like I would need to being this up with JCP-224 then. I'm pretty sure you won't like the answer. :-) Basically, the jcp224/jaxws folks (and the jaxb folks), at one point long ago, specifically decided against making things Serializable since the Serializable symantics are not honored by the XML serialization. (example: field marks transient would still be written to XML) Anyway, for the most part, it was a conscious decision. While that decision may or may not apply to the Holder objects, it wouldn't surprise me at all if they say something along those lines. In anycase, it's definitely not something that would change for JAX-WS 2.0/2.1/2.2 so you would be looking at something at LEAST a year away, probably more, which probably doesn't help you now. Dan --Kurt Jarek Gawor wrote: Kurt, I'm pretty sure that's what the spec mandates. I can test this out to see if it breaks the TCK signature tests but even if it doesn't you might still run into that problem on Java 6 or later since the javax.xml.ws API are now provided by the JVM. However, I think you could override these JVM API by placing the Geronimo spec jar into the JVM's lib/endorsed directory. I'll test this out and let you know. Jarek On Mon, Jun 29, 2009 at 7:56 PM, Kurt T Stamkurt.s...@gmail.com wrote: Hi guys, On the jUDDI project one of our APIs uses the javax.ws.xml.Holder class (which contains jUDDI specific data classes). We have a requirement to send the entire Holder class over RMI, but Holder is not Serializable. I think this is a short coming of the implementation. http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxws_2.2_ spec/src/main/java/javax/xml/ws/Holder.java If you agree can this be fixed? Or do you believe that the spec dictates this? Thx, --Kurt kstam at apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Session creation triggered by XSS/XSRF filter
Kevan Miller wrote: On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote: I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. OK, that would explain it... So, is there any reason to run XSS filtering on the welcome app? I'm not sure if there is a strong reason to have the filter applied to the welcome application. I have this vague recollection of somebody raising an issue earlier ... but I can't find any reference and after a quick glance I don't see any obvious exposures. It primarily includes links into our wiki documentation along with a few other links (such as to the console and to subscribe to the mailing lists). Perhaps the mail subscription links might present an exposure? Or perhaps on the IRC link? Does anybody have an idea if this is really necessary? It seems like overkill to me. Joe
Re: javax.ws.xml.Holder not serializable
Thx for the backgroud info Dan :( Isn't it great, the also decided to make the class 'final'? So I can't even make a wrapper. I've send a request to jsr-224-pub...@jcp.org. Hoping for the best.. --Kurt Daniel Kulp wrote: On Tue June 30 2009 11:38:35 am Kurt T Stam wrote: Thanks for going to test this Jarek. It sounds like I would need to being this up with JCP-224 then. I'm pretty sure you won't like the answer. :-) Basically, the jcp224/jaxws folks (and the jaxb folks), at one point long ago, specifically decided against making things Serializable since the Serializable symantics are not honored by the XML serialization. (example: field marks transient would still be written to XML) Anyway, for the most part, it was a conscious decision. While that decision may or may not apply to the Holder objects, it wouldn't surprise me at all if they say something along those lines. In anycase, it's definitely not something that would change for JAX-WS 2.0/2.1/2.2 so you would be looking at something at LEAST a year away, probably more, which probably doesn't help you now. Dan --Kurt Jarek Gawor wrote: Kurt, I'm pretty sure that's what the spec mandates. I can test this out to see if it breaks the TCK signature tests but even if it doesn't you might still run into that problem on Java 6 or later since the javax.xml.ws API are now provided by the JVM. However, I think you could override these JVM API by placing the Geronimo spec jar into the JVM's lib/endorsed directory. I'll test this out and let you know. Jarek On Mon, Jun 29, 2009 at 7:56 PM, Kurt T Stamkurt.s...@gmail.com wrote: Hi guys, On the jUDDI project one of our APIs uses the javax.ws.xml.Holder class (which contains jUDDI specific data classes). We have a requirement to send the entire Holder class over RMI, but Holder is not Serializable. I think this is a short coming of the implementation. http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxws_2.2_ spec/src/main/java/javax/xml/ws/Holder.java If you agree can this be fixed? Or do you believe that the spec dictates this? Thx, --Kurt kstam at apache.org
Re: Session creation triggered by XSS/XSRF filter
IMO, I don't think the welcome page need this filter. The filter only deal with the links that have the request parameters and the form request, but in the welcome page, there is no such links, so the filter won't take any effects. The reason why add the filtering to welcome project, as the G-4597 indicated, seems just want to comply with some sort of security standards.. so add this filter to all of our web projects(welcome, console), just my guess.. -Rex 2009/7/1 Joe Bohn joe.b...@earthlink.net Kevan Miller wrote: On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote: I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. OK, that would explain it... So, is there any reason to run XSS filtering on the welcome app? I'm not sure if there is a strong reason to have the filter applied to the welcome application. I have this vague recollection of somebody raising an issue earlier ... but I can't find any reference and after a quick glance I don't see any obvious exposures. It primarily includes links into our wiki documentation along with a few other links (such as to the console and to subscribe to the mailing lists). Perhaps the mail subscription links might present an exposure? Or perhaps on the IRC link? Does anybody have an idea if this is really necessary? It seems like overkill to me. Joe
Re: Session creation triggered by XSS/XSRF filter
Probably can be removed, since we no longer allow users to install Sample plugins from the welcome page. As long as the Login page and everything behind it is protected, we should be okay. -Donald Joe Bohn wrote: Kevan Miller wrote: On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote: I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. OK, that would explain it... So, is there any reason to run XSS filtering on the welcome app? I'm not sure if there is a strong reason to have the filter applied to the welcome application. I have this vague recollection of somebody raising an issue earlier ... but I can't find any reference and after a quick glance I don't see any obvious exposures. It primarily includes links into our wiki documentation along with a few other links (such as to the console and to subscribe to the mailing lists). Perhaps the mail subscription links might present an exposure? Or perhaps on the IRC link? Does anybody have an idea if this is really necessary? It seems like overkill to me. Joe
Re: Session creation triggered by XSS/XSRF filter
Thanks for the input Donald and Rex. So it sounds like we all agree that we should remove the filter from welcome. Kevan, Did you want to remove this or would you like me to make the change? Did you already create a JIRA for this? Thanks, Joe Donald Woods wrote: Probably can be removed, since we no longer allow users to install Sample plugins from the welcome page. As long as the Login page and everything behind it is protected, we should be okay. -Donald Joe Bohn wrote: Kevan Miller wrote: On Jun 30, 2009, at 10:26 AM, Joe Bohn wrote: I tried some random URIs and always received a 404 back in my tests. This could be a problem with the filter on the welcome application. It currently has a context-root of / and the filter is registered with a URL pattern of /*. OK, that would explain it... So, is there any reason to run XSS filtering on the welcome app? I'm not sure if there is a strong reason to have the filter applied to the welcome application. I have this vague recollection of somebody raising an issue earlier ... but I can't find any reference and after a quick glance I don't see any obvious exposures. It primarily includes links into our wiki documentation along with a few other links (such as to the console and to subscribe to the mailing lists). Perhaps the mail subscription links might present an exposure? Or perhaps on the IRC link? Does anybody have an idea if this is really necessary? It seems like overkill to me. Joe
Re: Problem when deploy CXF WebService (Service resource injection failed)
You might also want to add: dep:filterMETA-INF/cxf/dep:filter I don't know where org.xmlsoap.schemas.wsdl.http.AddressType comes from but you could try adding a filter for its package as well. Jarek On Mon, Jun 29, 2009 at 3:08 PM, Westhvegwesthstud...@gmail.com wrote: Jarek, Thanks for your reply. Setting the system property and adding hidden-classes in geronimo-web.xml file I get the following exception: Install New Applications start of default/ViewControllerWS/1.0/car failed org.apache.geronimo.kernel.config.LifecycleException: start of default/ViewControllerWS/1.0/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:580) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:544) 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$4b6d99b8.startConfiguration(generated) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start exception at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:522) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563) ... 14 more Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration default/ViewControllerWS/1.0/car failed to start due to the following reasons: The service J2EEApplication=null,WebModule=default/ViewControllerWS/1.0/car,j2eeType=Servlet,name=CXFServlet did not start because javax.servlet.ServletException: javax.servlet.ServletException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: class org.xmlsoap.schemas.wsdl.http.AddressType at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:485) ... 16 more Could you help me, please? Thanks, Westhveg Jarek Gawor-2 wrote: If you are deploying a web application that contains its own CXF and Spring jars, try doing the following: 1) Set the following system property before starting the server: export GERONIMO_OPTS=-Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true 2) Add the following hidden-classes/filters to geronimo-web.xml file: dep:hidden-classes dep:filterorg.apache.cxf/dep:filter dep:filterorg.springframework/dep:filter dep:filterMETA-INF/spring/dep:filter /dep:hidden-classes However, if your web service is just a standard JAX-WS web service you can let Geronimo to deploy it. Just remove all CXF and Spring jars from your application and deploy it and Geronimo should be able to find your web service class. Jarek On Mon, Jun 29, 2009 at 5:22 AM, Westhvegwesthstud...@gmail.com wrote: More details about the exception: Caused by: org.apache.xbean.recipe.MissingFactoryMethodException: Constructor has 5 arugments but expected 0 arguments: public org.apache.cxf.js.rhino.DOMMessageProvider(org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.String,boolean,boolean) at org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:546) at org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:532) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:270) at
[jira] Created: (GERONIMO-4722) XSS/XSRF filters are triggering Session object creation for unknown URLs
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 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.
Re: Problem when deploy CXF WebService (Service resource injection failed)
You have to remove both, CXF and Spring. And please include a full stack trace to see what's loading that org.springframework.context.ApplicationListener class. Jarek On Mon, Jun 29, 2009 at 3:56 PM, Westhvegwesthstud...@gmail.com wrote: And if I remove the spring or cfx jar files from WAR, I get a ClassNotFoundException. For example, if I remove spring jar file: Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationListener in classloader default/ViewControllerWS/1.0/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:438) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:280) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) ... 60 more Could you help me, please? Thanks, Westhveg
Re: Session creation triggered by XSS/XSRF filter
On Jun 30, 2009, at 1:06 PM, Joe Bohn wrote: Thanks for the input Donald and Rex. So it sounds like we all agree that we should remove the filter from welcome. Kevan, Did you want to remove this or would you like me to make the change? Did you already create a JIRA for this? Just created https://issues.apache.org/jira/browse/GERONIMO-4722 Would be great if you could fix... Thanks! --kevan
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12725723#action_12725723 ] Joe Bohn commented on GERONIMO-4722: It appears that we were too aggressive in the application of the XSSXSRFFilter. There is no strong reason that this should be applied to the welcome application which has a context-root of /'. Combine that with the filter URL pattern of /* registered for the filter on the welcome application and nearly every url is inspected. It seems we can remove this filter from welcome. Refer to this thread for more details: http://www.nabble.com/Session-creation-triggered-by-XSS-XSRF-filter-to24272007s134.html 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] Assigned: (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 ] Joe Bohn reassigned GERONIMO-4722: -- Assignee: Joe Bohn 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.
Re: Problem when deploy CXF WebService (Service resource injection failed)
Hi Jarek, Removing both jars, the exception is: Distribution of module failed. See log for details. Failed to load servlet class org.apache.cxf.transport.servlet.CXFServlet org.apache.geronimo.common.DeploymentException: Failed to load servlet class org.apache.cxf.transport.servlet.CXFServlet at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.getPortInfo(AdvancedWARWebServiceFinder.java:148) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverPOJOWebServices(AdvancedWARWebServiceFinder.java:125) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverWebServices(AdvancedWARWebServiceFinder.java:45) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:70) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.discoverWebServices(JAXWSServiceBuilder.java:97) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.findWebServices(JAXWSServiceBuilder.java:80) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:364) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.initContext(JettyModuleBuilder.java:350) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:255) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: org.apache.cxf.transport.servlet.CXFServlet in classloader default/ViewControllerWS/1.0/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:438) at
Re: Problem when deploy CXF WebService (Service resource injection failed)
Jarek, Adding this filter: dep:filterMETA-INF/cxf/dep:filter I get the same exception, but if I add a filter for package: dep:filterorg.xmlsoap.schemas.wsdl.http/dep:filter Then I get the following exception: Redeploy of module failed. See log for details. start of default/ViewControllerWS/1.0/car failed org.apache.geronimo.kernel.config.LifecycleException: start of default/ViewControllerWS/1.0/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:580) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:544) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start exception at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:522) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563) ... 39 more Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration default/ViewControllerWS/1.0/car failed to start due to the following reasons: The service J2EEApplication=null,Servlet=com.test.service.impl.ServiceImpl,WebModule=default/ViewControllerWS/1.0/car,j2eeType=GBean,name=org.apache.geronimo.cxf.pojo.POJOWebServiceContainerFactoryGBean did not start for an unknown reason The service J2EEApplication=null,WebModule=default/ViewControllerWS/1.0/car,j2eeType=Servlet,name=com.test.service.impl.ServiceImpl did not start because default/ViewControllerWS/1.0/car?J2EEApplication=null,Servlet=com.test.service.impl.ServiceImpl,WebModule=default/ViewControllerWS/1.0/car,j2eeType=GBean,name=org.apache.geronimo.cxf.pojo.POJOWebServiceContainerFactoryGBean did not start. The service
Re: Problem when deploy CXF WebService (Service resource injection failed)
Ok, making progress on this front... Remove the CXFServlet from web.xml file and add a servlet (and servlet-mapping) for the class that is your web service implementation. Jarek On Tue, Jun 30, 2009 at 2:18 PM, Westhvegwesthstud...@gmail.com wrote: Hi Jarek, Removing both jars, the exception is: Distribution of module failed. See log for details. Failed to load servlet class org.apache.cxf.transport.servlet.CXFServlet org.apache.geronimo.common.DeploymentException: Failed to load servlet class org.apache.cxf.transport.servlet.CXFServlet at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.getPortInfo(AdvancedWARWebServiceFinder.java:148) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverPOJOWebServices(AdvancedWARWebServiceFinder.java:125) at org.apache.geronimo.jaxws.builder.AdvancedWARWebServiceFinder.discoverWebServices(AdvancedWARWebServiceFinder.java:45) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:70) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.discoverWebServices(JAXWSServiceBuilder.java:97) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.findWebServices(JAXWSServiceBuilder.java:80) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:364) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.initContext(JettyModuleBuilder.java:350) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:255) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException:
Re: Problem when deploy CXF WebService (Service resource injection failed)
Are you sure you're running with -Dorg.apache.geronimo.jaxws.builder.useSimpleFinder=true? Because Geronimo should not be finding and deploying org.apache.cxf.js.rhino.DOMMessageProvider with that option. Or maybe that's from previous deployments? Jarek On Tue, Jun 30, 2009 at 2:26 PM, Westhvegwesthstud...@gmail.com wrote: Jarek, Adding this filter: dep:filterMETA-INF/cxf/dep:filter I get the same exception, but if I add a filter for package: dep:filterorg.xmlsoap.schemas.wsdl.http/dep:filter Then I get the following exception: Redeploy of module failed. See log for details. start of default/ViewControllerWS/1.0/car failed org.apache.geronimo.kernel.config.LifecycleException: start of default/ViewControllerWS/1.0/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:580) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:544) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start exception at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:522) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563) ... 39 more Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration default/ViewControllerWS/1.0/car failed to start due to the following reasons: The service J2EEApplication=null,Servlet=com.test.service.impl.ServiceImpl,WebModule=default/ViewControllerWS/1.0/car,j2eeType=GBean,name=org.apache.geronimo.cxf.pojo.POJOWebServiceContainerFactoryGBean did not start for an unknown reason The service
[jira] Resolved: (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 ] Joe Bohn resolved GERONIMO-4722. Resolution: Fixed I've committed changes in branches/2.1 (rev. 789881) and trunk (rev. 789885). This seems to resolve the problem you observed with session creation. Please validate before closing. 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.
Re: Trunk Builds
On Jun 30, 2009, at 7:35 AM, Jarek Gawor wrote:
David,
Some errors on the console (or in the logs) are to be expected. The
tests check if for example the service that requires security can be
accessed without security. That should generate some errors and that's
what the test expects.
As usual I wasn't too clear...
For instance, if I look at concurrent-testsuite/concurrent-basic/
build.log, I see that the build was successful and
OUT: Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
316.367 sec
OUT: Results :
OUT: Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
OUT: [INFO] [geronimo:undeploy-module {execution: undeploy-war-as-
moduleId}]
OUT: [INFO] Using non-artifact based module id:
org.apache.geronimo.testsuite/concurrent-web-ear/2.2-SNAPSHOT/ear
OUT: Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.933 sec
OUT: Results :
OUT: Tests run: 16, Failures: 0, Errors: 0, Skipped: 0
OUT: [INFO] [geronimo:undeploy-module {execution: undeploy-war-as-
moduleId}]
OUT: [INFO] Using non-artifact based module id:
org.apache.geronimo.testsuite/concurrent-ejb-ear/2.2-SNAPSHOT/ear
however on the console I'm running the tests from I see
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic FAILURE
(0:20:47.746) Java returned: 1
I don't understand why the test runner thinks the tests failed but I
don't see any failures in the build.log
As to securing ?wsdl access, a while ago I added a feature where the
user can specify which http methods should be secured or not. This was
supposed to work just like for servlet-based web services. We got a
few queries about this feature and I think we should continue to
support it. In fact, I'm not sure how jaxws-ejb-sec tests would pass
without it.
I was only really looking at jetty here. Previously ?wsdl requests
were serviced before checking transport type and for jetty the
protected methods were ignored. I've changed it so that all requests
have their security checked and that only the http methods specified
are allowed. (I think this is what the tomcat code is doing also, but
I'm not 100% sure). I think this is what you intended but I find the
parameter name protected methods a little confusing.
Do you think there's any value in allowing specification of excluded
http methods rather than included methods, as the servlet spec allows?
thanks
david jencks
Jarek
On Tue, Jun 30, 2009 at 5:04 AM, David
Jencksdavid_jen...@yahoo.com wrote:
I've worked on GERONIMO-4645, however I'm getting strange results
from
running the testsuite. When I look at build.log for a test bit I
don't see
errors but the console output claims a lot of bits failed.
So hopefully your automated tests won't have this problem and we
can see how
successful I was
BTW my new code secures access to the ?wsdl for the web service.
This seems
like a good idea to me, WDYT?
thanks
david jencks
On Jun 25, 2009, at 8:58 AM, Jarek Gawor wrote:
Based on running the testsuite yesterday and with fixes committed
last
night I *think* we should be passing all tests on Tomcat and fail
enterprise-testsuite/sec-tests and webservices-testsuite/jaxws-tests
on Jetty. The webservices-testsuite/jaxws-tests fails because of
GERONIMO-4645. Not sure what's going on with
enterprise-testsuite/sec-tests.
Jarek
On Thu, Jun 25, 2009 at 11:00 AM, Kevan Millerkevan.mil...@gmail.com
wrote:
A search of emails shows that our last successful automated build
of
trunk
was on May 26th. I know that there have been increasing
frustration with
these recent build issues. We seem to be closing in on getting
these
issues
resolved. I built last night. I built successfully, last night,
but had 7
testsuite failures -- 3 jetty, 4 tomcat.
I think it would do us a lot of good to have a concerted effort
to get
these
final issues resolved. Here are the test failures that I'm seeing:
3 common errors:
[INFO] The following tests failed:
[INFO] * console-testsuite/advanced -
/Users/kevan/geronimo/server/trunk/testsuite/console-testsuite/
advanced/build.log
[INFO] * enterprise-testsuite/sec-tests -
/Users/kevan/geronimo/server/trunk/testsuite/enterprise-testsuite/
sec-tests/build.log
[INFO] * webservices-testsuite/jaxws-tests -
/Users/kevan/geronimo/server/trunk/testsuite/webservices-
testsuite/jaxws-tests/build.log
1 Tomcat unique failure:
[INFO] * web-testsuite/test-tomcat -
/Users/kevan/geronimo/server/trunk/testsuite/web-testsuite/test-
tomcat/build.log
Is this consistent with what others are seeing?
--kevan
[jira] Reopened: (GERONIMO-4645) jetty7 ejb web service authentication is turned off
[ https://issues.apache.org/jira/browse/GERONIMO-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reopened GERONIMO-4645: --- David, This is still not working right. Please run testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb-sec tests (have the server running and just run mvn install from within the jaxws-ejb-sec directory). I had to commit some additional fixes (see revision 789931) just for these tests to deploy ok. jetty7 ejb web service authentication is turned off --- Key: GERONIMO-4645 URL: https://issues.apache.org/jira/browse/GERONIMO-4645 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 See JettyContainerImpl.addWebService. -- 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: 789862
Geronimo Revision: 789862 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 41 minutes 27 seconds
[INFO] Finished at: Tue Jun 30 15:45:45 EDT 2009
[INFO] Final Memory: 404M/1012M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-1500-tomcat/
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:47.029
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:19.881)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:35.788)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:40.283)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:21.166)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:29.778)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:32.365) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:58.981)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:52.682)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:55.784)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:47.688)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:33.885)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:35.409)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:35.683)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:01:21.750)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:59.530)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:53.110)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:30.948)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:54.984)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:49.684)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:32.601)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:31.240)
[INFO] web-testsuite/test-myfaces RUNNING
[INFO] web
Re: Problem when deploy CXF WebService (Service resource injection failed)
Jarek, Now the exception is: Distribution of module failed. See log for details. AbstractWebModuleBuilder: Could not load listener class: org.springframework.web.context.ContextLoaderListener org.apache.geronimo.common.DeploymentException: AbstractWebModuleBuilder: Could not load listener class: org.springframework.web.context.ContextLoaderListener at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:791) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:759) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:836) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:365) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:255) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor100.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener in classloader default/TestCXF/1.0/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:438) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:280) at java.lang.ClassLoader.loadClass(Unknown Source) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:789) ... 45 more But if I add spring.jar, then the WAR is published without errors, the CXF webservice is also published and WSDL file is generated correctly. Now my question
Re: Problem when deploy CXF WebService (Service resource injection failed)
And if I try to test the webservice developing this spring client:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;
!--
import resource=classpath:META-INF/cxf/cxf.xml /
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml /
import resource=classpath:META-INF/cxf/cxf-servlet.xml /
--
jaxws:client id=helloWordClient
serviceClass=com.test.HelloWorld
address=http://localhost:8080/helloWorld; /
/beans
30-jun-2009 23:52:33 org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
30-jun-2009 23:52:34
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://test.com/}HelloWorldService from class
com.test.HelloWorld
30-jun-2009 23:52:34 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121)
at $Proxy44.postMessage(Unknown Source)
at com.test.TestWsClient.main(TestWsClient.java:15)
Caused by: java.io.IOException: Not Found
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2015)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1940)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 8 more
Exception in thread main javax.xml.ws.soap.SOAPFaultException: Could not
send Message.
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
at $Proxy44.postMessage(Unknown Source)
at com.test.TestWsClient.main(TestWsClient.java:15)
Caused by: java.io.IOException: Not Found
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2015)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1940)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121)
... 2 more
Westhveg wrote:
Jarek,
Now the exception is:
Distribution of module failed. See log for details.
AbstractWebModuleBuilder: Could not load listener class:
org.springframework.web.context.ContextLoaderListener
org.apache.geronimo.common.DeploymentException:
AbstractWebModuleBuilder: Could not load listener class:
org.springframework.web.context.ContextLoaderListener
at
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:791)
at
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:759)
[BUILD] trunk: Failed for Revision: 790005
Geronimo Revision: 790005 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 39 minutes 7 seconds
[INFO] Finished at: Tue Jun 30 21:43:07 EDT 2009
[INFO] Final Memory: 484M/1013M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090630/logs-2100-tomcat/
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:43.132
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:05.712)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:32.909)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:37.680)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:20.945)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:35.800)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:28.037) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:54.844)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:53.261)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:54.889)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:46.583)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:33.569)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:35.256)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:37.478)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:01:09.992)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:02.857)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:52.588)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:28.991)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:52.739)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:52.282)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:33.436)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:32.533)
[INFO] web-testsuite/test-myfaces RUNNING
[INFO] web
Re: admin console and prompting
If Dojo is only used to display a nice box in this case, I think we should just get rid off it and use the regular dialog boxes. Jarek On Tue, Jun 30, 2009 at 2:12 AM, Ivanxhh...@gmail.com wrote: I checked the codes of ConfirmMessageTag, its main purpose is to import Dojo js file and some styles for showing Dojo box. 1. When dojo is not installed, I do not think the confirm box could work. For the showConfirmMessage function uses some Dojo components. 2. The name seems not conformable with its function. I agree that we should change it to be more valid. Ivan 2009/6/30 Jarek Gawor jga...@gmail.com Hi, While debugging the console testsuites I realized that the admin console was no longer prompting when uninstalling a given module (or stopping or restarting). I tracked down the problem to ConfirmMessageTag.java where it was pointing to wrong locations for Dojo resources. Now, I have a few of questions about this ConfirmMessageTag that I'm hoping somebody will be able to answer: 1) Is it necessary for ConfirmMessageTag to use Dojo? Or at least can we make it so that it still works (displays prompts) when Dojo is not installed? 2) The ConfirmMessageTag injects a style/ element into the page body (within body/). But from what I can tell (and I checked this with jslint) the style/ elements only should appear within the head/ element. Things seems to work the way they are now but I'm wondering if we should change this to be more valid. Jarek -- Ivan
Re: admin console and prompting
Yes, the regular dialog boxes are also OK. I remembered that I had discussed it with the patch contributor Jeff, our final result is that since more and more portlets are using Dojo, why not use it :-) I also wish the console would use Dojo to do some validation stuff in the future. Ivan 2009/7/1 Jarek Gawor jga...@gmail.com If Dojo is only used to display a nice box in this case, I think we should just get rid off it and use the regular dialog boxes. Jarek On Tue, Jun 30, 2009 at 2:12 AM, Ivanxhh...@gmail.com wrote: I checked the codes of ConfirmMessageTag, its main purpose is to import Dojo js file and some styles for showing Dojo box. 1. When dojo is not installed, I do not think the confirm box could work. For the showConfirmMessage function uses some Dojo components. 2. The name seems not conformable with its function. I agree that we should change it to be more valid. Ivan 2009/6/30 Jarek Gawor jga...@gmail.com Hi, While debugging the console testsuites I realized that the admin console was no longer prompting when uninstalling a given module (or stopping or restarting). I tracked down the problem to ConfirmMessageTag.java where it was pointing to wrong locations for Dojo resources. Now, I have a few of questions about this ConfirmMessageTag that I'm hoping somebody will be able to answer: 1) Is it necessary for ConfirmMessageTag to use Dojo? Or at least can we make it so that it still works (displays prompts) when Dojo is not installed? 2) The ConfirmMessageTag injects a style/ element into the page body (within body/). But from what I can tell (and I checked this with jslint) the style/ elements only should appear within the head/ element. Things seems to work the way they are now but I'm wondering if we should change this to be more valid. Jarek -- Ivan -- Ivan
[jira] Commented: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource
[
https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12725552#action_12725552
]
Ivan commented on XBEAN-133:
Generally speaking, the jarFile is in the method domain, it should be released
soon. But, if we could explicitly call the close method will be better.
After some investigation, whether or not we could invoke the close method, I
think it depends on. If the usercache is closed and url is recreated to point
to the jarFile (like what is done in the findResource method), each call to
openConnection().getJarFile() will return a different JarFile object , which
means that calling the close method would not affect others who uses the same
Jar file.
So, shall we change the patch to something like
if (jarfile != null !conn.getUseCaches())
try {
jarfile.close();
} catch (Exception e) {
}
Not sure whether I made a mistaken, thanks for any comment !
Jar file is not close after open resulting in files delete failure when
finding resource
Key: XBEAN-133
URL: https://issues.apache.org/jira/browse/XBEAN-133
Project: XBean
Issue Type: Bug
Components: finder
Environment: os:win2003
Reporter: viola.lu
Assignee: David Blevins
Priority: Minor
Attachments: XBEAN-133.patch
1.Deploy a war including jar files under lib with a wrong deployment plan in
Geronimo server
2.Fail to deploy but can't recursive delete files under lib coz jar files are
open not close by xbean resource finder
Refer to https://issues.apache.org/jira/browse/GERONIMO-4696 for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource
On Jun 30, 2009, at 12:00 AM, David Blevins (JIRA) wrote: [ https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins closed XBEAN-133. --- Resolution: Won't Fix Assignee: David Blevins (was: viola.lu) David Maybe I missed conversation on an email thread, but this could probably use a little explanation... --kevan
