December 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3854) EndpointConfigAdd does not set required PropertyService dependencies

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3854?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3854: ---------------------------------- Affects Version/s: jbossws-cxf-4.3 > EndpointConfigAdd does not set required PropertyService dependencies > -------------------------------------------------------------------- > > Key: JBWS-3854 > URL: https://issues.jboss.org/browse/JBWS-3854 > 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-5.0 > > > In the container integration, the EndpointConfigAdd operation is not setting PropertyService dependencies on ConfigService created for endpoints. That can result in properties being lost. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

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: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1157610|https://bugzilla.redhat.com/show_bug.cgi?id=1157610] 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.0.Beta2 > > > 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.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3813) Add exception name to faultstring/detail/stackTrace

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3813?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3813: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1111744 > Add exception name to faultstring/detail/stackTrace > --------------------------------------------------- > > Key: JBWS-3813 > URL: https://issues.jboss.org/browse/JBWS-3813 > Project: JBoss Web Services > Issue Type: Enhancement > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > This is a placeholder for the https://issues.apache.org/jira/browse/CXF-4242 issue. We should probably have a testcase in JBWS testsuite too. > Forum reference: https://community.jboss.org/thread/198372?tstart=0&_sscc=t -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3857) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3857?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3857: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167348 > Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) > ------------------------------------------------------------------------------------------------- > > Key: JBWS-3857 > URL: https://issues.jboss.org/browse/JBWS-3857 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Tomas Hofman > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. > Description of problem: > There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. > How reproducible: > always > Additional info: > It's also wrong in EAP 6.2. > EAP 6.1 is OK. > There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3857) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...)

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3857?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3857: -------------------------------- Committed revision 19121 to repo https://svn.jboss.org/repos/jbossws/stack/cxf/trunk <version>5.0.0-SNAPSHOT</version> Integrated of jbossws-cxf-4.3.x.patch posted in bz-1167348. modules/client/src/main/java/org/jboss/wsf/stack/cxf/saaj/SOAPConnectionImpl.java Added test case for patch. modules/testsuite/shared-tests/src/test/java/org/jboss/test/ws/saaj/jbws3857/MultipartContentTypeTestCase.java modules/testsuite/shared-tests/src/test/java/org/jboss/test/ws/saaj/jbws3857/SoapMultipartCheckerServlet.java modules/testsuite/shared-tests/src/test/resources/saaj/jbws3857/META-INF/beans.xml modules/testsuite/shared-tests/src/test/resources/saaj/jbws3857/WEB-INF/jboss-web.xml modules/testsuite/shared-tests/src/test/resources/saaj/jbws3857/WEB-INF/web.xml modules/testsuite/shared-tests/src/test/resources/saaj/jbws3857/test.png > Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) > ------------------------------------------------------------------------------------------------- > > Key: JBWS-3857 > URL: https://issues.jboss.org/browse/JBWS-3857 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Tomas Hofman > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. > Description of problem: > There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. > How reproducible: > always > Additional info: > It's also wrong in EAP 6.2. > EAP 6.1 is OK. > There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator

by John Ament (JIRA)

[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ] John Ament reopened JBWS-3812: ------------------------------ I'm not sure what more you're looking for. There's no way to provide a stacktrace for this as there is no way to set a valid value via the XML. > Incorrect value for ws-security.ut.validator > -------------------------------------------- > > Key: JBWS-3812 > URL: https://issues.jboss.org/browse/JBWS-3812 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4 > Reporter: John Ament > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071 > When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator > CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations. > To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3857) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3857?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3857: ---------------------------------- Assignee: R Searls (was: Tomas Hofman) > Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) > ------------------------------------------------------------------------------------------------- > > Key: JBWS-3857 > URL: https://issues.jboss.org/browse/JBWS-3857 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Tomas Hofman > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. > Description of problem: > There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. > How reproducible: > always > Additional info: > It's also wrong in EAP 6.2. > EAP 6.1 is OK. > There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

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: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1157472|https://bugzilla.redhat.com/show_bug.cgi?id=1157472] from NEW to ASSIGNED > 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.0.Beta2 > > 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.8#6338)

10 years

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