November 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3827) WSDL publisher incorrectly attempt to publish external HTTPS import

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3827?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3827: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > 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.0.Beta2 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3818) Upgrade to Apache CXF 3.0.2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3818?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3818: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > Upgrade to Apache CXF 3.0.2 > --------------------------- > > Key: JBWS-3818 > URL: https://issues.jboss.org/browse/JBWS-3818 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3837?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3837: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > 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.0.Beta2 > > > "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.8#6338)

10 years, 1 month

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: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > 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.0.Beta2 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3830) WSProvideTask "address" option not working

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3830?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3830: ---------------------------------- Fix Version/s: jbossws-cxf-5.0.0.Beta2 (was: jbossws-cxf-5.0) > WSProvideTask "address" option not working > ------------------------------------------ > > Key: JBWS-3830 > URL: https://issues.jboss.org/browse/JBWS-3830 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, tools-jaxws > Affects Versions: jbossws-cxf-4.1.0.Final > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.0.0.Beta2 > > > When implementing JBWS-3510, we erroneously named "portSoapAddress" the additional field in WSProvideTask. That should have been "address". As a result the "address" option does not work. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3560) Unlock FastInfoset feature in CXF on top of JBossAS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3560?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3560: ----------------------------------------------- Kyle Lape <klape(a)redhat.com> changed the Status of [bug 1154936|https://bugzilla.redhat.com/show_bug.cgi?id=1154936] from NEW to POST > Unlock FastInfoset feature in CXF on top of JBossAS > --------------------------------------------------- > > Key: JBWS-3560 > URL: https://issues.jboss.org/browse/JBWS-3560 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Richard Opalka > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3842) Cannot boot server with 2+ handlers in the same predefined configuration handler chain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3842?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3842: ----------------------------------------------- Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1157607|https://bugzilla.redhat.com/show_bug.cgi?id=1157607] from ASSIGNED to POST > Cannot boot server with 2+ handlers in the same predefined configuration handler chain > -------------------------------------------------------------------------------------- > > Key: JBWS-3842 > URL: https://issues.jboss.org/browse/JBWS-3842 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.3 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0 > > > Commit https://github.com/wildfly/wildfly/commit/e32f27d433ad3da41ef042f1ad9b950... introduced a regressions when having multiple handlers in the same handler-chain within one of the pre-defined configuration in the webservices subsystem: > {noformat} > 5:49:24,653 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: org.jboss.msc.service.StartException in service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60] > Caused by: org.jboss.msc.inject.InjectionException: Value already set for this injector > at org.jboss.msc.inject.RetainingInjector.inject(RetainingInjector.java:50) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.as.webservices.dmr.ListInjector.inject(ListInjector.java:23) > at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:55) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {noformat} -- 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: ----------------------------------------------- Jan Blizňák <jbliznak(a)redhat.com> changed the Status of [bug 1110631|https://bugzilla.redhat.com/show_bug.cgi?id=1110631] from ON_QA to VERIFIED > 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-3843) Username Token Digest Authentication failure with EJB3 endpoints

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3843?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3843: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1157482|https://bugzilla.redhat.com/show_bug.cgi?id=1157482] from NEW to MODIFIED > Username Token Digest Authentication failure with EJB3 endpoints > ---------------------------------------------------------------- > > Key: JBWS-3843 > URL: https://issues.jboss.org/browse/JBWS-3843 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration, ws-security > Affects Versions: jbossws-cxf-4.3.1 > Environment: JBoss EAP 6.3.1 > Reporter: Mustafa Musaji > Assignee: Jim Ma > Priority: Critical > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0 > > Attachments: ClientSample.java, javaee-ws-with-security_1413372207000.zip > > > EJB3 Web Service using username token for digest authentication fails when you load test it with parallel invocations. See attached reproducer. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3838) Predefined configuration handlers executing in different order when server is restarted

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3838?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3838: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1153960|https://bugzilla.redhat.com/show_bug.cgi?id=1153960] from NEW to MODIFIED > Predefined configuration 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-4.3.2, 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues November 2014