June 2011 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-3235) org.jboss.ws.core.soap.SOAPFaultImpl should be Serializable

by david.boeren (JIRA)

org.jboss.ws.core.soap.SOAPFaultImpl should be Serializable ----------------------------------------------------------- Key: JBWS-3235 URL: https://issues.jboss.org/browse/JBWS-3235 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.4.1 Reporter: david.boeren Priority: Trivial Fix For: jbossws-native-4.0 org.jboss.ws.core.soap.SOAPFaultImpl is currently not Serializable at runtime, which is counterintuitive since descendants of Throwable generally are, and all descendants of Throwable are marked as implementing the Serializable interface. There is a workaround to extract the message and place it in a different Exception class but this is an extra step that should not be necessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-3120) Virtual host feature have been removed in AS 6 series

by Richard Opalka (JIRA)

Virtual host feature have been removed in AS 6 series ----------------------------------------------------- Key: JBWS-3120 URL: https://jira.jboss.org/browse/JBWS-3120 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-4.0, jbossws-metro-4.0, jbossws-cxf-4.0 We should remove the test from our test suite and update our SPI accordingly to remove this feature for AS 6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBWS-2570) @SchemaValidation annotation does not work if schemaLocation property is not specified

by Nick Gudushauri (JIRA)

@SchemaValidation annotation does not work if schemaLocation property is not specified -------------------------------------------------------------------------------------- Key: JBWS-2570 URL: https://jira.jboss.org/jira/browse/JBWS-2570 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Environment: jboss 4.2.3.GA jbossws-native-3.0.5.GA Reporter: Nick Gudushauri Steps to reproduce: 1. Create simpe JAX-WS service 2. Annotate it with @SchemaValidation annotation WITHOUT specifying optional schemaLocation property (In such case schema should be extracted from the WSDL) 3. Send test request As the result no schema validation is performed and you will see the following messages in log: 17:07:13,421 INFO [SOAPBodyElementDoc] Validating: DOM_VALID 17:07:13,421 WARN [SchemaExtractor] Cannot find element: {http://schemas.xmlsoap.org/wsdl/}types 17:07:13,625 INFO [UCCServicesBean] Invoking UCC registerClearingOrder service by cer 17:07:14,515 INFO [SOAPBodyElementDoc] Validating: DOM_VALID 17:07:14,515 WARN [SchemaExtractor] Cannot find element: {http://schemas.xmlsoap.org/wsdl/}types The problem root is that org.jboss.ws.extensions.validation.SchemaExtractor class could not load 'types' element from WSDL as this element does not present in WSDL directly but imported via 'import' element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

6
9
0 / 0

[JBoss JIRA] Created: (JBWS-3256) Failed to load users/passwords/role files

by Richard Opalka (JIRA)

Failed to load users/passwords/role files ----------------------------------------- Key: JBWS-3256 URL: https://issues.jboss.org/browse/JBWS-3256 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Fix For: jbossws-native-4.0 12:16:56,434 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http-nucleus%2F127.0.0.1-8080-1) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found at org.jboss.security.auth.spi.Util.loadProperties(Util.java:201) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_20] at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_20] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:771) [:1.6.0_20] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [:1.6.0_20] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [:1.6.0_20] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [:1.6.0_20] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20] at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [:1.6.0_20] at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [:1.6.0_20] at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:553) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:487) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365) [picketbox-4.0.0.Alpha4.jar:4.0.0.Alpha4] at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:88) [jboss-as-web-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:660) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at java.lang.Thread.run(Thread.java:636) [:1.6.0_20] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JBWS-3246) Resuscitate JSON

by Richard Opalka (JIRA)

Resuscitate JSON ---------------- Key: JBWS-3246 URL: https://issues.jboss.org/browse/JBWS-3246 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-integration, jbossws-native Reporter: Richard Opalka Fix For: jbossws-native-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-3294) Remove ws-eventing implementation from native

by Richard Opalka (JIRA)

Remove ws-eventing implementation from native --------------------------------------------- Key: JBWS-3294 URL: https://issues.jboss.org/browse/JBWS-3294 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Assignee: Richard Opalka The jbossws-native ws-eventing implementation is not being maintained / supported. Even more the WS-Eventing spec. is considered deprecated. The upcoming WS-Eventing from WS-RA specification is it's successor. See http://www.w3.org/2002/ws/ra/snapshots/cr/wseventing.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-3276) Implement support for POJO endpoints with no web.xml in archive

by Richard Opalka (JIRA)

Implement support for POJO endpoints with no web.xml in archive --------------------------------------------------------------- Key: JBWS-3276 URL: https://issues.jboss.org/browse/JBWS-3276 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Richard Opalka Fix For: jbossws-native-4.0, jbossws-cxf-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-3280) Avoid building Spring Bus when deployment has no spring descriptor

by Alessio Soldano (JIRA)

Avoid building Spring Bus when deployment has no spring descriptor ------------------------------------------------------------------ Key: JBWS-3280 URL: https://issues.jboss.org/browse/JBWS-3280 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano The DescriptorDeploymentAspect currently relies on Spring availability in the classloader for deciding to generate a default jbossws-cxf.xml. Generally speaking, we should probably go the "Spring" way only when the deployment comes with a jbossws-cxf.xml (and spring is actually available ;-)), so the user explicitly asked for that. We might even evaluate changing the logic in JBossWSBusFactory to avoid using Spring when no spring descriptor is found (basically the same the CXF 2.4 SpringBusFactory does in public Bus createBus(String cfgFiles[], boolean includeDefaults) and we override in our JBossWS version of that factory). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3251) org.w3c.dom.DOMException when create dispatch with EPR

by Jim Ma (JIRA)

org.w3c.dom.DOMException when create dispatch with EPR ------------------------------------------------------- Key: JBWS-3251 URL: https://issues.jboss.org/browse/JBWS-3251 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native, ws-addressing Affects Versions: jbossws-native-3.4.1 Reporter: Jim Ma Fix For: jbossws-native-4.0 0:40:43,972 INFO [STDOUT] WS ADDR=<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/Quickstart_bpel_simple_invoke/HelloWorldWS</Address><Metadata><wsam:ServiceName EndpointName="HelloWorldPort" xmlns="http://simple_invoke/helloworld" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">HelloWorldWSService</wsam:ServiceName></Metadata></EndpointReference> 10:40:44,153 ERROR [HandlerChainExecutor] Exception during handler processing org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it. at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown Source) at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source) at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source) at org.jboss.ws.core.soap.NodeImpl.appendChild(NodeImpl.java:481) at org.jboss.ws.core.soap.SOAPHeaderImpl.appendChild(SOAPHeaderImpl.java:198) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:264) at org.jboss.ws.core.soap.SOAPHeaderImpl.addChildElement(SOAPHeaderImpl.java:70) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:233) at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:267) at org.jboss.ws.extensions.addressing.jaxws.WSAddressingClientHandler.handleOutbound(WSAddressingClientHandler.java:139) at org.jboss.wsf.common.handler.GenericHandler.handleMessage(GenericHandler.java:53) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:328) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:146) at org.jboss.ws.core.jaxws.client.DispatchImpl.callRequestHandlerChain(DispatchImpl.java:640) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:256) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:180) at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:147) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable$1.call(WebServiceClient.java:355) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:289) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:246) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable.call(WebServiceClient.java:231) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Only thing I am doing is: org.apache.ode.bpel.iapi.EndpointReference odeepr=mex.getEndpointReference(); javax.xml.ws.EndpointReference epr=null; if (odeepr != null) { if (odeepr instanceof org.apache.ode.bpel.epr.URLEndpoint) { org.apache.ode.bpel.epr.URLEndpoint url=(org.apache.ode.bpel.epr.URLEndpoint)odeepr; javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder builder= new javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder(); epr = builder.address(url.getUrl()) .serviceName(serviceName) .endpointName(port) .build(); System.out.println("WS ADDR="+epr); Creating the EPR from the ODE endpoint reference, and then if (epr != null) { dispatcher = service.createDispatch( epr, SOAPMessage.class, Service.Mode.MESSAGE, new javax.xml.ws.soap.AddressingFeature() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-3233) jbossws/services web view shows wrong port

by Steve Cassidy (JIRA)

jbossws/services web view shows wrong port ------------------------------------------ Key: JBWS-3233 URL: https://issues.jboss.org/browse/JBWS-3233 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss 4.3.0 CP08 running on RHEL 5 (5.6) - kernel version 2.6.18-238.1.1.el5 Reporter: Steve Cassidy Priority: Minor We have a JBoss installation where we have disabled port 8080 for security reasons (in jboss-web.deployer/server.xml). We listen on port 8443 on SSL and 8009 for AJP. However if I look at the web view of Web services (jbossws/services context path in a web browser) this shows the WSDLs of the services but the links are still showing ":8080" as the listening port (even though JBoss is not listening on port 8080). I undersdtand that it is possible to have JBoss listeing on multiple ports so hence it would not be clear what would be put here instead but for a simple example where Jboss is listening on port 8443 and not 8080 it seems wrong that 8080 is shown and not 8443. I understand that this is not the highetst priority issue ever but to make the product consistent could you please look at this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues June 2011