[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 edited comment on WFLY-4444 at 4/15/15 11:27 AM:
-----------------------------------------------------------------
OK, given the comments & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
was (Author: asoldano):
OK, given the comment & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
> 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
[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 resolved WFLY-4444.
-----------------------------------
Resolution: Out of Date
> 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
[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:
---------------------------------------
OK, given the comment & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
> 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
[JBoss JIRA] (WFLY-4187) Cloning org.jboss.invocation.InterceptorContext leaks memory
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-4187:
---------------------------------------
This was fixed by JBoss Invocation 1.4.1.Final, which will be integrated in this week WildFly Core 1.0.0.Beta5 release, and that should mean the issue will be fixed in next WildFly 9.0.0 release. I will keep an eye on it and close the issue when WildFly master has the fixed JBoss Invocation integrated.
In case you want WildFly 8.x with such fix you need to upgrade JBoss Invocation to 1.4.1.Final or, in case its not fully compatible, fork the tag of the included JBoss Invocation, and apply https://github.com/jbossas/jboss-invocation/commit/21cbe4d6d08d245ac80efe...
> Cloning org.jboss.invocation.InterceptorContext leaks memory
> ------------------------------------------------------------
>
> Key: WFLY-4187
> URL: https://issues.jboss.org/browse/WFLY-4187
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Jeroen Wielandt
> Assignee: Eduardo Martins
>
> The clone function uses sublist to set the new list of interceptors.
> public InterceptorContext clone() {
> ....
> clone.setInterceptors(interceptors.subList(next, interceptors.size()));
> return clone;
> }
> This will keep a reference to the original list around. So the original list will never be released. Chaining clone multiple times will eventually cause an out of memory because each sublist grows slightly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4187) Cloning org.jboss.invocation.InterceptorContext leaks memory
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-4187:
-------------------------------------
Assignee: Eduardo Martins (was: Jason Greene)
> Cloning org.jboss.invocation.InterceptorContext leaks memory
> ------------------------------------------------------------
>
> Key: WFLY-4187
> URL: https://issues.jboss.org/browse/WFLY-4187
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Jeroen Wielandt
> Assignee: Eduardo Martins
>
> The clone function uses sublist to set the new list of interceptors.
> public InterceptorContext clone() {
> ....
> clone.setInterceptors(interceptors.subList(next, interceptors.size()));
> return clone;
> }
> This will keep a reference to the original list around. So the original list will never be released. Chaining clone multiple times will eventually cause an out of memory because each sublist grows slightly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4520) Multi-JSF archive deploy fails with JBAS014746: steps may not be null
by Paul Newport (JIRA)
Paul Newport created WFLY-4520:
----------------------------------
Summary: Multi-JSF archive deploy fails with JBAS014746: steps may not be null
Key: WFLY-4520
URL: https://issues.jboss.org/browse/WFLY-4520
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 8.2.0.Final
Reporter: Paul Newport
Assignee: Farah Juma
Deploying a multi-jsf archive fails with a steps may not be null error
deploy install-mojarra-1.2_15.cli
{
"outcome" => "failed",
"failure-description" => "JBAS014746: steps may not be null",
"rolled-back" => true
}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months