Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong 'ahc-default.properties' resource file loaded when there's a non-shaded version of asynchttpclient in the class path. #177

Open
noisypants opened this issue Jul 25, 2017 · 5 comments

Comments

@noisypants
Copy link

Are you looking for help?

Play WS Version (2.5.x / etc)

2.6.2

API (Scala / Java / Neither / Both)

Both

Operating System (Ubuntu 15.10 / MacOS 10.10 / Windows 10)

Windows 10

JDK (Oracle 1.8.0_72, OpenJDK 1.8.x, Azul Zing)

java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Library Dependencies

Expected Behavior

When there is a non-shaded version of asynchttpclient in the class path, depending on the order of jars in the classpath, the non-shaded version of the ahc-default.properties file can get loaded. This in turn makes config queries fail with using the prefix 'play.shaded.ahc'. I would expect the shaded library to specifically load the shaded properties files by renaming the shaded property files.

Actual Behavior

NumberFomatException occurs when trying to instantiate the AsyncHttpClientProvider class when launching a play application.

Caused by: java.lang.NumberFormatException: null
        at java.lang.Integer.parseInt(Integer.java:542)
        at java.lang.Integer.parseInt(Integer.java:615)
        at play.shaded.ahc.org.asynchttpclient.config.AsyncHttpClientConfigHelper$Config.getInt(AsyncHttpClientConfigHelper.java:109)
        at play.shaded.ahc.org.asynchttpclient.config.AsyncHttpClientConfigDefaults.defaultMaxRedirects(AsyncHttpClientConfigDefaults.java:64)
        at play.shaded.ahc.org.asynchttpclient.DefaultAsyncHttpClientConfig$Builder.<init>(DefaultAsyncHttpClientConfig.java:599)
        at play.api.libs.ws.ahc.AhcConfigBuilder.<init>(AhcConfig.scala:127)
        at play.api.libs.ws.ahc.AsyncHttpClientProvider.<init>(AhcWSModule.scala:64)
        at play.api.libs.ws.ahc.AsyncHttpClientProvider$$FastClassByGuice$$68dd0aee.newInstance(<generated>)
        at com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance(DefaultConstructionProxyFactory.java:89)
@marcospereira
Copy link
Member

Hi @noisypants,

Is this a duplicate of #87?

@marcospereira marcospereira marked this as a duplicate of #87 Jul 25, 2017
@noisypants
Copy link
Author

noisypants commented Jul 25, 2017

It's got the same original behavior, however i'm not convinced the workaround solves the issue. By adding the original keys to the shaded properties file, it works if the non-shaded library loads the shaded properties file. But i have the shaded library loading the non-shaded properties.

@marcospereira, am i reading that correctly?

@annebyrne
Copy link

annebyrne commented Oct 3, 2017

I am seeing the same issue (see version details below) on the Guardian frontend repo with Play 2.6.3 and above. Here is the branch that exhibits the issue. Confirming the fix in #87 has not resolved the problem as mentioned by @noisypants.

Play WS Version (2.5.x / etc)

2.6.3+

API (Scala / Java / Neither / Both)

Both

Operating System (Ubuntu 15.10 / MacOS 10.10 / Windows 10)

macOS Sierra 10.12.5
Darwin 34480 16.6.0 Darwin Kernel Version 16.6.0

JDK (Oracle 1.8.0_72, OpenJDK 1.8.x, Azul Zing)

java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

Stack Trace

Caused by: java.lang.NumberFormatException: null
	at java.lang.Integer.parseInt(Integer.java:542)
	at java.lang.Integer.parseInt(Integer.java:615)
	at play.shaded.ahc.org.asynchttpclient.config.AsyncHttpClientConfigHelper$Config.getInt(AsyncHttpClientConfigHelper.java:109)
	at play.shaded.ahc.org.asynchttpclient.config.AsyncHttpClientConfigDefaults.defaultMaxRedirects(AsyncHttpClientConfigDefaults.java:64)
	at play.shaded.ahc.org.asynchttpclient.DefaultAsyncHttpClientConfig$Builder.<init>(DefaultAsyncHttpClientConfig.java:599)
	at play.api.libs.ws.ahc.AhcConfigBuilder.<init>(AhcConfig.scala:127)
	at play.api.libs.ws.ahc.AsyncHttpClientProvider.<init>(AhcWSModule.scala:64)
	at play.api.libs.ws.ahc.AhcWSComponents$class.wsClient(AhcWSComponents.scala:31)
	at AppLoader$$anon$1.wsClient$lzycompute(AppLoader.scala:25)
	at AppLoader$$anon$1.wsClient(AppLoader.scala:25)
	at AppComponents$class.ophanApi(AppLoader.scala:32)
	at AppLoader$$anon$1.ophanApi$lzycompute(AppLoader.scala:25)
	at AppLoader$$anon$1.ophanApi(AppLoader.scala:25)
	at AppComponents$class.lifecycleComponents(AppLoader.scala:42)
	at AppLoader$$anon$1.lifecycleComponents$lzycompute(AppLoader.scala:25)
	at AppLoader$$anon$1.lifecycleComponents(AppLoader.scala:25)
	at app.LifecycleComponents$class.startLifecycleComponents(FrontendApplicationLoader.scala:61)
	at AppLoader$$anon$1.startLifecycleComponents(AppLoader.scala:25)
	at app.FrontendApplicationLoader$class.load(FrontendApplicationLoader.scala:23)
	at AppLoader.load(AppLoader.scala:24)
	at play.core.server.DevServerStart$$anonfun$mainDev$1$$anon$1$$anonfun$1.apply(DevServerStart.scala:174)
	at play.core.server.DevServerStart$$anonfun$mainDev$1$$anon$1$$anonfun$1.apply(DevServerStart.scala:171)
	at play.utils.Threads$.withContextClassLoader(Threads.scala:21)
	at play.core.server.DevServerStart$$anonfun$mainDev$1$$anon$1.reload(DevServerStart.scala:171)

The code corresponding to the line indicated in the stack trace (AsyncHttpClientConfigDefaults.defaultMaxRedirects(AsyncHttpClientConfigDefaults.java:64)) references code from the non-shaded version of the asynchttp client even if the package name matches the shaded version.

@an-tex
Copy link

an-tex commented Nov 22, 2017

Same issue on 2.6.7

@domdorn
Copy link
Member

domdorn commented Nov 23, 2017

The problem still persists. A solution is to copy the ahc.properties file from the jar file into the conf/ path of the application, thus making sure that the application finds this one in the classpath (the file from the jar already contains the correct keys for shaded+non-shaded versions).
We should add a note somewhere in the documentation about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants