[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3750:
--------------------------------
The CXF changes are available in version 3.0.1 and 2.7.12
> Add ability to rewrite path in WSDL URL references
> --------------------------------------------------
>
> Key: JBWS-3750
> URL: https://issues.jboss.org/browse/JBWS-3750
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Reporter: Kyle Lape
> Assignee: R Searls
> Fix For: jbossws-cxf-5.0
>
>
> Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3750:
--------------------------------
CXF has accepted the patch for CXF-5792 with some minor changes.
The refactored WSDLGetUtils was accepted with minor changes.
The proposed changes to WSDLGetInterceptor were not accepted. Instead
WSDLGetInterceptor was changed to allow a custom WSDLGetUtils class to be passed
in through a contextual property,
WSDLGetUtils utils = (WSDLGetUtils)message.getContextualProperty(WSDLGetUtils.class.getName());
These changes have been integrated into the CXF master branch.
I have changed WSDLSoapAddressRewriteInterceptor, WSDLSoapAddressRewriteUtils and EndpointImpl in accordance
with the CXF changes, confirmed they work, and check-in the code ( https://svn.jboss.org/repos/jbossws/stack/cxf/branches/rsearls).
> Add ability to rewrite path in WSDL URL references
> --------------------------------------------------
>
> Key: JBWS-3750
> URL: https://issues.jboss.org/browse/JBWS-3750
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Reporter: Kyle Lape
> Assignee: R Searls
> Fix For: jbossws-cxf-5.0
>
>
> Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[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:
---------------------------------------
I agree on the complexity of plugging into CXF processing of wsdl. That's why I suggested considering feeding CXF with an already modified wsdl document. Post-processing the wsdl after org.jboss.wsf.stack.cxf.deployment.EndpointImpl call to super.doPublish(addr) is not going to work, as CXF would run using the wsdl with references to the properties (not expanded).
Perhaps we can pre-process the wsdl (as an XML doc, not as a javax.wsdl.Definition) to expand the properties, write it somewhere, set it into the EndpointImpl (see e.g. NonSpringBusHolder#configure(...) method) and let CXF rely on it. I'm saying "perhaps", as I fear there might be some places where CXF is looking for @WebService annotations and directly getting the wsdlLocation, but we should verify and perhaps that's not correct when the EndpointImpl wsdlLocation is set).
> 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.6#6264)
10 years, 6 months
[JBoss JIRA] (JBWS-3800) Review the required elements under webservice subystem
by Jim Ma (JIRA)
Jim Ma created JBWS-3800:
----------------------------
Summary: Review the required elements under webservice subystem
Key: JBWS-3800
URL: https://issues.jboss.org/browse/JBWS-3800
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-integration
Affects Versions: jbossws-cxf-4.3
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: jbossws-cxf-5.0
>From jboss-as-webservices12.xsd, all elements' minOccurs under webserivce subsystem is "0". When remove all the elements under subsytem, it fails to deploy webservice endpoint:
11:26:24,723 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."jaxws-samples-schemavalidation.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-samples-schemavalidation.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jaxws-samples-schemavalidation.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.NullPointerException
at org.jboss.ws.common.deployment.EndpointMetricsDeploymentAspect.start(EndpointMetricsDeploymentAspect.java:49)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
... 5 more
11:26:24,736 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0014: Operation ("deploy") failed - address: ([("deployment" => "jaxws-samples-schemavalidation.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jaxws-samples-schemavalidation.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-samples-schemavalidation.war\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"jaxws-samples-schemavalidation.war\"
Caused by: java.lang.NullPointerException"}}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[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:
--------------------------------
A generic solution is for JBossWS to have a DefinitionVistor class that preforms
post-processing of an endpoint's javax.wsdl.Definition data before the wsdl data is
written by CXF. This utility would run after the return of super.doPublish(addr) and
before publishContractToFilesystem in org.jboss.wsf.stack.cxf.deployment.EndpointImpl.
We should not attempt to insert this processing into the CXF code base. The JAXB processing
of this is quite deep in CXF's doPublish processing path. CXF is using the com.ibm.wsdl.DefinitionImpl
of javax.wsdl.Definition which is another good reason not to muck with that code but to do post processing.
> 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)
10 years, 6 months
[JBoss JIRA] (JBWS-3799) Upgrade to JAXB 2.2.7
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3799:
-------------------------------------
Summary: Upgrade to JAXB 2.2.7
Key: JBWS-3799
URL: https://issues.jboss.org/browse/JBWS-3799
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-5.0
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (JBWS-3682) Anonymous types in an exception aren't generated in WSDL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3682?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3682:
-----------------------------------------------
Tadayoshi Sato <tasato(a)redhat.com> changed the Status of [bug 997380|https://bugzilla.redhat.com/show_bug.cgi?id=997380] from NEW to CLOSED
> Anonymous types in an exception aren't generated in WSDL
> --------------------------------------------------------
>
> Key: JBWS-3682
> URL: https://issues.jboss.org/browse/JBWS-3682
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2
> Reporter: Tadayoshi Sato
> Attachments: exception-anontype.zip
>
>
> This is a CXF issue: https://issues.apache.org/jira/browse/CXF-5208
> Anonymous types (annotated with {{@XmlType(name = "")}}) in an exception class aren't generated at all in WSDL.
> Web service classes:
> {code:java}
> @WebService
> public class GreetingService {
> @WebMethod
> public void hello() throws MyException {}
> ...
> {code}
> {code:java}
> public class MyException extends Exception {
> private String str;
> private MyAnonType myAnonObj;
> public String getStr() { return str; }
> public void setStr(String str) { this.str = str; }
> public MyAnonType getMyAnonObj() { return myAnonObj; }
> public void setMyAnonObj(MyAnonType myAnonObj) { this.myAnonObj = myAnonObj; }
> ...
> {code}
> {code:java}
> @XmlType(name = "")
> public class MyAnonType { ...
> {code}
> Generated WSDL:
> {code:xml}
> <wsdl:types>
> <xs:schema ...>
> ...
> <xs:complexType name="MyException">
> <xs:sequence>
> <xs:element name="str" nillable="true" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> {code}
> Note that the same type ({{MyAnonType}}) is generated in WSDL if the {{@XmlType(name = "")}} annotation is removed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (JBWS-3798) @WebEndpoint name not considered when building up webservicerefs
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3798?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3798:
----------------------------------
Description:
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 name of the @WebEndpoint annotation.
was:
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.
> @WebEndpoint name 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 name of the @WebEndpoint annotation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (JBWS-3798) @WebEndpoint name not considered when building up webservicerefs
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3798?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3798:
----------------------------------
Summary: @WebEndpoint name not considered when building up webservicerefs (was: @WebEndpoint not considered when building up webservicerefs)
> @WebEndpoint name 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)
10 years, 6 months