May 2012 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3426) Factor out EndpointService logic and update EndpointServiceDA

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3426: ------------------------------------- Summary: Factor out EndpointService logic and update EndpointServiceDA Key: JBWS-3426 URL: https://issues.jboss.org/browse/JBWS-3426 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-native Affects Versions: jbossws-cxf-4.0.1, jbossws-native-4.0.1 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.0.2, jbossws-native-4.0.2 As a consequence of having moved the registration of endpoints into EndpointRegistry in the AS7 EndpointService, the JBossWS Shared Testsuite test for the EndpointPublisher fails due to the published endpoint not being registered. That's because the ServiceTarget is not available in that case, hence the EndpointService is not installed. This needs to be solved by having the logic of the EndpointService being invoked differently by the EndpointServiceDA when there's not ServiceTarget available (the endpoint registration is still possible, as well as looking up the current mbeanserver, etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
7
0 / 0

[JBoss JIRA] (JBWS-3396) Evaluate partial generation of jbossws-cxf.xml descriptor

by Alessio Soldano (Created) (JIRA)

Evaluate partial generation of jbossws-cxf.xml descriptor --------------------------------------------------------- Key: JBWS-3396 URL: https://issues.jboss.org/browse/JBWS-3396 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano See http://community.jboss.org/message/640779#640779 . Basically the issue with the need for user to specify every endpoint in the jbossws-cxf.xml, while in some case the info might come from the metadata created from the web.xml / annotations. At least we could have defaults. The same applies to defaults for the address attribute in jaxws:endpoint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
2
0 / 0

[JBoss JIRA] Created: (JBWS-2671) org.jboss.ws.core.soap.SOAPMessageImpl does not implement setProperty and getProperty methods

by Edward Pilipczuk (JIRA)

org.jboss.ws.core.soap.SOAPMessageImpl does not implement setProperty and getProperty methods ---------------------------------------------------------------------------------------------- Key: JBWS-2671 URL: https://jira.jboss.org/jira/browse/JBWS-2671 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.1 Environment: Windows XP, JBoss AS 4.2.3GA (JBossWS upgraded to 3.1.1GA), JDK 1.6.0_14 Reporter: Edward Pilipczuk Priority: Critical I am trying to implement SOAPClient that invokes WebService by use of Dispatch<Object> interface with JAXB. When trying to write the code like in the following tutorial --> http://www.omii.ac.uk/wiki/JaxWsTutorial#section-JaxWsTutorial-Example6.J... I got an exception as below: 13:55:58,453 ERROR [DispatchImpl] Cannot dispatch message java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage at javax.xml.soap.SOAPMessage.setProperty(Unknown Source) at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:87) at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:169) at org.jboss.ws.core.jaxws.client.DispatchSOAPBinding.getRequestMessage(DispatchSOAPBinding.java:121) at org.jboss.ws.core.jaxws.client.DispatchImpl.getRequestMessage(DispatchImpl.java:450) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:183) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:170) at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:133) at application.package.SOAPClient.process(SOAPClient.java:254) Looking into the source of the classes listed in stacktrace I found that SOAPMessageImpl class does not implement required setProperty() and getProperty() methods. -- 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

12 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBWS-1439) Jdk 1.6.0 Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage"

by Denis Angleton (JIRA)

Jdk 1.6.0 Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage" -------------------------------------------------------------------------------------------------- Key: JBWS-1439 URL: http://jira.jboss.com/jira/browse/JBWS-1439 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-1.0.4 Environment: Jboss 4.0.5.GA Java 1.6.0 Reporter: Denis Angleton Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage" In the abstract class javax.xml.soap.SOAPMessage which is now shipped with the jdk, the implementation of setProperty is as follows: public void setProperty(String property, Object value) throws SOAPException { throw new UnsupportedOperationException("setProperty must be overridden by all subclasses of SOAPMessage"); } in the constructor of org.jboss.ws.soap.SOAPMessageImpl it calls the super methods setProperty(CHARACTER_SET_ENCODING, "UTF-8"); setProperty(WRITE_XML_DECLARATION, false); This results in the exception being thrown. -- 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

12 years, 2 months

19
33
0 / 0

[JBoss JIRA] (JBWS-3441) Support CDI interceptors for POJO JAX-WS services

by Paul Robinson (JIRA)

Paul Robinson created JBWS-3441: ----------------------------------- Summary: Support CDI interceptors for POJO JAX-WS services Key: JBWS-3441 URL: https://issues.jboss.org/browse/JBWS-3441 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson CDI provides a way of doing method interception. This works for POJOs and EJBs. For more information, see the CDI 1.0 specification from here: http://jcp.org/en/jsr/detail?id=299. Page 74 of the PDF (printed page number 67) specifies the interceptor features. Here's an example of how I would have expected this to work with a JAX-WS service implemented as a POJO rather than an EJB: https://github.com/weld/core/pull/154/files This does not work in JBossWS. See Richard Opalka's comment: {quote} I reviewed the test case and I confirm it won't work. CDI interceptors won't work on JAXWS POJOs because of current design. The reason is JAXWS POJO invocation is not using AS7 interceptor chains at all. It just reuses AS7 component instances (to see injections). {quote} CDI @Inject does work. I'm not sure about other CDI features. I am creating a framework that provides annotation support for transactional Web services. I am using CDI to implement this. My motivation for this feature is that I want to fully support JAX-WS. Currently my users must implement their Web services as EJBs for my annotations to work. With CDI and JEE6, the movement seems to be away from EJB and towards POJOs. Therefore, I would expect more JBossWS users to take the POJO approach, rather than the EJB approach. I'm sure you guys would have a better idea than I have, so please let me know what you think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
8
0 / 0

[JBoss JIRA] (JBWS-3479) Implement @org.jboss.ws.api.annotation.WebContext support for POJO endpoints

by Richard Opalka (JIRA)

Richard Opalka created JBWS-3479: ------------------------------------ Summary: Implement @org.jboss.ws.api.annotation.WebContext support for POJO endpoints Key: JBWS-3479 URL: https://issues.jboss.org/browse/JBWS-3479 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Richard Opalka Fix For: jbossws-cxf-4.1, jbossws-native-4.1 We support @WebContext on EJB endpoints now. Since Servlet 3.0 spec allows web deployments without web.xml it is worth to support this annotation also on POJO WS endpoints. There are however two restrictions that must be ensured. If there are multiple WS endpoints in web archive all annotated with @WebContext annotation then the following restriction must apply: - contextRoot value must be the same for all @WebContext annotated endpoints - virtualHost value must be the same for all @WebContext annotated endpoints - if there's provided jboss-web.xml or jboss-webservices.xml with context root in deployment this DD driven context root will have higher priority than context root specified in annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-3166) Review the code which enable the mtom threshold configuration from DDEndpoint in both spring and without spring stack

by Jim Ma (JIRA)

Review the code which enable the mtom threshold configuration from DDEndpoint in both spring and without spring stack ---------------------------------------------------------------------------------------------------------------------- Key: JBWS-3166 URL: https://jira.jboss.org/browse/JBWS-3166 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-native-3.4.0.CR1 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.0 We can probably add some more convenient APIs in cxf to configure the MTOMFeature easily. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBWS-3172) SpringBusHolder.createBus(URL location) does not support the bean class annotated with @PostConstruct

by Jim Ma (JIRA)

SpringBusHolder.createBus(URL location) does not support the bean class annotated with @PostConstruct ------------------------------------------------------------------------------------------------------ Key: JBWS-3172 URL: https://jira.jboss.org/browse/JBWS-3172 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-native-3.4.0.CR1 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.0 SpringBusHolder has the same issue with https://issues.apache.org/jira/browse/CXF-3157. Look at if load the jbossws-cxf.xml with FileSystemXmlApplicationContext can fix this issue. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2710) Provide testcase for WS-Trust (server side) and WS-SecureConversation

by Alessio Soldano (JIRA)

Provide testcase for WS-Trust (server side) and WS-SecureConversation --------------------------------------------------------------------- Key: JBWS-2710 URL: https://jira.jboss.org/jira/browse/JBWS-2710 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano http://cwiki.apache.org/CXF20DOC/ws-trust.html http://cwiki.apache.org/CXF20DOC/ws-secureconversation.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

12 years, 3 months

1
4
0 / 0

[JBoss JIRA] (JBWS-3504) Add ability to configure the CXF policy alternative selector on server side

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3504: ------------------------------------- Summary: Add ability to configure the CXF policy alternative selector on server side Key: JBWS-3504 URL: https://issues.jboss.org/browse/JBWS-3504 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-4.1 As a consequence of JBWS-3149, JBossWS-CXF defaults to MaximalAlternativeSelector on server side. We need an option for letting users configure a different behavior if they really want to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
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 2012