September 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3829) Move to JBossWS 5 and prune Native stack tests

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3829: ------------------------------------- Summary: Move to JBossWS 5 and prune Native stack tests Key: JBWS-3829 URL: https://issues.jboss.org/browse/JBWS-3829 Project: JBoss Web Services Issue Type: Task Components: jaxws-tools-maven-plugin Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-jaxws-tools-maven-plugin-1.2.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3828) Encoding option support

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3828: ------------------------------------- Summary: Encoding option support Key: JBWS-3828 URL: https://issues.jboss.org/browse/JBWS-3828 Project: JBoss Web Services Issue Type: Feature Request Components: jaxws-tools-maven-plugin Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-jaxws-tools-maven-plugin-1.2.0.Beta1 This is about adding support in the pluging for the encoding option that is coming from JBWS-3826. Additionally, the plugin should default to the value of the project.build.sourceEncoding Maven property. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3827) WSDL publisher incorrectly attempt to publish external HTTPS import

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3827?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3827: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 > WSDL publisher incorrectly attempt to publish external HTTPS import > ------------------------------------------------------------------- > > Key: JBWS-3827 > URL: https://issues.jboss.org/browse/JBWS-3827 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > Fix For: jbossws-cxf-5.0 > > > In org.jboss.ws.common.utils.AbstractWSDLFilePublisher, the condition used to detect external import looks like this: > // its an external import, don't publish locally > if (locationURI.startsWith("http://") == false) { ... } > This does not take in account import done over other protocols such as HTTPS. Deploying such WSDL will fail since jboss will try to resolve an absolute URL against the current deployment unit. > Simply adapting the test to include "https://" seems effective (not sure if it truly satisfies all use cases however). > This was only tested in version 2.2.3 Final of jboss-ws-common but those lines are still in trunk... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3809: --------------------------------------- WildFly 9.0.0.Beta1 is going to include the fix. > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0.0.Beta1 > > Attachments: JBWS-3809.patch, jbws3809-sample.zip, jbws3809-sample_v2.zip > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > 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:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Rob Heine (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Rob Heine commented on JBWS-3809: --------------------------------- In which WildFly distribution is this bugfix included? > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0.0.Beta1 > > Attachments: JBWS-3809.patch, jbws3809-sample.zip, jbws3809-sample_v2.zip > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > 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:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3827) WSDL publisher incorrectly attempt to publish external HTTPS import

by Marc H. (JIRA)

[ https://issues.jboss.org/browse/JBWS-3827?page=com.atlassian.jira.plugin.... ] Marc H. updated JBWS-3827: -------------------------- Summary: WSDL publisher incorrectly attempt to publish external HTTPS import (was: WSDL publisher incorrectly pttempt to publish external HTTPS import) > WSDL publisher incorrectly attempt to publish external HTTPS import > ------------------------------------------------------------------- > > Key: JBWS-3827 > URL: https://issues.jboss.org/browse/JBWS-3827 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Marc H. > > In org.jboss.ws.common.utils.AbstractWSDLFilePublisher, the condition used to detect external import looks like this: > // its an external import, don't publish locally > if (locationURI.startsWith("http://") == false) { ... } > This does not take in account import done over other protocols such as HTTPS. Deploying such WSDL will fail since jboss will try to resolve an absolute URL against the current deployment unit. > Simply adapting the test to include "https://" seems effective (not sure if it truly satisfies all use cases however). > This was only tested in version 2.2.3 Final of jboss-ws-common but those lines are still in trunk... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3827) WSDL publisher incorrectly pttempt to publish external HTTPS import

by Marc H. (JIRA)

Marc H. created JBWS-3827: ----------------------------- Summary: WSDL publisher incorrectly pttempt to publish external HTTPS import Key: JBWS-3827 URL: https://issues.jboss.org/browse/JBWS-3827 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf Affects Versions: jbossws-cxf-4.3 Reporter: Marc H. In org.jboss.ws.common.utils.AbstractWSDLFilePublisher, the condition used to detect external import looks like this: // its an external import, don't publish locally if (locationURI.startsWith("http://") == false) { ... } This does not take in account import done over other protocols such as HTTPS. Deploying such WSDL will fail since jboss will try to resolve an absolute URL against the current deployment unit. Simply adapting the test to include "https://" seems effective (not sure if it truly satisfies all use cases however). This was only tested in version 2.2.3 Final of jboss-ws-common but those lines are still in trunk... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3790) Add maven profile for disabling UDP tests

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3790?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3790: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > Add maven profile for disabling UDP tests > ----------------------------------------- > > Key: JBWS-3790 > URL: https://issues.jboss.org/browse/JBWS-3790 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0.0.Beta1 > > > This is about adding a maven profile for optionally disabling udp tests, which require setting the network environment properly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 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 edited comment on JBWS-3628 at 9/5/14 5:21 AM: --------------------------------------------------------------- Solved; documentation at https://docs.jboss.org/author/display/JBWS/Advanced+User+Guide#AdvancedUs... In particular, references to system properties delimited with "@" (both starting and ending delimiter) will be expanded. was (Author: asoldano): Solved; documentation at https://docs.jboss.org/author/display/JBWS/Advanced+User+Guide#AdvancedUs... > 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 > Components: jbossws-cxf > Reporter: david.boeren > Assignee: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.0.0.Beta1 > > Attachments: JBWS-3628-JBossWS-WSDLFactory-tentative-patch.txt, JBWS-3628-tentative-patch-from-Rebecca.txt, JBWS-3628.diff > > > 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.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3826) Add support for encoding option in JAX-WS tools

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3826: ------------------------------------- Summary: Add support for encoding option in JAX-WS tools Key: JBWS-3826 URL: https://issues.jboss.org/browse/JBWS-3826 Project: JBoss Web Services Issue Type: Feature Request Components: jaxws-tools-maven-plugin, jbossws-cxf, tools-jaxws Reporter: Alessio Soldano Fix For: jbossws-cxf-5.0 This relates to https://issues.apache.org/jira/browse/CXF-2450 . Basically, unless the encoding option of cxf tools is specified, both cxf and xjc rely on the system encoding setup, defaulting to UTF-8 if nothing is set at system level. On system with a specific encoding (e.g. Windows installed w/ Italian language), the "file.encoding" system property is set to a value different from UTF-8 (ISO-8859-1 for the italian setup). This can lead to generating sources which can't then be compiled using a more restrictive encoding like UTF-8. Generally speaking it would hence be good to allow users specifying the desired encoding for the sources to be generated. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues September 2014