June 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3809: --------------------------------------- The user who reproduced this is having endpoints declared as follows: @WebService(name = "QualificationAndAlternativeSynchronizerService", portName = "QualificationSynchronizerServiceV2Port", serviceName = "dispate2Web", targetNamespace = "http://ws2.dispate.sync.centerware.mobilexag.de/") @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = Use.LITERAL, parameterStyle = ParameterStyle.WRAPPED) public class QualificationAndAlternativeSynchronizerServiceBean implements QualificationAndAlternativeSynchronizerService { ... @WebService(name = "BasicUpdateTaskService", portName = "BasicUpdateTaskServicePort", serviceName = "dispate2Web", targetNamespace = "http://ws2.dispate.sync.centerware.mobilexag.de/") @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL, parameterStyle = SOAPBinding.ParameterStyle.WRAPPED) public class BasicUpdateTaskServiceBean implements BasicUpdateTaskService { ... ejb-jar.xml: ... <session id="QualificationSynchronizerServiceV2Bean"> <display-name>QualificationSynchronizerServiceV2Bean</display-name> <ejb-name>QualificationSynchronizerServiceV2Bean</ejb-name> <business-local>de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerService</business-local> <ejb-class>de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> ... <session id="BasicUpdateTaskServiceBean"> <display-name>BasicUpdateTaskServiceBean</display-name> <ejb-name>BasicUpdateTaskServiceBean</ejb-name> <business-local>de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskService</business-local> <ejb-class>de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3809: --------------------------------------- JSR109 v.1.3 should be checked when dealing with this. > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3809: ---------------------------------- Description: We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. {noformat} 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more {noformat} was: We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3809: ---------------------------------- Description: We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. was: We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3809: ------------------------------------- Summary: AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data Key: JBWS-3809 URL: https://issues.jboss.org/browse/JBWS-3809 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3808) The response-count of the endpoint metrics sometimes not counted

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3808?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-3808: ------------------------- Summary: The response-count of the endpoint metrics sometimes not counted (was: The response-count of the endpoint metrics is sometimes not counted correctly) > The response-count of the endpoint metrics sometimes not counted > ---------------------------------------------------------------- > > Key: JBWS-3808 > URL: https://issues.jboss.org/browse/JBWS-3808 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: jbossws-cxf-5.0 > > > We now calculate the request-count, response-count and other metric value in RequestHandlerImpl , it is executed after cxf's httpDestination.invoke(cfg, context, req, response) which the response already sent to receiver and invocation is done. The response related metric won't be incremented and updated if the metric query happens between httpDestination.invoke and metrics update. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3808) The response-count of the endpoint metrics is sometimes not counted correctly

by Jim Ma (JIRA)

Jim Ma created JBWS-3808: ---------------------------- Summary: The response-count of the endpoint metrics is sometimes not counted correctly Key: JBWS-3808 URL: https://issues.jboss.org/browse/JBWS-3808 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.3 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-5.0 We now calculate the request-count, response-count and other metric value in RequestHandlerImpl , it is executed after cxf's httpDestination.invoke(cfg, context, req, response) which the response already sent to receiver and invocation is done. The response related metric won't be incremented and updated if the metric query happens between httpDestination.invoke and metrics update. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3516) JBossWS-CXF doesn't send fault message to a FaultTo endpoint when request-response message.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3516?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3516: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 900634|https://bugzilla.redhat.com/show_bug.cgi?id=900634] from VERIFIED to CLOSED > JBossWS-CXF doesn't send fault message to a FaultTo endpoint when request-response message. > -------------------------------------------------------------------------------------------- > > Key: JBWS-3516 > URL: https://issues.jboss.org/browse/JBWS-3516 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.0.2 > Reporter: Takayuki Konishi > Assignee: Jim Ma > Fix For: jbossws-cxf-4.1.0.Beta2 > > > When I set FaultTo element of WS-Addressing to a WS client but WS server doesn't sent fault messages to the FaultTo destination. On the other hand, when set ReplyTo element, the WS server sent responses to ResponseTo destination. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3773) HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3773?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3773: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1077259|https://bugzilla.redhat.com/show_bug.cgi?id=1077259] from VERIFIED to CLOSED > HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set > ------------------------------------------------------------------------------ > > Key: JBWS-3773 > URL: https://issues.jboss.org/browse/JBWS-3773 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > See https://issues.apache.org/jira/browse/CXF-5602 > The HttpServletContext retrieved from the WebServiceContext can have stale values when running on AS 7 (using JBossWeb) and processing WS-Addressing requests with non generic ReplyTo header props. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3670) Spring declared endpoints, AS components and injection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3670?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3670: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1060001|https://bugzilla.redhat.com/show_bug.cgi?id=1060001] from VERIFIED to CLOSED > Spring declared endpoints, AS components and injection > ------------------------------------------------------ > > Key: JBWS-3670 > URL: https://issues.jboss.org/browse/JBWS-3670 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > > > See https://community.jboss.org/message/822796#822796 . Basically the user is trying to declare a WS endpoint using Spring configuration and having other Spring beans injected in it. The problem is the endpoint is actually being created as an AS component later after the spring context has already been built. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues June 2014