August 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-3541) SubjectCreatingInterceptor.createSubject does not return principals in the correct order

by Matt Wringe (JIRA)

Matt Wringe created JBWS-3541: --------------------------------- Summary: SubjectCreatingInterceptor.createSubject does not return principals in the correct order Key: JBWS-3541 URL: https://issues.jboss.org/browse/JBWS-3541 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Matt Wringe SubjectCreatingInterceptor.createSubject(String name, String password, boolean isDigest, String nonce, String created) has to return the user principal first, and any other principals after this one. >From org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor (which the SubjectCreatingInterceptor extends): * Create a Subject representing a current user and its roles. * This Subject is expected to contain at least one Principal representing a user * and optionally followed by one or more principal Groups this user is a member of. org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor checks that the first entry is the user entry, if not it throws an error. The problem is that this method, by its definition, requires the user principal to be first, but the ordering of the credentials doesn't matter to whatever populates the credentials. SubjectCreatingInterceptor.createSubject has to check the order and rearrange the principals before return the results. Otherwise its not implementing the abstract method properly. Note: I am not trying to argue that the ordering _should_ matter and I do think its probably better for cxf to not require the ordering. -- 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

2
5
0 / 0

[JBoss JIRA] (JBWS-3511) WSDL parsing exception: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.

by Biljana Kramer (JIRA)

Biljana Kramer created JBWS-3511: ------------------------------------ Summary: WSDL parsing exception: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. Key: JBWS-3511 URL: https://issues.jboss.org/browse/JBWS-3511 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Environment: WSRP on EPP 5.2.1 Reporter: Biljana Kramer When trying to create consumer by setting Producer WSDL URL http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1... the following Exception is thrown in server.log file (this is all done from EPP 5.2.1): 2012-06-05 14:59:15,051 WARN [org.jboss.util.xml.JBossEntityResolver] (http-10.33.1.120-8080-4) Trying to resolve systemId as a non-file URL: http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1... 2012-06-05 14:59:15,580 ERROR [STDERR] (http-10.33.1.120-8080-4) [Fatal Error] wsrp_v1_bindings.wsdl:1:50: White spaces are required between publicId and systemId. 2012-06-05 14:59:15,586 INFO [org.gatein.wsrp.services.SOAPServiceFactory] (http-10.33.1.120-8080-4) Couldn't access WSDL information athttp://wsrp.netunitysoftware.com/WSRPTestService/WSRPTestService.asmx?O.... Service won't be available javax.xml.ws.WebServiceException: org.jboss.ws.metadata.wsdl.WSDLException: javax.wsdl.WSDLException: WSDLException (at /wsdlefinitions/import): faultCode=PARSER_ERROR: Problem parsing 'http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1...'.: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. ... 2012-06-05 14:59:15,653 INFO [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-10.33.1.120-8080-4) WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. >> sourceId=pbG049fd3d3_2dff75_2d4581_2da5f6_2dd097be693be8:j_id37:status[severity=(ERROR 2), summary=(javax.xml.ws.WebServiceException: org.jboss.ws.metadata.wsdl.WSDLException: javax.wsdl.WSDLException: WSDLException (at /wsdlefinitions/import): faultCode=PARSER_ERROR: Problem parsing 'http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1...'.: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.), detail=(org.jboss.ws.metadata.wsdl.WSDLException: javax.wsdl.WSDLException: WSDLException (at /wsdlefinitions/import): faultCode=PARSER_ERROR: Problem parsing 'http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1...'.: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.)] It seems the error might be caused by the fact that the WSDL URL redirects to an https URL. -- 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
9
0 / 0

[JBoss JIRA] (JBWS-3524) Resolve system property references in jboss-webservices.xml

by Kyle Lape (JIRA)

12 years, 3 months

2
2
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] (JBWS-3509) Convert project to use i18n logging and exceptions

by James Perkins (JIRA)

James Perkins created JBWS-3509: ----------------------------------- Summary: Convert project to use i18n logging and exceptions Key: JBWS-3509 URL: https://issues.jboss.org/browse/JBWS-3509 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: James Perkins As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- 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
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues August 2012