April 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3789) Enable WS-Security streaming (StAX) support

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3789?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3789: ---------------------------------- Description: WSS4J 2.0 comes with streaming (StAX) WS-Security support: http://ws.apache.org/wss4j/streaming.html We need to verify it's working with the JBossWS integration, test & run benchmarks and possibly turn it on by default. See also: http://santuario.apache.org/streaming-xml-security.html http://coheigea.blogspot.ie/2014/04/apache-santuario-xml-security-for-jav... was: WSS4J 2.0 comes with streaming (StAX) WS-Security support: http://ws.apache.org/wss4j/streaming.html We need to verify it's working with the JBossWS integration, test & run benchmarks and possibly turn it on by default. > Enable WS-Security streaming (StAX) support > ------------------------------------------- > > Key: JBWS-3789 > URL: https://issues.jboss.org/browse/JBWS-3789 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > WSS4J 2.0 comes with streaming (StAX) WS-Security support: http://ws.apache.org/wss4j/streaming.html > We need to verify it's working with the JBossWS integration, test & run benchmarks and possibly turn it on by default. > See also: > http://santuario.apache.org/streaming-xml-security.html > http://coheigea.blogspot.ie/2014/04/apache-santuario-xml-security-for-jav... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3789) Enable WS-Security streaming (StAX) support

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3789: ------------------------------------- Summary: Enable WS-Security streaming (StAX) support Key: JBWS-3789 URL: https://issues.jboss.org/browse/JBWS-3789 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Fix For: jbossws-cxf-5.0 WSS4J 2.0 comes with streaming (StAX) WS-Security support: http://ws.apache.org/wss4j/streaming.html We need to verify it's working with the JBossWS integration, test & run benchmarks and possibly turn it on by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3686) Upgrade to Apache CXF 3.0.0

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3686?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3686: ---------------------------------- Description: Apache CXF 3 migration guide: http://cxf.apache.org/docs/30-migration-guide.html WSS4J 2 migration guide: http://ws.apache.org/wss4j/migration.html was:http://cxf.apache.org/docs/30-migration-guide.html > Upgrade to Apache CXF 3.0.0 > --------------------------- > > Key: JBWS-3686 > URL: https://issues.jboss.org/browse/JBWS-3686 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > Apache CXF 3 migration guide: http://cxf.apache.org/docs/30-migration-guide.html > WSS4J 2 migration guide: http://ws.apache.org/wss4j/migration.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3788) Add catalog testcase

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3788: ------------------------------------- Summary: Add catalog testcase Key: JBWS-3788 URL: https://issues.jboss.org/browse/JBWS-3788 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Fix For: jbossws-cxf-5.0 We need a testcase that explicitly verifies usage of jaxws catalog both in the jbossws-cxf-client jar / jaxws-client module and in a user deployment. As a consequence of having moved to Apache CXF 3.0.0 (JBWS-3686), I'm seeing warnings like the following because of the change at [1]: {noformat} 10:48:16,235 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-4) Catalog found at jar:file:/dati/jboss-as-7.2.0.Final/build/target/jboss-as-7.2.0.Final/modules/system/layers/base/org/jboss/ws/jaxws-client/main/jbossws-cxf-client.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar. 10:48:16,235 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-4) Catalog found at jar:file:/dati/jboss-as-7.2.0.Final/build/target/jboss-as-7.2.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-tools-wsdlto-frontend-jaxws.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar. {noformat} We need to clarify this a bit. [1] https://github.com/apache/cxf/commit/7823e995 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3750: -------------------------------- Code changes are required in artifacts, jbossws-common, jbossws-cxf-server, jbossws-spi and wildfly-webservices-server-integration. I've created the following branched repos for these changes. https://svn.jboss.org/repos/jbossws/common/branches/rsearls https://svn.jboss.org/repos/jbossws/spi/branches/rsearls https://svn.jboss.org/repos/jbossws/stack/cxf/branches/rsearls > Add ability to rewrite path in WSDL URL references > -------------------------------------------------- > > Key: JBWS-3750 > URL: https://issues.jboss.org/browse/JBWS-3750 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Kyle Lape > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ] Alessio Soldano edited comment on JBWS-3750 at 4/24/14 4:58 AM: ---------------------------------------------------------------- Rebecca, I'm not sure I follow your analysis here, perhaps you can clarify it a bit. My idea would be this new feature to be something in JBossWS / WFLY / EAP, possibly with no changes to CXF, unless that's strictly required. This would likely be an extension to the current address rewrite mechanism we have in JBossWS, see org.jboss.wsf.stack.cxf.metadata.MetadataBuilder#processAddressRewrite(...) method. If we had a "path" element in the ServerConfig that comes from the AS webservices subsystem management model, that could be used by the SoapAddressRewriteHelper to create the rewritten address. The problem I can see with this approach, atm, is that it won't work properly for the scenario in which auto rewrite is on (that is when the webservice host in the server config is "jbossws.undefined.host"), but we could probably accept this limitation. was (Author: asoldano): Rebecca, I'm not sure I follow your analysis here, perhaps you can clarify it a bit. My idea would be this new feature to be something in JBossWS / WFLY / EAP, possibly with no changes to CXF, unless that's strictly required. This would likely be an extension to the current address rewrite mechanism we have in JBossWS, see org.jboss.wsf.stack.cxf.metadata.MetadataBuilder#processAddressRewrite(...) method. If we had a "path" element in the ServerConfig that comes from the AS webservices subsystem management model, that could be used by the SoapAddressRewriteHelper to create the rewritten address. The problem I can see with that approach, atm, is this won't work properly for the scenario in which auto rewrite is on (that is when the webservice host in the server config is "jbossws.undefined.host"), but we could probably accept this limitation. > Add ability to rewrite path in WSDL URL references > -------------------------------------------------- > > Key: JBWS-3750 > URL: https://issues.jboss.org/browse/JBWS-3750 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Kyle Lape > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3750: --------------------------------------- Rebecca, I'm not sure I follow your analysis here, perhaps you can clarify it a bit. My idea would be this new feature to be something in JBossWS / WFLY / EAP, possibly with no changes to CXF, unless that's strictly required. This would likely be an extension to the current address rewrite mechanism we have in JBossWS, see org.jboss.wsf.stack.cxf.metadata.MetadataBuilder#processAddressRewrite(...) method. If we had a "path" element in the ServerConfig that comes from the AS webservices subsystem management model, that could be used by the SoapAddressRewriteHelper to create the rewritten address. The problem I can see with that approach, atm, is this won't work properly for the scenario in which auto rewrite is on (that is when the webservice host in the server config is "jbossws.undefined.host"), but we could probably accept this limitation. > Add ability to rewrite path in WSDL URL references > -------------------------------------------------- > > Key: JBWS-3750 > URL: https://issues.jboss.org/browse/JBWS-3750 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Kyle Lape > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > > Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 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: ---------------------------------- Assignee: R Searls (was: Alessio Soldano) > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 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: --------------------------------------- Rebecca, sure, the client has power to change this specific value, as well as using a completely different wsdl contract. The JMS case here is probably also not a perfect fit for the new feature request, as for pure JMS endpoints the wsdl contract is actually not published at all (that's also why in the testcase you mentioned the client is retrieving the wsdl from as a resource in the client jar). This said, it could still be useful to support a server side property expansion mechanism; the user could deploy a contract first endpoint with something like @foo@ in its wsdl, then the jbossws deployer would expand that by reading the value of the "foo" system property when publishing the endpoint wsdl. Do you see what I mean? > 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: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 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: -------------------------------- There is currently away for the client to access and change the contexts of soapjms:jndiURL before the endpoint is called. (The contents of the source WSDL is not altered). The value of soapjms:jndiURL is set in Properties props = conduit.getJmsConfig().getJndiTemplate().getEnvironment(); where conduit is retrieved by JMSConduit conduit = (JMSConduit)ClientProxy.getClient(proxy).getConduit(); The following test can be used to see the default contents of props. https://svn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/cxf... At line 99 the returned value of "props" is props[0] key="java.naming.provider.url" value="$MY_URL" props[1] key="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory" As a test I changed <soapjms:jndiURL>remote://@jboss.bind.address@:4447</soapjms:jndiURL> to <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> in file https://svn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/cxf... and in JMSHTTPEndpointDeploymentTestCaseForked.java added the following code after line 101 String value = (String)props.get("java.naming.provider.url"); if (value.equals("$MY_URL")){ props.put("java.naming.provider.url", "remote://localhost:4447"); } The test ran properly. > 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: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

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