July 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, 8 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, 8 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, 8 months

4
4
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-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, 10 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

[JBoss JIRA] Created: (JBWS-2534) sun-jaxws.xml generation doesn't respect @MTOM

by Alessio Soldano (JIRA)

sun-jaxws.xml generation doesn't respect @MTOM ---------------------------------------------- Key: JBWS-2534 URL: https://jira.jboss.org/jira/browse/JBWS-2534 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-metro Reporter: Alessio Soldano >From SunJaxwsDeploymentAspect: Class beanClass = endpoint.getTargetBeanClass(); BindingType bindingType = (BindingType)beanClass.getAnnotation(BindingType.class); if (bindingType != null && bindingType.value().length() > 0) { String binding = bindingType.value(); ddEndpoint.setBinding(binding); ddEndpoint.setEnableMTOM(isMtomEnabled(binding)); } ... private static boolean isMtomEnabled(String binding) { return binding.equals(SOAPBinding.SOAP11HTTP_MTOM_BINDING) || binding.equals(SOAPBinding.SOAP12HTTP_MTOM_BINDING); } The @MTOM annotation should be considered too when enabling/disabling MTOM. -- 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
1
0 / 0

[JBoss JIRA] Created: (JBWS-2010) Select the right operation metadata when using Dispatch

by Alessio Soldano (JIRA)

Select the right operation metadata when using Dispatch ------------------------------------------------------- Key: JBWS-2010 URL: http://jira.jboss.com/jira/browse/JBWS-2010 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jbossws-native-2.0.3 Reporter: Alessio Soldano Assigned To: Alessio Soldano Inspite of the Common/ClientImpl deriving the operation metadata from the invoked method, the DispatchImpl doesn't even try to find out the operation metadata corresponding to the message that is going to be sent. For instance this may be a potential issues when using ws-security with custom target configuration. -- 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, 10 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues July 2009