October 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3797) Let @WebContext(virtualHost...) affect endpoint address

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3797?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-3797: ------------------------- Description: When @WebContext(virtualHost=...) is specified, the referenced virtualHost name should be usable to get the corresponding port (from the web layer, through the (JBoss)WebMetadata attached to deployment) and modify the endpoint address accordingly (in EndpointAddressDeploymentAspect). This likely require some additional functionalities from the container web layer to get the port for a given virtual host. was: When @WerbContext(virtualHost=...) is specified, the referenced virtualHost name should be usable to get the corresponding port (from the web layer, through the (JBoss)WebMetadata attached to deployment) and modify the endpoint address accordingly (in EndpointAddressDeploymentAspect). This likely require some additional functionalities from the container web layer to get the port for a given virtual host. > Let @WebContext(virtualHost...) affect endpoint address > ------------------------------------------------------- > > Key: JBWS-3797 > URL: https://issues.jboss.org/browse/JBWS-3797 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > When @WebContext(virtualHost=...) is specified, the referenced virtualHost name should be usable to get the corresponding port (from the web layer, through the (JBoss)WebMetadata attached to deployment) and modify the endpoint address accordingly (in EndpointAddressDeploymentAspect). > This likely require some additional functionalities from the container web layer to get the port for a given virtual host. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3839) excessive ERROR logging on webservices invocation if SoapFault

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3839?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-3839: ------------------------- Comment: was deleted (was: Hi Thomas, To fix this issue I think we can introduce another annotation to mark some exception doesn't need to be logged, and this kind of exception is expected to happen. For example when it sees the exception with Annotation @NonLoggingException , it will skip to log this kind of error. @NonLonggingException public ExampleException extends Exception { } Will this work for your case ?) > excessive ERROR logging on webservices invocation if SoapFault > -------------------------------------------------------------- > > Key: JBWS-3839 > URL: https://issues.jboss.org/browse/JBWS-3839 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Thomas Frühbeck > Assignee: Jim Ma > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > AbstractInvocationHandler logs ERROR even if invocation fails with SOAPFault, which is IMHO wrong. > It is to be handled like @ApplicationException, the service implementation too care to raise a SOAPFault. > catch (Throwable t) { > WSLogger.ROOT_LOGGER.methodInvocationFailed(t, t.getLocalizedMessage()); > handleInvocationException(t); > The current implementation leads to excessive false ERROR logs, which is unpleasant in production environments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3839) excessive ERROR logging on webservices invocation if SoapFault

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3839?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3839: ------------------------------ This kind of exception is logged by org.apache.cxf.phase.PhaseInterceptorChain with INFO level. Full detailed exception and cause can be logged with Fine level. It looks we can simply remove this line code. > excessive ERROR logging on webservices invocation if SoapFault > -------------------------------------------------------------- > > Key: JBWS-3839 > URL: https://issues.jboss.org/browse/JBWS-3839 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Thomas Frühbeck > Assignee: Jim Ma > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > AbstractInvocationHandler logs ERROR even if invocation fails with SOAPFault, which is IMHO wrong. > It is to be handled like @ApplicationException, the service implementation too care to raise a SOAPFault. > catch (Throwable t) { > WSLogger.ROOT_LOGGER.methodInvocationFailed(t, t.getLocalizedMessage()); > handleInvocationException(t); > The current implementation leads to excessive false ERROR logs, which is unpleasant in production environments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3803) Revisit doc on running JBWS testsuite in IDE

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3803?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3803: -------------------------------- New text posted to https://developer.jboss.org/wiki/JBossWS-SetupYourIDE. Waiting for moderator to approve the changes. > Revisit doc on running JBWS testsuite in IDE > -------------------------------------------- > > Key: JBWS-3803 > URL: https://issues.jboss.org/browse/JBWS-3803 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > At the time of JBossWS 3, we put some efforts on the IDE integration and the page at [1] was produced. That page basically does not apply anymore; we need to provide proper directions on how to run the jbossws testsuite in the IDE nowadays (with the eclipse / maven plugins we have today and the current project structure). > The last part of the old webpage is about the project generation, which is to be replaced by the jbossws maven archetype, so that's not part of the task here. > [1] https://community.jboss.org/wiki/JBossWS-SetupyourIDE -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3792) JBossWS: wsdl:import always handled as relative location

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3792?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3792: -------------------------------- Commit patch to SOAPAddressWSDLParser https://svn.jboss.org/repos/jbossws/common/trunk (version 3.0.0-SNAPSHOT) Committed revision 18986. > JBossWS: wsdl:import always handled as relative location > -------------------------------------------------------- > > Key: JBWS-3792 > URL: https://issues.jboss.org/browse/JBWS-3792 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > Assignee: R Searls > Attachments: JBWS-3792_java.net.URL_proposal.patch, jbws3792-external-wsdl.war, jbws3792-ws-impl.war, jbws3792_example_src.tar.gz > > > As described in this thread: https://community.jboss.org/thread/240821 > wsdl:import directive seems to be always resolved as a relative location. > For example, this statement: > <wsdl:import namespace="http://foo.bar.com/foo.bar.Service" location="http://foo.bar.com/Service.svc?wsdl=wsdl0"/> > May result in this URL being resolved: > http://foo.bar.com/http://foo.bar.com/Service.svc?wsdl=wsdl0 > This prevents the WSDL file from being parsed. > This behavior seems to originate from: org.jboss.ws.common.deployment.SOAPAddressWSDLParser, line 211 in v2.3.0.Final and current trunk: > } else if (match(reader, WSDL_NS, IMPORT)) { > final String location = reader.getAttributeValue(null, LOCATION); > final String url = wsdlUrl.toString(); > final String newUrl = url.substring(0, url.lastIndexOf("/") + (location.startsWith("/") ? 0 : 1)) + location; > if (!metadata.getImports().containsKey(newUrl)) { > metadata.getImports().put(newUrl, false); > } > } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3802) Empty response returned when SOAP Fault is thrown from an endpoint having WS-Security Policy Signature profile

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3802?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3802: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1111046|https://bugzilla.redhat.com/show_bug.cgi?id=1111046] from MODIFIED to ON_QA > Empty response returned when SOAP Fault is thrown from an endpoint having WS-Security Policy Signature profile > -------------------------------------------------------------------------------------------------------------- > > Key: JBWS-3802 > URL: https://issues.jboss.org/browse/JBWS-3802 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > Assignee: Jim Ma > Fix For: jbossws-cxf-5.0.0.Beta1 > > > Please port [CXF-5810|https://issues.apache.org/jira/browse/CXF-5810], which is the root cause of the issue, to JBoss WS. > When a web service has a WS-Security Signature policy in its WSDL and throws a SOAP Fault, it returns an empty HTTP response that has zero-length of content to client instead of the SOAP Fault. > This happens only with Signature policy and doesn't happen with any other WS-Security policies like UsernameToken, or without WS-Security. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3838) SOAP Web Service Handlers executing in different order when server is restarted

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3838?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3838: ---------------------------------- Description: Handler order can change after a reboot, which causes problems when one handler depends on the action of another. * Description of the problem The flow is basically the following: 1) the container model is parsed; it can include jaxws configs, which are composed of jaxws handler chains, which in turn has one or multiple jaxws handlers 2) we have add operations for each jaxws handler and jaxws handler chain. Each of them starts a service, which builds up the corresponding metadata to be later used by jbossws; proper dependencies are set between those services, so that for instance the service for a handler chain waits for all its handlers' services. 3) when the service for the handler chain runs, it gets the info from the handler services and them in the chain metadata. This is where I get unpredictable ordering, as the handler services are run in parallel * Solution The idea is that we need to derive the handlers' order from the add operation steps, which are executed in the same order they're created in the parser. Brian also suggests to use the OperationContext.attach(...) API to pass data between handler invocations within an overall operation execution. All ws subsystem ops during boot are executed as steps within an overall operation. The API works like the attachment stuff that's used a lot in DeploymentUnitProcessors. was:Handler order can change after a reboot, which causes problems when one handler depends on the action of another. > SOAP Web Service Handlers executing in different order when server is restarted > ------------------------------------------------------------------------------- > > Key: JBWS-3838 > URL: https://issues.jboss.org/browse/JBWS-3838 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: david.boeren > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > Handler order can change after a reboot, which causes problems when one handler depends on the action of another. > * Description of the problem > The flow is basically the following: > 1) the container model is parsed; it can include jaxws configs, which are composed > of jaxws handler chains, which in turn has one or multiple jaxws handlers > 2) we have add operations for each jaxws handler and jaxws handler > chain. Each of them starts a service, which builds up the corresponding > metadata to be later used by jbossws; proper dependencies are set > between those services, so that for instance the service for a handler > chain waits for all its handlers' services. > 3) when the service for the handler chain runs, it gets the info from > the handler services and them in the chain metadata. This is where I get > unpredictable ordering, as the handler services are run in parallel > * Solution > The idea is that we need to derive the handlers' order from the add operation steps, which are executed in the same order they're created in the parser. > Brian also suggests to use the OperationContext.attach(...) API to pass data between handler invocations within an overall operation execution. All ws subsystem ops during boot are executed as steps within an overall operation. The API works like the attachment stuff that's used a lot in DeploymentUnitProcessors. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3841) Upgrade to Woodstox 4.4.1

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3841: ------------------------------------- Summary: Upgrade to Woodstox 4.4.1 Key: JBWS-3841 URL: https://issues.jboss.org/browse/JBWS-3841 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3792) JBossWS: wsdl:import always handled as relative location

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3792?page=com.atlassian.jira.plugin.... ] R Searls reopened JBWS-3792: ---------------------------- Revisiting issue with apps provided by poster. > JBossWS: wsdl:import always handled as relative location > -------------------------------------------------------- > > Key: JBWS-3792 > URL: https://issues.jboss.org/browse/JBWS-3792 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > Assignee: R Searls > Attachments: JBWS-3792_java.net.URL_proposal.patch, jbws3792-external-wsdl.war, jbws3792-ws-impl.war, jbws3792_example_src.tar.gz > > > As described in this thread: https://community.jboss.org/thread/240821 > wsdl:import directive seems to be always resolved as a relative location. > For example, this statement: > <wsdl:import namespace="http://foo.bar.com/foo.bar.Service" location="http://foo.bar.com/Service.svc?wsdl=wsdl0"/> > May result in this URL being resolved: > http://foo.bar.com/http://foo.bar.com/Service.svc?wsdl=wsdl0 > This prevents the WSDL file from being parsed. > This behavior seems to originate from: org.jboss.ws.common.deployment.SOAPAddressWSDLParser, line 211 in v2.3.0.Final and current trunk: > } else if (match(reader, WSDL_NS, IMPORT)) { > final String location = reader.getAttributeValue(null, LOCATION); > final String url = wsdlUrl.toString(); > final String newUrl = url.substring(0, url.lastIndexOf("/") + (location.startsWith("/") ? 0 : 1)) + location; > if (!metadata.getImports().containsKey(newUrl)) { > metadata.getImports().put(newUrl, false); > } > } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3792) JBossWS: wsdl:import always handled as relative location

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3792?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3792: ---------------------------------- Fix Version/s: (was: jbossws-cxf-5.0) > JBossWS: wsdl:import always handled as relative location > -------------------------------------------------------- > > Key: JBWS-3792 > URL: https://issues.jboss.org/browse/JBWS-3792 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > Assignee: R Searls > Attachments: JBWS-3792_java.net.URL_proposal.patch, jbws3792-external-wsdl.war, jbws3792-ws-impl.war, jbws3792_example_src.tar.gz > > > As described in this thread: https://community.jboss.org/thread/240821 > wsdl:import directive seems to be always resolved as a relative location. > For example, this statement: > <wsdl:import namespace="http://foo.bar.com/foo.bar.Service" location="http://foo.bar.com/Service.svc?wsdl=wsdl0"/> > May result in this URL being resolved: > http://foo.bar.com/http://foo.bar.com/Service.svc?wsdl=wsdl0 > This prevents the WSDL file from being parsed. > This behavior seems to originate from: org.jboss.ws.common.deployment.SOAPAddressWSDLParser, line 211 in v2.3.0.Final and current trunk: > } else if (match(reader, WSDL_NS, IMPORT)) { > final String location = reader.getAttributeValue(null, LOCATION); > final String url = wsdlUrl.toString(); > final String newUrl = url.substring(0, url.lastIndexOf("/") + (location.startsWith("/") ? 0 : 1)) + location; > if (!metadata.getImports().containsKey(newUrl)) { > metadata.getImports().put(newUrl, false); > } > } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

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 October 2014