Issues with Attachments: week of 2012-07-23
CXF - Monday, July 23, 2012 1 Issues with Attachments (sorted oldest to newest) [CXF-4431] Add support for OAuth2 'mac' token type - Created: 2012-07-18 - Updated: 2012-07-18 - Type: Improvement - Fix Versions: [2.7.0] - Reporter: Sasi M - Assigned: Unassigned - Attachments: [mac_token_nonce_checking.txt, mac_token_support.txt] - https://issues.apache.org/jira/browse/CXF-4431
[jira] [Created] (CXF-4439) Update to Jettison 1.3.2
Sergey Beryozkin created CXF-4439: - Summary: Update to Jettison 1.3.2 Key: CXF-4439 URL: https://issues.apache.org/jira/browse/CXF-4439 Project: CXF Issue Type: Task Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4438) more flexibility in configuring tlsServerParameters in spring and blueprint
[ https://issues.apache.org/jira/browse/CXF-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4438. -- Resolution: Fixed > more flexibility in configuring tlsServerParameters in spring and blueprint > --- > > Key: CXF-4438 > URL: https://issues.apache.org/jira/browse/CXF-4438 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.6.1 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.2, 2.7.0 > > > CXF-4423 added an option to reference the keyManagers and trustManagers from > tlsClientParameters using the optional ref attribute in keyManagers and > trustManagers, respectively. > The patch adds this referencing option also in tlsServerParameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4424) Option for codegen plugin to fork in order to support endorsed libs
[
https://issues.apache.org/jira/browse/CXF-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420623#comment-13420623
]
David J. M. Karlsen commented on CXF-4424:
--
In my top pom I declare in the properties section:
{noformat}
...
2.2
2.2
2.2
${project.build.directory}/endorsed
{noformat}
as well as manage surefire/compiler plugin to use endorsed:
{noformat}
org.apache.maven.plugins
maven-compiler-plugin
${endorsed.dir}
org.apache.maven.plugins
maven-surefire-plugin
once
-Djava.endorsed.dirs=${endorsed.dir}
{noformat}
in the child projects which generates code, I unpack a dependency containing
wsdls and fork with the endorsed libs:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
unpack-cpl-server-schemas
generate-sources
unpack
**/*.wsdl
com.edb.fs.cashpool.srv
cp-server-schemas
${cp.srv.version}
org.apache.cxf
cxf-codegen-plugin
${cxf.version}
once
-Djava.endorsed.dirs=${endorsed.dir}
${basedir}/src/main/resources/wsdl/catalog.xml
${basedir}/src/main/resources/wsdl/jaxbbindings.xml
-fe
jaxws21
-xjc-Xts
-xjc-Xfluent-api
-xjc-mark-generated
-verbose
true
${basedir}/src/main/resources/wsdl
generate-sources-embedded
generate-sources
${basedir}/src/main/resources/wsdl
wsdl2java
generate-sources-cp-srv
generate-sources
${project.build.directory}/dependency/wsdl
[jira] [Comment Edited] (CXF-4424) Option for codegen plugin to fork in order to support endorsed libs
[
https://issues.apache.org/jira/browse/CXF-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420623#comment-13420623
]
David J. M. Karlsen edited comment on CXF-4424 at 7/23/12 1:05 PM:
---
In my top pom I declare in the properties section:
{noformat}
...
2.2
2.2
2.2
${project.build.directory}/endorsed
{noformat}
as well as manage surefire/compiler plugin to use endorsed:
{noformat}
org.apache.maven.plugins
maven-compiler-plugin
${endorsed.dir}
org.apache.maven.plugins
maven-surefire-plugin
once
-Djava.endorsed.dirs=${endorsed.dir}
{noformat}
Thirdly in the topmost pom I configure the dependency plugin to copy the
jaxws-api and jaxb-api to target/endorsed for all modules:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
generate-sources
copy
javax.xml.bind
jaxb-api
${jaxb.api.version}
javax.xml.ws
jaxws-api
${jaxws.api.version}
${endorsed.dir}
{noformat}
in the child projects which generates code, I unpack a dependency containing
wsdls and fork with the endorsed libs:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
unpack-cpl-server-schemas
generate-sources
unpack
**/*.wsdl
com.edb.fs.cashpool.srv
cp-server-schemas
${cp.srv.version}
org.apache.cxf
cxf-codegen-plugin
${cxf.version}
once
-Djava.endorsed.dirs=${endorsed.dir}
${basedir}/src/main/resources/wsdl/catalog.xml
[jira] [Comment Edited] (CXF-4424) Option for codegen plugin to fork in order to support endorsed libs
[
https://issues.apache.org/jira/browse/CXF-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420623#comment-13420623
]
David J. M. Karlsen edited comment on CXF-4424 at 7/23/12 1:06 PM:
---
In my top pom I declare in the properties section:
{noformat}
...
2.2
2.2
2.2
${project.build.directory}/endorsed
{noformat}
as well as manage surefire/compiler plugin to use endorsed:
{noformat}
org.apache.maven.plugins
maven-compiler-plugin
${endorsed.dir}
org.apache.maven.plugins
maven-surefire-plugin
once
-Djava.endorsed.dirs=${endorsed.dir}
{noformat}
Thirdly in the topmost pom I configure the dependency plugin to copy the
jaxws-api and jaxb-api to target/endorsed for all modules:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
generate-sources
copy
javax.xml.bind
jaxb-api
${jaxb.api.version}
javax.xml.ws
jaxws-api
${jaxws.api.version}
${endorsed.dir}
{noformat}
in the child projects which generates code, I unpack a dependency containing
wsdls and fork with the endorsed libs:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
unpack-cpl-server-schemas
generate-sources
unpack
**/*.wsdl
com.edb.fs.cashpool.srv
cp-server-schemas
${cp.srv.version}
org.apache.cxf
cxf-codegen-plugin
${cxf.version}
once
-Djava.endorsed.dirs=${endorsed.dir}
${basedir}/src/main/resources/wsdl/catalog.xml
[jira] [Comment Edited] (CXF-4424) Option for codegen plugin to fork in order to support endorsed libs
[
https://issues.apache.org/jira/browse/CXF-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420623#comment-13420623
]
David J. M. Karlsen edited comment on CXF-4424 at 7/23/12 1:12 PM:
---
In my top pom I declare in the properties section:
{noformat}
...
2.2
2.2
2.2
${project.build.directory}/endorsed
{noformat}
as well as manage surefire/compiler plugin to use endorsed:
{noformat}
org.apache.maven.plugins
maven-compiler-plugin
${endorsed.dir}
org.apache.maven.plugins
maven-surefire-plugin
once
-Djava.endorsed.dirs=${endorsed.dir}
{noformat}
Thirdly in the topmost pom I configure the dependency plugin to copy the
jaxws-api and jaxb-api to target/endorsed for all modules:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
generate-sources
copy
javax.xml.bind
jaxb-api
${jaxb.api.version}
javax.xml.ws
jaxws-api
${jaxws.api.version}
${endorsed.dir}
{noformat}
in the child projects which generates code, I unpack a dependency containing
wsdls and fork with the endorsed libs:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
unpack-cpl-server-schemas
generate-sources
unpack
**/*.wsdl
com.edb.fs.cashpool.srv
cp-server-schemas
${cp.srv.version}
org.apache.cxf
cxf-codegen-plugin
${cxf.version}
once
-Djava.endorsed.dirs=${endorsed.dir}
${basedir}/src/main/resources/wsdl/catalog.xml
[jira] [Commented] (CXF-4425) OAuth 1.0 timestamp and nonces are not validated and the validation can not be customized
[ https://issues.apache.org/jira/browse/CXF-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420663#comment-13420663 ] Evgeni Kisel commented on CXF-4425: --- I'm sorry. I've made a quick look, seem it's fixed. Waiting for new release. > OAuth 1.0 timestamp and nonces are not validated and the validation can not > be customized > - > > Key: CXF-4425 > URL: https://issues.apache.org/jira/browse/CXF-4425 > Project: CXF > Issue Type: Bug > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Evgeni Kisel >Assignee: Sergey Beryozkin > Fix For: 2.6.2, 2.7.0 > > > It's possible to send multiple request with the same header. Actually it's a > security violation. > Specifically, the default OAuthValidator is created per-request - this is OK > for validating that a given OAuth message contains the expected parameters > and that the signature is correct, but the default nonces cache is lost after > the validation is done. Additionally, it is not possible to customize the > validation process -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CXF-4425) OAuth 1.0 timestamp and nonces are not validated and the validation can not be customized
[ https://issues.apache.org/jira/browse/CXF-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420663#comment-13420663 ] Evgeni Kisel edited comment on CXF-4425 at 7/23/12 2:03 PM: I've made a quick look, seem it's fixed. Waiting for new release. was (Author: evgeni_kisel): I'm sorry. I've made a quick look, seem it's fixed. Waiting for new release. > OAuth 1.0 timestamp and nonces are not validated and the validation can not > be customized > - > > Key: CXF-4425 > URL: https://issues.apache.org/jira/browse/CXF-4425 > Project: CXF > Issue Type: Bug > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Evgeni Kisel >Assignee: Sergey Beryozkin > Fix For: 2.6.2, 2.7.0 > > > It's possible to send multiple request with the same header. Actually it's a > security violation. > Specifically, the default OAuthValidator is created per-request - this is OK > for validating that a given OAuth message contains the expected parameters > and that the signature is correct, but the default nonces cache is lost after > the validation is done. Additionally, it is not possible to customize the > validation process -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4440) Webservice Unavailable - Internal Server Error (Response code 500) not handled in HTTPConduit.java (One way webservice)
Amol Deshpande created CXF-4440:
---
Summary: Webservice Unavailable - Internal Server Error (Response
code 500) not handled in HTTPConduit.java (One way webservice)
Key: CXF-4440
URL: https://issues.apache.org/jira/browse/CXF-4440
Project: CXF
Issue Type: Bug
Reporter: Amol Deshpande
Hi,
I am working on a CXF client for a one way JAX-RPC webservice.
I am testing a scenario where, the webservice is unavailable (The application
for the webservice on the server is stopped)
In this case, the server sends back a response Internal server error (Response
code 500)
This response code is not handled by the httpConduit.handleResponseInternal()
function because it does not throw an error for response code 500.
2184 if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
2185 &&
!MessageUtils.isTrue(outMessage.getContextualProperty(
2186 "org.apache.cxf.http.no_io_exceptions"))) {
2187 throw new IOException("HTTP response '" + responseCode
+ ": "
2188 + connection.getResponseMessage() + "'");
2189 }
Can you please let me know if this is a known issue or if there is a workaround
to handle this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4440) Webservice Unavailable - Internal Server Error (Response code 500) not handled in HTTPConduit.java (One way webservice)
[
https://issues.apache.org/jira/browse/CXF-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amol Deshpande updated CXF-4440:
Description:
Hi,
I am working on a CXF client for a one way JAX-RPC webservice.
I am testing a scenario where, the webservice is unavailable (The application
for the webservice on the server is stopped)
In this case, the server sends back a response Internal server error (Response
code 500)
This response code is not handled by the httpConduit.handleResponseInternal()
function because it does not throw an error for response code 500.
if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
&& !MessageUtils.isTrue(outMessage.getContextualProperty(
"org.apache.cxf.http.no_io_exceptions"))) {
throw new IOException("HTTP response '" + responseCode + ":
" + connection.getResponseMessage() + "'");
}
Can you please let me know if this is a known issue or if there is a workaround
to handle this?
was:
Hi,
I am working on a CXF client for a one way JAX-RPC webservice.
I am testing a scenario where, the webservice is unavailable (The application
for the webservice on the server is stopped)
In this case, the server sends back a response Internal server error (Response
code 500)
This response code is not handled by the httpConduit.handleResponseInternal()
function because it does not throw an error for response code 500.
2184 if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
2185 &&
!MessageUtils.isTrue(outMessage.getContextualProperty(
2186 "org.apache.cxf.http.no_io_exceptions"))) {
2187 throw new IOException("HTTP response '" + responseCode
+ ": "
2188 + connection.getResponseMessage() + "'");
2189 }
Can you please let me know if this is a known issue or if there is a workaround
to handle this?
> Webservice Unavailable - Internal Server Error (Response code 500) not
> handled in HTTPConduit.java (One way webservice)
> ---
>
> Key: CXF-4440
> URL: https://issues.apache.org/jira/browse/CXF-4440
> Project: CXF
> Issue Type: Bug
>Reporter: Amol Deshpande
>
> Hi,
> I am working on a CXF client for a one way JAX-RPC webservice.
> I am testing a scenario where, the webservice is unavailable (The application
> for the webservice on the server is stopped)
> In this case, the server sends back a response Internal server error
> (Response code 500)
> This response code is not handled by the httpConduit.handleResponseInternal()
> function because it does not throw an error for response code 500.
> if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
> && !MessageUtils.isTrue(outMessage.getContextualProperty(
> "org.apache.cxf.http.no_io_exceptions"))) {
> throw new IOException("HTTP response '" + responseCode +
> ": " + connection.getResponseMessage() + "'");
>}
> Can you please let me know if this is a known issue or if there is a
> workaround to handle this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4440) Webservice Unavailable - Internal Server Error (Response code 500) not handled in HTTPConduit.java (One way webservice)
[
https://issues.apache.org/jira/browse/CXF-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420681#comment-13420681
]
Glen Mazza commented on CXF-4440:
-
Please ask your question on the CXF-User's list first, to determine that this
is indeed a bug in CXF instead of within your code. Note CXF is not a JAX-RPC
implementation, it's a JAX-WS one; Axis 1.x may be better fit for your needs.
> Webservice Unavailable - Internal Server Error (Response code 500) not
> handled in HTTPConduit.java (One way webservice)
> ---
>
> Key: CXF-4440
> URL: https://issues.apache.org/jira/browse/CXF-4440
> Project: CXF
> Issue Type: Bug
>Reporter: Amol Deshpande
>
> Hi,
> I am working on a CXF client for a one way JAX-RPC webservice.
> I am testing a scenario where, the webservice is unavailable (The application
> for the webservice on the server is stopped)
> In this case, the server sends back a response Internal server error
> (Response code 500)
> This response code is not handled by the httpConduit.handleResponseInternal()
> function because it does not throw an error for response code 500.
> if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
> && !MessageUtils.isTrue(outMessage.getContextualProperty(
> "org.apache.cxf.http.no_io_exceptions"))) {
> throw new IOException("HTTP response '" + responseCode +
> ": " + connection.getResponseMessage() + "'");
>}
> Can you please let me know if this is a known issue or if there is a
> workaround to handle this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4440) Webservice Unavailable - Internal Server Error (Response code 500) not handled in HTTPConduit.java (One way webservice)
[
https://issues.apache.org/jira/browse/CXF-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420711#comment-13420711
]
Amol Deshpande commented on CXF-4440:
-
Hi Glenn,
Sorry! I have asked the question on the CXF-Users list now.
Thanks,
Amol
> Webservice Unavailable - Internal Server Error (Response code 500) not
> handled in HTTPConduit.java (One way webservice)
> ---
>
> Key: CXF-4440
> URL: https://issues.apache.org/jira/browse/CXF-4440
> Project: CXF
> Issue Type: Bug
>Reporter: Amol Deshpande
>
> Hi,
> I am working on a CXF client for a one way JAX-RPC webservice.
> I am testing a scenario where, the webservice is unavailable (The application
> for the webservice on the server is stopped)
> In this case, the server sends back a response Internal server error
> (Response code 500)
> This response code is not handled by the httpConduit.handleResponseInternal()
> function because it does not throw an error for response code 500.
> if (responseCode == HttpURLConnection.HTTP_NOT_FOUND
> && !MessageUtils.isTrue(outMessage.getContextualProperty(
> "org.apache.cxf.http.no_io_exceptions"))) {
> throw new IOException("HTTP response '" + responseCode +
> ": " + connection.getResponseMessage() + "'");
>}
> Can you please let me know if this is a known issue or if there is a
> workaround to handle this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FEDIZ-18) Make supported claims configurable in FileClaimsHandler
Oliver Wulff created FEDIZ-18:
-
Summary: Make supported claims configurable in FileClaimsHandler
Key: FEDIZ-18
URL: https://issues.apache.org/jira/browse/FEDIZ-18
Project: CXF-Fediz
Issue Type: Improvement
Components: IDP
Affects Versions: 1.0.0
Reporter: Oliver Wulff
Priority: Minor
The supported claims of the FileClaimsHandler are managed in the code:
public List getSupportedClaimTypes()
{
ArrayList list = new ArrayList();
list.add(ClaimTypes.EMAILADDRESS);
list.add(ClaimTypes.LASTNAME);
list.add(ClaimTypes.FIRSTNAME);
list.add(ROLE);
return list;
}
This should be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4424) Option for codegen plugin to fork in order to support endorsed libs
[ https://issues.apache.org/jira/browse/CXF-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4424. -- Resolution: Fixed Fix Version/s: Invalid Assignee: Daniel Kulp I updated the docs at: https://cwiki.apache.org/confluence/display/CXF20DOC/Maven+cxf-codegen-plugin+(WSDL+to+Java) to include some of the snippets from the above. > Option for codegen plugin to fork in order to support endorsed libs > --- > > Key: CXF-4424 > URL: https://issues.apache.org/jira/browse/CXF-4424 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.5.4 > Environment: java 6 >Reporter: David J. M. Karlsen >Assignee: Daniel Kulp > Labels: codegen, endorsed, fork > Fix For: Invalid > > > In order to support endorsed libs it would be preferable to have the codegen > plugin fork (and support setting of java.endorsed.dirs). > I wish to do so because my build uses a vanilla JDK6 which is JAXB 2.1 and > JAX-WS 2.1, but the target env is JDK6, JEE6 on WAS8 with JAXB 2.2 and JAX-WS > 2.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4422) Unable to authenticate to proxy -- Proxy returns "HTTP/1.1 500 Internal Server Error"
[
https://issues.apache.org/jira/browse/CXF-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-4422:
-
Fix Version/s: NeedMoreInfo
Honestly, I'm not sure if there is anything we can do with the above. I
checked a simple case with the only proxy server setup I have and it worked.
The fact that it works for HTTP as well as in eclipse suggests the code itself
is correct. The only thing I can think of is a difference between the JVM's
in use, maybe lacking installation of the needed certs or maybe the unlimitted
strength encryption or similar.
If you can get something that works using the in JDK HttpsURLConnection, that
MAY be something we could work with to diagnose this.
> Unable to authenticate to proxy -- Proxy returns "HTTP/1.1 500 Internal
> Server Error"
> -
>
> Key: CXF-4422
> URL: https://issues.apache.org/jira/browse/CXF-4422
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.6
> Environment: Red Hat Enterprise Linux - Oracle Java SE JDK 1.6.0_24.
>Reporter: Nick Parmelee
> Labels: authentication, https, proxy
> Fix For: NeedMoreInfo
>
>
> Hi,
> I am attempting to call an external web service via HTTPS through a proxy
> requiring authentication, from a simple standalone Java program running on a
> Linux server. Authentication to the proxy fails, with the proxy returning the
> following error: "Caused by: javax.xml.stream.XMLStreamException:
> java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.1
> 500 Internal Server Error".
> However, if I change the protocol to HTTP, the call succeeds.
> When running the same program on Windows from within Eclipse, the call always
> succeeds, whether I am using HTTP or HTTPS, even with invalid credentials.
> Please find below the source code for the program:
> {code}
> NEXTGENLiteSoap client;
> try {
> JaxWsProxyFactoryBean proxyFactory = new JaxWsProxyFactoryBean();
> proxyFactory.setServiceClass(NEXTGENLiteSoap.class);
>
> proxyFactory.setAddress("https://www.nextgen.com/soap/v1.0/service.asmx?WSDL";);
> client = (NEXTGENLiteSoap) proxyFactory.create();
> Client endpointClient = ClientProxy.getClient(client);
> HTTPConduit http = (HTTPConduit) endpointClient.getConduit();
> HTTPClientPolicy httpClientPolicy = http.getClient();
> httpClientPolicy.setConnectionTimeout(36000);
> httpClientPolicy.setAllowChunking(false);
> httpClientPolicy.setProxyServer("101.213.190.104");
> httpClientPolicy.setProxyServerPort(8080);
> httpClientPolicy.setProxyServerType(ProxyServerType.HTTP);
> httpClientPolicy.setAutoRedirect(false);
> httpClientPolicy.setConnection(ConnectionType.KEEP_ALIVE);
> ProxyAuthorizationPolicy proxyAuthPolicy = new ProxyAuthorizationPolicy();
> proxyAuthPolicy.setUserName("testUser");
> proxyAuthPolicy.setPassword("testPass");
> proxyAuthPolicy.setAuthorizationType("Basic");
> http.setProxyAuthorization(proxyAuthPolicy);
> http.setClient(httpClientPolicy);
> DataInput input = new DataInput();
> input.setUsername("NEXTGEN0941");
> input.setPassword("M0XLY7VH");
> input.setVRM("12345678");
> Object a = client.getNextGenData(input);
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> {code}
> I implemented a simple HTTP client via the program below to validate the
> credentials:
> {code}
> HttpHost proxy = new HttpHost("101.213.190.104", 8080, "http");
> // general setup
> SchemeRegistry supportedSchemes = new SchemeRegistry();
> // Register the "http" and "https" protocol schemes, they are
> // required by the default operator to look up socket factories.
> supportedSchemes.register(new Scheme("http",
> PlainSocketFactory.getSocketFactory(), 80));
> supportedSchemes.register(new Scheme("https",
> SSLSocketFactory.getSocketFactory(), 443));
> // prepare parameters
> HttpParams params = new BasicHttpParams();
> HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
> HttpProtocolParams.setContentCharset(params, "UTF-8");
> HttpProtocolParams.setUseExpectContinue(params, true);
> ClientConnectionManager ccm = new ThreadSafeClientConnManager(params,
> supportedSchemes);
> DefaultHttpClient httpclient = new DefaultHttpClient(ccm, params);
> httpclient.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxy);
> httpclient.getCredentialsProvider().setCredentials(new
> AuthScope("101.213.190.104", 8080), new
> UsernamePasswordCredentials("testUser", "testPass"));
>
> HttpGet req = new
> HttpGet("https://www.nextgen.com/soap/v1.0/service.asmx?WSDL";);
> //System.out.println("executing request to " + target + " via " + proxy);
> HttpResponse rsp = httpclient.execute(req);
> HttpEntity entity = rsp.getE
[jira] [Commented] (CXF-4437) Stack Overflow exception in org.apache.cxf.endpoint.ClientImpl when logging set to FINE
[
https://issues.apache.org/jira/browse/CXF-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421000#comment-13421000
]
Jason Pell commented on CXF-4437:
-
Hi,
Thanks for your comments. The problem occurs when we abort the outgoing chain
and
Call the onMessage on the Message Observer. What we are not doing is creating a
new Response message which. I guess is pretty stupid. I will change our code to
do this and see if the issue goes away.
> Stack Overflow exception in org.apache.cxf.endpoint.ClientImpl when logging
> set to FINE
> ---
>
> Key: CXF-4437
> URL: https://issues.apache.org/jira/browse/CXF-4437
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6.1
> Environment: JDK 1.6.0_32
>Reporter: Jason Pell
> Fix For: 2.6.2
>
>
> Hi,
> I can reproduce the issue in our code, but will probably struggle to
> create a test case.
> I have narrowed down the culprit (in 2.6.1) to
> org.apache.cxf.endpoint.ClientImpl line 636
> The method protected Object[] processResult(Message message,
>Exchange exchange,
>BindingOperationInfo oi,
>Map resContext)
> throws Exception {
> And the code:
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("set responseContext to be" + resContext);
> }
> The code to add all the properties from the message to resContext, creates a
> recursive reference, because the message already has a reference to
> resContext. This causes the logging to fail as when it tries to serialise
> the content of the map, it gets a stack overflow.
> The org.apache.cxf.invocation.context contains the ResponseContext and
> the ResponseContext contains the org.apache.cxf.invocation.context
> To prove my hypothesis I added the following code to replace the log call:
> HashMap contextMap = (HashMap)
> resContext.get("org.apache.cxf.invocation.context");
> HashMap responseContextMap = (HashMap)
> contextMap.get("ResponseContext");
> HashMap secondContextMap = (HashMap)
> responseContextMap.get("org.apache.cxf.invocation.context");
> if (secondContextMap != null) {
> System.out.println("Oh boy here is the
> error!");
> }
> And I got the Oh boy here is the error! message back.
> The original stack trace is:
> java.lang.StackOverflowError
> at java.util.HashMap$EntrySet.iterator(HashMap.java:950)
> at java.util.AbstractMap.toString(AbstractMap.java:478)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
