jbossws-issues June 2014

jbossws-issues@lists.jboss.org

1 participants
55 discussions

[JBoss JIRA] (JBWS-3798) @WebEndpoint not considered when building up webservicerefs

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3798: ------------------------------------- Summary: @WebEndpoint not considered when building up webservicerefs Key: JBWS-3798 URL: https://issues.jboss.org/browse/JBWS-3798 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 When building up webservice refs for a provided Service class, we currently look for 'getXYZ' methods with proper return type and select the first one with proper signature (for instance supporting WebServiceFeature). A user provided Service class could possibly have multiple getPortName methods returning the same service endpoint interface, but actually using different wsdl ports. That is possible when different @WebEndpoint annotations are specified. In such a scenario, if the user has also specified the required port QName in the webserviceref metadata (port-component-ref block, for instance in jboss-web.xml), we need to select the right method my matching the value of the @WebEndpoint annotation. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3628: --------------------------------------- Rebecca, again, please do not stick to this specific JMS endpoint scenario. If a property expansion capability is to be provided, that will have to be a generic solution applying to any (or at least to a defined set of) elements of a provided wsdl contract. Perhaps we can process the provided wsdl, expand the property references and then have CXF work on the modified wsdl? The testing automation can be dealt with; the WFLY management model allows setting system properties; we might need to expand the org.jboss.wsf.spi.deployer.Deployer / org.jboss.as.webservices.deployer.RemoteDeployer for that, but I'd rather have a valid plan for addressing this jira before working on the test automation. Thanks! > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3628: -------------------------------- The <soapjms:jndiURL> element is unmarshaled by JAXB and saved as a org.apache.cxf.transport.jms.wsdl.JndiURLType object in the extensibilityElement list of the corresponding ServiceImpl. This information is not available until the call to super.doPublish(addr) in org.jboss.wsf.stack.cxf.deployment.EndpointImpl#doPublish returns. The JndiURLType object can be checked and altered any time after the return of super.doPublish(addr) and before publishContractToFilesystem is called in org.jboss.wsf.stack.cxf.deployment.EndpointImpl#doPublish. Automated testing of the feature may be an issue. The system env in which the server is running will require the appropriate system property (e.g., -DMyTestCase="mylocalhost") for substitution be set. I am not aware of any way to set such a property on the server from the test framework. > Add property expansion capability to .wsdl files > ------------------------------------------------ > > Key: JBWS-3628 > URL: https://issues.jboss.org/browse/JBWS-3628 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: david.boeren > Assignee: R Searls > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation): > <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory> > <soapjms:jndiURL>$MY_URL</soapjms:jndiURL> > The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3670) Spring declared endpoints, AS components and injection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3670?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3670: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1062697|https://bugzilla.redhat.com/show_bug.cgi?id=1062697] from VERIFIED to CLOSED > Spring declared endpoints, AS components and injection > ------------------------------------------------------ > > Key: JBWS-3670 > URL: https://issues.jboss.org/browse/JBWS-3670 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2.4, jbossws-cxf-4.3 > > > See https://community.jboss.org/message/822796#822796 . Basically the user is trying to declare a WS endpoint using Spring configuration and having other Spring beans injected in it. The problem is the endpoint is actually being created as an AS component later after the spring context has already been built. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3773) HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3773?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3773: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1077262|https://bugzilla.redhat.com/show_bug.cgi?id=1077262] from POST to MODIFIED > HttpServletRequest in WebServiceContext and requests with WSA ReplyTo prop set > ------------------------------------------------------------------------------ > > Key: JBWS-3773 > URL: https://issues.jboss.org/browse/JBWS-3773 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > See https://issues.apache.org/jira/browse/CXF-5602 > The HttpServletContext retrieved from the WebServiceContext can have stale values when running on AS 7 (using JBossWeb) and processing WS-Addressing requests with non generic ReplyTo header props. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

← Newer
1
2
3
4
5
6
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues June 2014