[JBoss JIRA] Created: (JBWS-3101) NullPointerException if SOAPMessage Provider endpoint returns null to indicate a one way MEP
by Ray Cardillo (JIRA)
NullPointerException if SOAPMessage Provider endpoint returns null to indicate a one way MEP
--------------------------------------------------------------------------------------------
Key: JBWS-3101
URL: https://jira.jboss.org/browse/JBWS-3101
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.3.1
Environment: JBossESB 4.8, JBossAS 5.1.0, JBossWS-Native 3.3.1
Reporter: Ray Cardillo
JAX-WS Provider Endpoints are supposed to be able to return 'null' to indicate that it's a one way MEP and no response is needed. Web services ported from the Metro stack will fail on the Native stack if they use this feature because the Native stack seems to be expecting a non-null value to be returned at all times. The API clearly states that null can be returned from invoke() to indicate a one way MEP when no response is required:
https://jax-ws.dev.java.net/nonav/jax-ws-20-pfd/api/javax/xml/ws/Provider...
On the native stack, when trying to return null from a Provider<SOAPMessage> invoke() operation, a NullPointerException is thrown:
08:03:32,870 ERROR [RequestHandlerImpl] Error processing web service request
org.jboss.ws.WSException: java.lang.NullPointerException
at org.jboss.ws.WSException.rethrow(WSException.java:68)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:362)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:207)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:132)
at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
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:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.sendResponse(RequestHandlerImpl.java:435)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:358)
... 24 more
--
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
15 years, 4 months
[JBoss JIRA] Created: (JBWS-3116) NettyClient sends uri on absolute format which is not correct according to RFC2616
by Sverker Abrahamsson (JIRA)
NettyClient sends uri on absolute format which is not correct according to RFC2616
----------------------------------------------------------------------------------
Key: JBWS-3116
URL: https://jira.jboss.org/browse/JBWS-3116
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.3.1
Reporter: Sverker Abrahamsson
When JBossWS native implementation sends a HTTP request this is hadled by org.jboss.ws.core.client.transport.NettyClient. The first line in the HTTP request is sent like this:
POST http://server:port/path HTTP/1.1
I.e. an absoluteURI according to section 5.1.2 in RFC2616. However, there it's also stated that:
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
The absoluteURI format is to be used when the request is sent through a proxy and the abs_path format is to be used when sending directly to the server. Although RFC2616 also states that all servers compliant to HTTP 1.1 must be able to accept the absoluteURI for forward compatibility, no compliant clients must generate such requests.
I found this when I ran into problems connecting to a certain webservice which couldn't parse the uri, so in that case both sides were wrong (jbossws shouldn't use that kind of uri and the other end should be able to accept them).
To make JBossWS compliant to HTTP 1.1 I've changed it according to the attached patch, it probably need some more work as it needs to check if proxy is used and if so send the uri on absolute format.
--
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
15 years, 4 months
[JBoss JIRA] Created: (JBWS-3124) Remove JBWS2942TestCase framework test and create Native and CXF specific tests validating empty EPR Metadata are dropped
by Sergey Beryozkin (JIRA)
Remove JBWS2942TestCase framework test and create Native and CXF specific tests validating empty EPR Metadata are dropped
-------------------------------------------------------------------------------------------------------------------------
Key: JBWS-3124
URL: https://jira.jboss.org/browse/JBWS-3124
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-native
Affects Versions: jbossws-cxf-3.4.0.Beta2, jbossws-native-3.3.1
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Fix For: jbossws-cxf-3.4.0, jbossws-native-3.4.0
JBWS-2942 tests that empty Metadata can be dropped when external EPRs already containing empty Metadata are read and then serialized.
CXF has been updated to ensure EPRs won't have empty Metadata written in the first place and the test using W3CEndpointReferenceBuilder can confirm it.
Given that it would be difficult for enhance CXF to have original JBWS-2942 passing and equally it could be tricky to enhance Native to have a W3CEndpointReferenceBuilder based test passing, it would be good to have the test removed from the framework and the original test moved to Native and a W3CEndpointReferenceBuilder based test added to JBossWS-CXF
--
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
15 years, 4 months
[JBoss JIRA] Created: (JBWS-3096) WebServiceContext#getUserPrincipal() returns null in JBossWS Metro stack when the user is authenticated
by Yue Ni (JIRA)
WebServiceContext#getUserPrincipal() returns null in JBossWS Metro stack when the user is authenticated
-------------------------------------------------------------------------------------------------------
Key: JBWS-3096
URL: https://jira.jboss.org/browse/JBWS-3096
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro
Affects Versions: jbossws-metro-3.3.1
Environment: JBoss 5.0.1 EAP
Java 1.6
Reporter: Yue Ni
Attachments: hello-service.zip, request.xml
I am using JBossWS metro stack to implement Username Token profile authentication for a web service. The authentication will be triggered, and the credential information in SOAP header can be obtained in a custom realm authenticator.
However, even if the authentication pass and the service operation is performed, the WebServiceContext#getUserPrincipal() always returns null.
I attached a simple maven 2 project (for service implementation) and a SOAP request (sent with SOAP UI), you can use that to reproduce this issue.
--
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
15 years, 4 months
[JBoss JIRA] Created: (JBWS-2462) Address rewrite test fails in Metro integration
by Richard Opalka (JIRA)
Address rewrite test fails in Metro integration
-----------------------------------------------
Key: JBWS-2462
URL: https://jira.jboss.org/jira/browse/JBWS-2462
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-metro-3.0.5
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-metro-3.0.6
18:25:47,441 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/home/opalka/svn/jbossws/stack/metro/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws2150-sec.war state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/opalka/svn/jbossws/stack/metro/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws2150-sec.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:270)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.xml.ws.WebServiceException: Failed to build METRO runtime model
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.start(RuntimeModelDeploymentAspect.java:133)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:129)
at org.jboss.wsf.container.jboss50.deployer.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:75)
at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:60)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 63 more
Caused by: java.lang.Error: Undefined operation name echo
at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:327)
at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:97)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:268)
at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:322)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:188)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parseAdapters(DeploymentDescriptorParserExt.java:295)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parse(DeploymentDescriptorParserExt.java:171)
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.start(RuntimeModelDeploymentAspect.java:109)
... 68 more
--
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
15 years, 4 months