May 2009 - jbossws-issues - Jboss List Archives

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

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

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

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-2418) setProperty must be overridden by all subclasses of SOAPMessage

by Christopher Logan (JIRA)

setProperty must be overridden by all subclasses of SOAPMessage --------------------------------------------------------------- Key: JBWS-2418 URL: https://jira.jboss.org/jira/browse/JBWS-2418 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Environment: WinXPsp2 Java version: 1.6.0_11,Sun Microsystems Inc. JBoss [Trinity] 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417) jbossws-3.0.1-native-2.0.4.GA (build=200803312044) JBossWeb/2.0.1.GA Reporter: Christopher Logan Hi, I'm running Jboss on WinXPsp2 and here is what is echoed to the screen during JBoss server startup: Java version: 1.6.0_11,Sun Microsystems Inc. JBoss [Trinity] 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417) jbossws-3.0.1-native-2.0.4.GA (build=200803312044) JBossWeb/2.0.1.GA I have a webservice and a webservice client deployed on the same server. The webservice was deployed without errors but when trying to invoke that webservice from a client I get setProperty must be overridden by all subclasses of SOAPMessage (stack trace attached to end of this comment) I read the previous posts about copying jboss-jaxrpc.jar, jboss-jaxws.jar & jboss-saaj.jar, I tried that but I got another error about javax/xml/ws/spi/ServiceDelegate21 not found. I removed the three files above to capture the following exception: 2008-12-11 17:14:27,437 ERROR [STDERR] javax.xml.ws.WebServiceException: java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage 2008-12-11 17:14:27,437 ERROR [STDERR] at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:404) 2008-12-11 17:14:27,437 ERROR [STDERR] at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:314) 2008-12-11 17:14:27,437 ERROR [STDERR] at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172) 2008-12-11 17:14:27,437 ERROR [STDERR] at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152) 2008-12-11 17:14:27,453 ERROR [STDERR] at $Proxy83.add(Unknown Source) 2008-12-11 17:14:27,453 ERROR [STDERR] at com.bnymellon.ws.client.CalculatorServlet.processRequest(CalculatorServlet.java:45) 2008-12-11 17:14:27,453 ERROR [STDERR] at com.bnymellon.ws.client.CalculatorServlet.doGet(CalculatorServlet.java:67) 2008-12-11 17:14:27,453 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) 2008-12-11 17:14:27,453 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 2008-12-11 17:14:27,453 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 2008-12-11 17:14:27,468 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) 2008-12-11 17:14:27,968 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619) 2008-12-11 17:14:27,968 ERROR [STDERR] Caused by: java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage 2008-12-11 17:14:27,968 ERROR [STDERR] at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:441) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:83) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:171) 2008-12-11 17:14:27,968 ERROR [STDERR] at org.jboss.ws.core.CommonSOAP11Binding.createMessage(CommonSOAP11Binding.java:59) 2008-12-11 17:14:28,468 ERROR [STDERR] at org.jboss.ws.core.CommonSOAPBinding.bindRequestMessage(CommonSOAPBinding.java:158) 2008-12-11 17:14:28,468 ERROR [STDERR] at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:291) 2008-12-11 17:14:28,468 ERROR [STDERR] at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:302) 2008-12-11 17:14:28,468 ERROR [STDERR] ... 25 more Thank you, -Christopher -- 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
2
0 / 0

[JBoss JIRA] Created: (JBWS-2308) Wrong fault handling with logical handlers

by Alessio Soldano (JIRA)

Wrong fault handling with logical handlers ------------------------------------------ Key: JBWS-2308 URL: https://jira.jboss.org/jira/browse/JBWS-2308 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-metro Affects Versions: jbossws-metro-3.0.3 Reporter: Alessio Soldano We have some issue in fault/exception handling when logical handlers are used. The jaxws/api/javax_xml_ws_handler/LogicalHandler/Client.java#ClientLogicalOutboundHandleFaultFalseTest and jaxws/api/javax_xml_ws_handler/LogicalHandler/Client.java#ClientLogicalInboundHandleFaultFalseTest are failing. Identify the testcase, reproduce in jbossws-metro testcase and fix. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBWS-1309) Support xml overrides for @PortComponent

by Jason T. Greene (JIRA)

Support xml overrides for @PortComponent ---------------------------------------- Key: JBWS-1309 URL: http://jira.jboss.com/jira/browse/JBWS-1309 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jaxws Reporter: Jason T. Greene Fix For: jbossws-2.0.0 Similar to EJB3 annotations, we need to support an xml override for the PortComponent annotation. The information will then need to be pulled from the JBoss metadata. -- 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

7
22
0 / 0

[JBoss JIRA] Created: (JBWS-2199) Injection abstraction

by Thomas Diesler (JIRA)

Injection abstraction --------------------- Key: JBWS-2199 URL: http://jira.jboss.com/jira/browse/JBWS-2199 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- 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, 3 months

3
10
0 / 0

[JBoss JIRA] Created: (JBWS-2400) Rewrite large attachment testcase

by Alessio Soldano (JIRA)

Rewrite large attachment testcase --------------------------------- Key: JBWS-2400 URL: https://jira.jboss.org/jira/browse/JBWS-2400 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-metro Reporter: Alessio Soldano The JBWS2000 testcase lives in framework but currently fails with JBossWS-Metro because of a java.lang.OutOfMemoryError on client side. This can be prevented enabling the chunked transfer which seems to be off by default with Metro: ((BindingProvider)port).getRequestContext().put("com.sun.xml.ws.transport.http.client.streaming.chunk.size", 8192); Unfortunately we still get a OOME on server side so, more generally, we should split this test and rewrite the Metro one using the available feature for large attachments (StreamingAttachment). See https://metro.dev.java.net/guide/Large_Attachments.html . -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBWS-2369) WS client uses WSSE settings from the WSDL file, ignoring client side settings

by Alan Feng (JIRA)

WS client uses WSSE settings from the WSDL file, ignoring client side settings ------------------------------------------------------------------------------ Key: JBWS-2369 URL: https://jira.jboss.org/jira/browse/JBWS-2369 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-native-3.0.4 Environment: JBoss AS 4.2.3.GA + JBoss WS 3.0.4 Native Reporter: Alan Feng When a SOAP service specifies its WSSE requirements, they are published in the WSDL, including the location and the passwords of the keystore and truststore files. These settings are usually specific to that SOAP server. On the client side, according to the wiki, the location and the password of the keystore and truststore files are specified in via JVM system properties. However, the dynamic WS client is using the WS-Security settings from the WSDL file, ignoring the client side system properties. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2410) Implement @PostConstruct and @Predestroy annotations support for POJO based endpoints (JSR 109 conformance)

by Richard Opalka (JIRA)

Implement @PostConstruct and @Predestroy annotations support for POJO based endpoints (JSR 109 conformance) ----------------------------------------------------------------------------------------------------------- Key: JBWS-2410 URL: https://jira.jboss.org/jira/browse/JBWS-2410 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-metro Affects Versions: jbossws-metro-3.0.4, jbossws-metro-3.0.3, jbossws-metro-3.0.2, jbossws-metro-3.0.1, jbossws-metro-3.0.0 Reporter: Richard Opalka Priority: Optional For inspiration see SVN commits related to JBWS-2256 for native -- 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, 3 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues May 2009