March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-4444: --------------------------------------- So, I've tried your app and found a bunch of issues. First issue is about properly declaring a contract-first endpoint, that is an endpoint whose published contract is provided in a wsdl file in the deployment. You're not specifying the "serviceName" in @WebService, hence the ws stack is not using your wsdl and it's generating a new one from the code instead. While this is an error on user side, it's still something that the stack should notify the user about, so I've created https://issues.jboss.org/browse/JBWS-3899 . If you're wondering how I spotted this issue, I was looking at the log during deployment and noticed the "annotationWsdlLocation" was null: {noformat} 22:24:08,349 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-1) JBWS024061: Adding service endpoint metadata: id=SimpleEcho address=http://localhost:8080/simple-ws-1.0-SNAPSHOT/SimpleEcho implementor=com.tad.ws.SimpleEcho serviceName={http://ws.tad.com/}SimpleEchoService portName={http://ws.tad.com/}SimpleEchoPort annotationWsdlLocation=null wsdlLocationOverride=null mtomEnabled=false {noformat} Another issue is that you're not placing the wsdl file in the proper location within the deployment archive. Even if you have a war deployment, you're using an EJB3 based WS endpoints, as a consequence the the root for looking up ws endpoint resources is the actual war root, not WEB-INF/classes within it. In particular, the "META-INF/wsdl/Echo.wsdl" reference in your @WebService annotation is not resolved, as you actually have WEB-INF/classes/META-INF/wsdl/Echo.wsdl in the war. I manually moved the wsdl dir in the META-INF dir under the root and that fixed the issue; I'm leaving to you to figure out how to tune your pom for building the proper archive (how about a jar deployment?). Btw, you could have noticed a debug message from jbossws (need to enable debug logging in standalone.xml) saying: {noformat} 2015-03-25 22:45:02,984 DEBUG [org.jboss.ws.cxf.metadata] (MSC service thread 1-8) JBWS024091: Could not get WSDL from META-INF/wsdl/Echo.wsdl, aborting soap:address rewrite. {noformat} Moreover, if you manually modified the provided wsdl (e.g. by adding a useless wsdl:message), you would have noticed it was not there after deployment in the published contract (meaning the contract was actually a generated one). Once you've fixed the 2 things above and disabled automatic wsdl soap:address rewite (by adding <modify-wsdl-address>false</modify-wsdl-address> in the webservices susbsystem of standalone.xml), you should see what follows in the logs: {noformat} 22:47:13,896 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-4) JBWS024061: Adding service endpoint metadata: id=SimpleEcho address=http://localhost:8080/simple-ws-1.0-SNAPSHOT/SimpleEchoService/SimpleEcho implementor=com.tad.ws.SimpleEcho serviceName={http://ws.tad.com/}SimpleEchoService portName={http://ws.tad.com/}SimpleEchoPort annotationWsdlLocation=META-INF/wsdl/Echo.wsdl wsdlLocationOverride=null mtomEnabled=false publishedEndpointUrl=http://spartalnx:8080/simple-ws-1.0-SNAPSHOT/SimpleEcho invoker=org.jboss.wsf.stack.cxf.JBossWSInvoker properties=[org.jboss.as.webservices.metadata.modelComponentViewName -> service jboss.deployment.unit."simple-ws-1.0-SNAPSHOT.war".component.SimpleEcho.VIEW."com.tad.ws.SimpleEcho".SERVICE_ENDPOINT] [....] 2015-03-25 22:47:13,896 DEBUG [org.jboss.ws.cxf.endpointAddressRewrite] (MSC service thread 1-4) JBWS024036: WSDL service endpoint address rewrite not required: http://spartalnx:8080/simple-ws-1.0-SNAPSHOT/SimpleEcho {noformat} ... and the wsdl visible at "http://localhost:8080/simple-ws-1.0-SNAPSHOT/SimpleEchoService/SimpleEcho..." (beware the different default URL because of the endpoint being a contract first) has your provided and unchanged address "http://spartalnx:8080/simple-ws-1.0-SNAPSHOT/SimpleEcho" (which you would want to change to match the correct context-root & path, or you might want to tune the deployment). So, besides for the warning issue, I believe there's no issue here and this jira can be closed. > Ability to set WSDL URL > ----------------------- > > Key: WFLY-4444 > URL: https://issues.jboss.org/browse/WFLY-4444 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Affects Versions: 8.2.0.Final > Reporter: John Ament > Assignee: Alessio Soldano > > There's no way to correctly set a WSDL URL. The properties are: > {code} > <modify-wsdl-address>true</modify-wsdl-address> > <wsdl-host>${public.app.host:localhost}</wsdl-host> > <wsdl-port>${public.http.port:80}</wsdl-port> > <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port> > {code} > We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-489?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-489: ------------------------------------ Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > The "access-mechanism" field in the active-operation resources is always undefined > ---------------------------------------------------------------------------------- > > Key: WFCORE-489 > URL: https://issues.jboss.org/browse/WFCORE-489 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.CR1 > > > The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: > {code} > ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); > if (accessMechanism != null) { > accessMechanismNode.set(accessMechanismNode.toString()); > } > {code} > It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-611) Add way to validating operation by its definition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-611?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-611: ------------------------------------ Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) > Add way to validating operation by its definition > ------------------------------------------------- > > Key: WFCORE-611 > URL: https://issues.jboss.org/browse/WFCORE-611 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 1.0.0.CR1 > > > we could use OperationDefinition#validateAndSet(operation,model) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-487) Instability in RespawnHttpTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-487?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-487: ----------------------------------------- Should this be resolved then? > Instability in RespawnHttpTestCase > ----------------------------------- > > Key: WFCORE-487 > URL: https://issues.jboss.org/browse/WFCORE-487 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 1.0.0.Alpha14 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 1.0.0.Beta1 > > Attachments: respawn-http-threads.txt > > > We have the following error message in the traces: > 2014-12-15 19:19:53,574 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=32341&buildTyp...! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-604) After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-604?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-604: ----------------------------------------- WFCORE-213 was implemented as the general solution to the category of problems described by WFCORE604. > After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-604 > URL: https://issues.jboss.org/browse/WFCORE-604 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Chao Wang > Assignee: Chao Wang > > {noformat} > Description of problem: > === > - After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory > - Please see following reproduce steps. > How reproducible: > === > Steps to Reproduce: > 1. Fail to deploy application via jboss-cli > 2. Find deployment info in JBOSS_HOME/{standalone|domaine}/data/content, but there are no standalone.xml in <deployments> tag. > 3. Fix deployment and success to deploy. > 4. Find "new" deployment info in JBOSS_HOME/{standalone|domaine}/data/content, and the old deployment info will be still there. > - I know that as we changed application in step-3, its hash value was changed. And then, old info is remained in JBOSS_HOME/{standalone|domaine}/data/content. But I think it always happens and should be fixed. > Actual results: > - The deployment information which created when deploy was failed remains in JBOSS_HOME/{standalone|domaine}/data/content. > Expected results: > - The deployment information which created when deploy was failed should be removed if the deploy is failed. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-748) MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1).

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-748?page=com.atlassian.jira.plugin... ] Tibor Zimányi resolved DROOLS-748. ---------------------------------- Resolution: Done > MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1). > ------------------------------------------------------------------------- > > Key: DROOLS-748 > URL: https://issues.jboss.org/browse/DROOLS-748 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > > In MultithreadTest classes (there are two of them) method testSlidingTimeWindows() uses unreliable Thread.sleep(1) call for waiting for fact insertion. Thread.sleep(1) doesn't wait for exactly 1 millisecond, because there is overhead from thread scheduler. This overhead can be pretty large in contrast to expected 1ms sleep. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-742) DecisionTableXLSToDecisionTableGuidedConverterTest fails on jdk8

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-742?page=com.atlassian.jira.plugin... ] Tibor Zimányi resolved DROOLS-742. ---------------------------------- Resolution: Done > DecisionTableXLSToDecisionTableGuidedConverterTest fails on jdk8 > ---------------------------------------------------------------- > > Key: DROOLS-742 > URL: https://issues.jboss.org/browse/DROOLS-742 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.2.0.Final > Reporter: Tibor Zimányi > Assignee: Michael Anstis > Priority: Minor > > Failing test is from drools-wb repo. > Test methods testConditions() and testConditionsIndexedParameters() fails on jdk8. > XLS files used in these methods contain multiple parameters column (column with more parameters than one). When XLS is parsed, these parameters are transformed into child columns of BRLConditionColumn. In ParameterUtilities class is method extractTemplateKeys. This method extracts params from preprocessed original string from XLS table cell containing parameters. But because the method uses HashSet as return value, the ordering of parameters cannot be determined (in HashSet, the order of items can be different than the order in which the items were inserted). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4464) JDBC driver module-slot is not persisted in domain mode

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4464?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4464: ------------------------------ Affects Version/s: 8.2.0.Final > JDBC driver module-slot is not persisted in domain mode > ------------------------------------------------------- > > Key: WFLY-4464 > URL: https://issues.jboss.org/browse/WFLY-4464 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.2.0.Final > Reporter: Lin Gao > Assignee: Jesper Pedersen > > The module-slot of jdbc-driver is NOT persisted in domain mode, but it is persisted in standalone mode. > After debugging, I found that the performRuntime() method of JdbcDriverAdd.java is not called in domain mode, but is called in standalone mode. > For more information about the issue, please refer to the thread: https://developer.jboss.org/thread/253654 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4464) JDBC driver module-slot is not persisted in domain mode

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4464?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4464: ------------------------------ Component/s: Domain Management > JDBC driver module-slot is not persisted in domain mode > ------------------------------------------------------- > > Key: WFLY-4464 > URL: https://issues.jboss.org/browse/WFLY-4464 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Reporter: Lin Gao > Assignee: Jesper Pedersen > > The module-slot of jdbc-driver is NOT persisted in domain mode, but it is persisted in standalone mode. > After debugging, I found that the performRuntime() method of JdbcDriverAdd.java is not called in domain mode, but is called in standalone mode. > For more information about the issue, please refer to the thread: https://developer.jboss.org/thread/253654 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1251) Only allow certain decrementer policies for CRI pools

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1251?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1251. ---------------------------------- Resolution: Done > Only allow certain decrementer policies for CRI pools > ----------------------------------------------------- > > Key: JBJCA-1251 > URL: https://issues.jboss.org/browse/JBJCA-1251 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.3.Final > > > Otherwise there could be configurations where the pools never would empty > Allow > * TimedOutDecrementer > * MinPoolSizeDecrementer > * SizeDecrementer -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015