June 2014 - jbossws-issues - Jboss List Archives

[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: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1111048|https://bugzilla.redhat.com/show_bug.cgi?id=1111048] from NEW to CLOSED > 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 > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > > 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.2.6#6264)

10 years, 6 months

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 updated JBWS-3802: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110631, https://bugzilla.redhat.com/show_bug.cgi?id=1111046, https://bugzilla.redhat.com/show_bug.cgi?id=1111048 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1110631, https://bugzilla.redhat.com/show_bug.cgi?id=1111046) > 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 > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > > 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.2.6#6264)

10 years, 6 months

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 updated JBWS-3802: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110631, https://bugzilla.redhat.com/show_bug.cgi?id=1111046 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1110631) > 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 > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > > 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.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] R Searls updated JBWS-3628: --------------------------- Attachment: JBWS-3628-JBossWS-WSDLFactory-tentative-patch.txt Proposed patch to CXF for JBossWS to provide a custom WSDLFactory. > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3628-JBossWS-WSDLFactory-tentative-patch.txt, JBWS-3628-tentative-patch-from-Rebecca.txt > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3628: -------------------------------- I recant. I can override protected methods of com.ibm.wsdl.xml.WSDLReaderImpl, that makes things much easier and cleaner to customize. > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3628-tentative-patch-from-Rebecca.txt > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3628: -------------------------------- CXF would need only a minor modification in order for us to register an custom WSDLFactoryImpl through the bus for CXF's WSDLManager to reference. Our WSDLFactoryImpl class would override the newWSDLReader method and return a custom WSDLReaderImpl class. It would be most desirable to subclass com.ibm.wsdl.xml.WSDLReaderImpl and override select parsing methods, however is this not possible because the methods of interest are "protected". I see two solutions. One, copy the contents of com.ibm.wsdl.xml.WSDLReaderImpl into our WSDLReaderImpl class and make the desired modifications to the protected methods. Two, in our WSDLFactoryImpl override method newDefinition() and return a custom impl of DefinitionImpl and in DefinitionImpl override methods like createService() and return a custom ServiceImpl class (and the like) that does our bidding. This would allow com.ibm.wsdl.xml.WSDLReaderImpl to be used as is. Because of the nature of what we are currently customizing I am more in favor of option one. This provides us full access to the wsdl contents with the smallest number of classes that needs to be maintained. Option two seems like over kill and requires a larger number of custom classes to be maintained by us. What are your thoughts? > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3628-tentative-patch-from-Rebecca.txt > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

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

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3803: ------------------------------------- Summary: 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 Security Level: Public (Everyone can see) Components: jbossws-cxf, productivity Reporter: Alessio Soldano 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.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3628: --------------------------------------- OK, I see. So we can't "fool" CXF into using a different location for the wsdl. Btw, I also remember that CXF has a wsdl cache mechanism that is based on the wsdl url, so playing with the wsdl location url might definitely be risky. The idea of running a filter at the time CXF parses the wsdl into the WSDL4J Definition model is interesting; something I've noticed in the patch is that is applies to the JMS wsdl extensibility element only. So we'd need to clarify in advance which elements actually support property expansion and which do not. Something I've been thinking about is why don't we run the filter directly at WSDL4J level? javax.wsdl.factory.WSDLFactory (which is used by CXF to parse the wsdl) lets us have a different implementation of WSDLFactory (see newInstance() and findFactoryImplName() methods). We could have a custom WSDLFactory impl that runs our filters and eventually delegates to the default WSDLFactory impl (or to what would have been resolved before, but that's an impl detail). The filtering could either be performed through pluggable filters as you did in your last patch for cxf, or (better, I think) be StAX / DOM based on the whole document (depends on which readWSDL method flavor is called). The advantage are no need to have changes in CXF and a solution that applies to any component relying on the WSDLReader. > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3628-tentative-patch-from-Rebecca.txt > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3628: ---------------------------------- Attachment: JBWS-3628-tentative-patch-from-Rebecca.txt > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > Attachments: JBWS-3628-tentative-patch-from-Rebecca.txt > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

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 updated JBWS-3802: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110631 > 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 > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > > 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.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