December 2009 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-2210) CXF Username Token JAAS integration

by Alessio Soldano (JIRA)

CXF Username Token JAAS integration ----------------------------------- Key: JBWS-2210 URL: http://jira.jboss.com/jira/browse/JBWS-2210 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf, ws-security Reporter: Alessio Soldano Assigned To: Alessio Soldano Ideally we would need the CXF stack to have the same degree of JAAS integration the native stack has (i.e. authentication and authorization delegated to JBoss Security). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (JBWS-2571) Mode.INOUT parameter not generated

by Alessio Soldano (JIRA)

Mode.INOUT parameter not generated ---------------------------------- Key: JBWS-2571 URL: https://jira.jboss.org/jira/browse/JBWS-2571 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Wehn running wsconsume (wsdl2java) on the jaxws/holder framework testcase we don't get a INOUT parameter for the addInOut method (while we get it with wsimport). We need to investigate where is the issue here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWS-2640) UsernameToken does not correctly handle "Created" element from wsse:Security soap header

by MrTed MrTed (JIRA)

UsernameToken does not correctly handle "Created" element from wsse:Security soap header ---------------------------------------------------------------------------------------- Key: JBWS-2640 URL: https://jira.jboss.org/jira/browse/JBWS-2640 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-native-3.1.1 Environment: AS: jboss-4.2.3.GA on Windows XP jbossws-native-3.1.1.GA Reporter: MrTed MrTed UsernameToken does not correctly handle "Created" element from wsse:Security soap header. Oasis standard describes "Created" element in the following way: /wsse:UsernameToken/wsu:Created The optional <wsu:Created> element specifies a timestamp used to indicate the creation time. It is defined as part of the <wsu:Timestamp> definition. The solution - Constants.WSU_NS should be used instead of Constants.WSSE_NS. "Created" element is described in http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utilit... In the code org.jboss.ws.extensions.security.element.UsernameToken "Created" element is recived via: Iterator<Element> itCreated = DOMUtils.getChildElements(element, new QName(Constants.WSSE_NS, "Created")); instead it should be: Iterator<Element> itCreated = DOMUtils.getChildElements(element, new QName(Constants.WSU_NS, "Created")); The same goes for line: child = doc.createElementNS(Constants.WSSE_NS, Constants.WSSE_PREFIX + ":" + "Created"); should be: child = doc.createElementNS(Constants.WSU_NS, Constants.WSU_PREFIX + ":" + "Created"); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (JBWS-2718) Loading artifacts from WEB-INF/wsdl1 fails

by Alessio Soldano (JIRA)

Loading artifacts from WEB-INF/wsdl1 fails ------------------------------------------ Key: JBWS-2718 URL: https://jira.jboss.org/jira/browse/JBWS-2718 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Alessio Soldano Fix For: jbossws-cxf-3.2.1, jbossws-native-3.2.1, jbossws-metro-3.2.1 > how is your pojo endpoint annotated? @javax.jws.WebService( name = "WSRPV1MarkupPortType", serviceName = "WSRPV1Service", portName = "WSRPMarkupService", targetNamespace = "urn:oasis:names:tc:wsrp:v1:wsdl", wsdlLocation = "/WEB-INF/wsdl1/wsrp_services.wsdl", endpointInterface = "org.oasis.wsrp.v1.WSRPV1MarkupPortType" ) public class MarkupEndpoint extends WSRPBaseEndpoint implements WSRPV1MarkupPortType > And what exception you get exactly? 15:09:30,232 INFO [TomcatDeployer] deploy, ctxPath=/wsrp-producer, warUrl=.../tmp/deploy/tmp7635205325184845617wsrp-producer-exp.war/ 15:09:36,999 INFO [WSDLFilePublisher] WSDL published to: file:/Users/claprun/Dev/jboss-4.2.3.GA-jdk6/server/default/data/wsdl/wsrp-producer.war/wsrp_services.wsdl 15:09:37,013 ERROR [MainDeployer] Could not start deployment: file:/Users/claprun/Dev/jboss-4.2.3.GA-jdk6/server/default/deploy/wsrp-producer.war org.jboss.ws.WSException: Cannot publish wsdl to: /Users/claprun/Dev/jboss-4.2.3.GA-jdk6/server/default/data/wsdl/wsrp-producer.war/wsrp_services.wsdl at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:143) at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52) at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:118) at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97) at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90) at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188) at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy45.start(Unknown Source) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225) Caused by: java.io.IOException: Cannot get URL for: WEB-INF/wsdl/wsrp_v1_types.xsd at org.jboss.wsf.common.URLLoaderAdapter.findChild(URLLoaderAdapter.java:106) at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:99) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:242) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlImports(WSDLFilePublisher.java:192) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlImports(WSDLFilePublisher.java:188) at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:126) ... 32 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
15
0 / 0

[JBoss JIRA] Created: (JBWS-1672) SunRI does not respect @HandlerChain on client SEI

by Thomas Diesler (JIRA)

SunRI does not respect @HandlerChain on client SEI -------------------------------------------------- Key: JBWS-1672 URL: http://jira.jboss.com/jira/browse/JBWS-1672 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: integration-sunri Reporter: Thomas Diesler Fix For: jbossws-2.1.0 tests-run-internal: [junit] Running org.jboss.test.ws.jaxws.samples.handlerchain.HandlerChainTestCase [junit] FIXME: [JBWS-1671] SunRI client handler cannot set mime header [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.209 sec [junit] Test org.jboss.test.ws.jaxws.samples.handlerchain.HandlerChainTestCase FAILED @WebService(name="Endpoint") @SOAPBinding(style = SOAPBinding.Style.RPC) @HandlerChain(file = "jaxws-handlers-client.xml") // relative path from the class file public interface EndpointWithHandlerChain { public String echo(String input); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
12
0 / 0

[JBoss JIRA] Created: (JBWS-2774) Cleaned up dependency in cxf client module

by Jim Ma (JIRA)

Cleaned up dependency in cxf client module ------------------------------------------ Key: JBWS-2774 URL: https://jira.jboss.org/jira/browse/JBWS-2774 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-3.2.1 There is no aegis related jar files in client library, look at if we need to add other jar files to enable ws-*, aegis etc. Look at if we also can remove the geronimo-*.jar shipped in cxf and use Sun equivalent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWS-2021) app-client with client and server not sharing the same filesystem

by Alessio Soldano (JIRA)

app-client with client and server not sharing the same filesystem ----------------------------------------------------------------- Key: JBWS-2021 URL: http://jira.jboss.com/jira/browse/JBWS-2021 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Alessio Soldano Assigned To: Alessio Soldano Fix For: jbossws-native-2.0.5 Some jax-rpc tests using app-client were failing due to JBVFS-17. This however pointed out that our current implementation for app-client is supposed to work only when server and client share the same filesystem (see the referenced forum thread). We should think about something like a buffering virtual file implementation that eagerly reads the referenced resources from the file system before the metadata it is contained in is bound to the JNDI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWS-2656) no soap 1.2 inline multireferences support

by Wojciech Oczkowski (JIRA)

no soap 1.2 inline multireferences support ------------------------------------------ Key: JBWS-2656 URL: https://jira.jboss.org/jira/browse/JBWS-2656 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.0.2 Environment: debian, jboss-4.2, sun-java-6 Reporter: Wojciech Oczkowski jbossws doesn't seem to support inline multireferences from soap 1.2 while consuming webservices from other enviroments (php for example) result like: <item> <name>item1</name> <product enc:id="ref1"> <name>product1</name> </product> </item> <item> <name>item2</name> <product enc:ref="#ref1"/> </item> is unmarshaled with item2 object with product object filled with null's -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2650) Evaluate providing a maven plugin for wsconsume/wsprovide

by Alessio Soldano (JIRA)

Evaluate providing a maven plugin for wsconsume/wsprovide --------------------------------------------------------- Key: JBWS-2650 URL: https://jira.jboss.org/jira/browse/JBWS-2650 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: tools-jaxws Reporter: Alessio Soldano -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBWS-2572) Marshalling JAXB element over SOAPHeader produces an empty element

by Jose Antonio (JIRA)

Marshalling JAXB element over SOAPHeader produces an empty element ------------------------------------------------------------------ Key: JBWS-2572 URL: https://jira.jboss.org/jira/browse/JBWS-2572 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.0.5 Environment: JDK 1.6, JBoss 4.2.3, Ubuntu Linux 8.10 Reporter: Jose Antonio Hello, I'm trying to set some ws security headers manually in a handler for a Web service client and server. I have generated JAXB bindings from WS Security schema and in the client, I generate a Security element with a UserNameToken inside. Then, I try to put it in the headers in my handler like this: public boolean handleMessage(SOAPMessageContext context) { ............................................ ObjectFactory fact = new ObjectFactory(); JAXBElement<SecurityHeaderType> secHead = fact.createSecurity(sec); Marshaller marshaller = ctx.createMarshaller(); SOAPEnvelope envelope = context.getMessage().getSOAPPart().getEnvelope(); SOAPHeader header = (envelope.getHeader() == null) ? envelope.addHeader() : envelope.getHeader(); marshaller.marshal(secHead,header); sec is a JAXB element with the Security element content and is not null and not empty. If I execute my client with this handler in local, using JAX-WS RI 2.1, I get the expected behavior and I get a header with a Security element and a UserNameToken inside. But when I deploy my client in JBoss and try to execute it, I get an empty Security element. There is no UserNameToken inside. I tried the following workaround and it works for JBoss: DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = builder.newDocument(); marshaller.marshal(secHead, doc); SOAPFactory sFact = SOAPFactory.newInstance(); header.appendChild(sFact.createElement(doc.getDocumentElement())); However, it's not the optimum way of doing it, since I need to create two factories and an intermediary document only to append a child to a header, while it could be done only with one sencence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues December 2009