November 2009 - jbossws-issues - Jboss List Archives

[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, 1 month

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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 months

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-2845) NullPointerException deploying JAX-WS endpoint with types in target namespace ending with '#'

by Darran Lofthouse (JIRA)

NullPointerException deploying JAX-WS endpoint with types in target namespace ending with '#' --------------------------------------------------------------------------------------------- Key: JBWS-2845 URL: https://jira.jboss.org/jira/browse/JBWS-2845 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.1 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.2 -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-2846) Service.create(java.net.URL, javax.xml.namespace.QName) should throw javax.xml.ws.WebServiceException not org.jboss.ws.metadata.wsdl.WSDLException

by Darran Lofthouse (JIRA)

Service.create(java.net.URL, javax.xml.namespace.QName) should throw javax.xml.ws.WebServiceException not org.jboss.ws.metadata.wsdl.WSDLException -------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBWS-2846 URL: https://jira.jboss.org/jira/browse/JBWS-2846 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.1 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.2 Service.create(java.net.URL, javax.xml.namespace.QName) should throw javax.xml.ws.WebServiceException however is throws org.jboss.ws.metadata.wsdl.WSDLException if there is a problem retrieving the WSDL. -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-2830) EnvelopeBuilderDOM: buildSOAPHeader, reduce log level to debug for text node types.

by Daniel Bevenius (JIRA)

EnvelopeBuilderDOM: buildSOAPHeader, reduce log level to debug for text node types. ----------------------------------------------------------------------------------- Key: JBWS-2830 URL: https://jira.jboss.org/jira/browse/JBWS-2830 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.1 Reporter: Daniel Bevenius Priority: Minor buildSOAPHeader currently logs with a WARN level if a header element contains a text element, for example a new line character. The following header: <soap:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> </wsse:Security> </soap:Header> will generate the following in the warnings: 10:37:03,426 WARN [main][EnvelopeBuilderDOM] Ignore child type: 3 10:37:03,435 WARN [main][EnvelopeBuilderDOM] Ignore child type: 3 Changing the header to: <soap:Header><wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"></wsse:Security></soap:Header> will not generate any warnings at all. I think it might be nice to not have such a warning, at least not for the above situation as it might confuse users. -- 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, 2 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 November 2009