October 2014 - jbossws-issues - Jboss List Archives

[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: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 > 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. -- 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 david.boeren (JIRA)

david.boeren created JBWS-3838: ---------------------------------- Summary: 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 Handler order can change after a reboot, which causes problems when one handler depends on the action of another. -- 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: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1111046|https://bugzilla.redhat.com/show_bug.cgi?id=1111046] from POST to MODIFIED > 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-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: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 1110631|https://bugzilla.redhat.com/show_bug.cgi?id=1110631] from ASSIGNED to MODIFIED > 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-3827) WSDL publisher incorrectly attempt to publish external HTTPS import

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3827?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3827: -------------------------------- code added as described above into https://svn.jboss.org/repos/jbossws/common/trunk (3.0.0-SNAPSHOT). Committed revision 18976. Index: src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java =================================================================== --- src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java (revision 18971) +++ src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java (working copy) @@ -143,7 +143,7 @@ { String locationURI = wsdlImport.getLocationURI(); // its an external import, don't publish locally - if (locationURI.startsWith("http://") == false) + if (locationURI.startsWith("http://") == false && locationURI.startsWith("https://") == false) { // infinity loops prevention if (published.contains(locationURI)) ==================================== The fix was tested manually. It was not possbile to create an automated test. Manual configuration of standalone.xml and $JAVA_HOME/jre/lib/security/cacerts would be required. > WSDL publisher incorrectly attempt to publish external HTTPS import > ------------------------------------------------------------------- > > Key: JBWS-3827 > URL: https://issues.jboss.org/browse/JBWS-3827 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > In org.jboss.ws.common.utils.AbstractWSDLFilePublisher, the condition used to detect external import looks like this: > // its an external import, don't publish locally > if (locationURI.startsWith("http://") == false) { ... } > This does not take in account import done over other protocols such as HTTPS. Deploying such WSDL will fail since jboss will try to resolve an absolute URL against the current deployment unit. > Simply adapting the test to include "https://" seems effective (not sure if it truly satisfies all use cases however). > This was only tested in version 2.2.3 Final of jboss-ws-common but those lines are still in trunk... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3837) Apache CXF interceptors setup through properties

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3837: ------------------------------------- Summary: Apache CXF interceptors setup through properties Key: JBWS-3837 URL: https://issues.jboss.org/browse/JBWS-3837 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 "Speaking of properties, currently specified in jboss-webservices.xml and possibly in jboss-webservices-client.xml, we could start supporting two additional props: * org.apache.cxf.interceptor.InInterceptors, with the value string to be parsed for getting a list of in-interceptor classnames; basically to achieve the same we get with @InInterceptor * org.apache.cxf.interceptor.OutInterceptors, with the value string to be parsed for getting a list of out-interceptor classnames; basically to achieve the same we get with @OutInterceptor The interceptors would be attached either to the bus or to the client/endpoint depending on where the property is declared." http://lists.jboss.org/pipermail/jbossws-dev/2014-September/002209.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3836) Convention for automatic predefined client/endpoint configuration retrieval

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3836: ------------------------------------- Summary: Convention for automatic predefined client/endpoint configuration retrieval Key: JBWS-3836 URL: https://issues.jboss.org/browse/JBWS-3836 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf, jbossws-integration, productivity Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 "An alternative idea would be to provide a convention for automatically reading a pre-defined client configuration, for instance based on the SEI class FQN. So for instance, we could say that for a port retrieved as follows import org.foo.ServiceIface; ... Service service = Service.create(new URL("...?wsdl"), serviceQName); ServiceIface port = (ServiceIface)service.getPort(portQName, ServiceIface.class); instead of directly going and fetching the "Standard-Client-Configuration" from the container webservices management model we'd first try getting a configuration named "org.foo.ServiceIface" (still in the webservices model) and only fallback to the "Standard-Client-Configuration" if that's not found. That would allow for different configurations to clients without touching their code; the only requirement is the clients run in-container." http://lists.jboss.org/pipermail/jbossws-dev/2014-September/002211.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3832) Different default Spring descriptor name for creating client and server Bus instances

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3832?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3832: --------------------------------------- The testcase for this feature requires JBWS-3835. > Different default Spring descriptor name for creating client and server Bus instances > ------------------------------------------------------------------------------------- > > Key: JBWS-3832 > URL: https://issues.jboss.org/browse/JBWS-3832 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3832-TEST_DRAFT.patch, JBWS-3832.diff > > > When Spring integration is enabled, the CXF Bus factory uses the same name to lookup descriptor defining the bus to be used for clients or endpoints (usually cxf.xml). Generally speaking, we might want to have the JAX-WS clients end up always using different Spring descriptors then any other consumer of the CXF Spring Bus factory. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3835) Add mechanism for restarting target container while running JBossWS tests

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3835?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3835: ---------------------------------- Description: We need a mechanism for asking the current test container to be restarted; this is useful to test different values for configuration options that are read once when booting the server or creating the WS subsystem classloader. (was: We need a mechanism for asking the current test container to be restarted; this is useful to test different values for configuration options that are read once when booting the server.) > Add mechanism for restarting target container while running JBossWS tests > ------------------------------------------------------------------------- > > Key: JBWS-3835 > URL: https://issues.jboss.org/browse/JBWS-3835 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > We need a mechanism for asking the current test container to be restarted; this is useful to test different values for configuration options that are read once when booting the server or creating the WS subsystem classloader. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3835) Add mechanism for restarting target container while running JBossWS tests

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3835: ------------------------------------- Summary: Add mechanism for restarting target container while running JBossWS tests Key: JBWS-3835 URL: https://issues.jboss.org/browse/JBWS-3835 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 We need a mechanism for asking the current test container to be restarted; this is useful to test different values for configuration options that are read once when booting the server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 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 October 2014