-
Notifications
You must be signed in to change notification settings - Fork 87
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
Exceptions when using together with AsyncHttpClient #87
Comments
So what we would need to do is to also rename the ahc-default.properties to something like play.shaded-ahc-default.properties and replace references to it. |
Yes please. |
Ok, unfortunately, "jar jar links" only supports changing the package name of the classes transformed. I've managed to rename the ahc-default.properties and ahc.properties files themselves, but unfortunately, references to these are hardcoded (as constants) in Unfortunately, the whole AysncHttpClientConfigHelper is written in a way that does not really allow outside modification/configuration. We could try to exclude it in the shading process and provide our own version of it, but that feels like a rather bad hack. |
A alternative to shading the async-http-client on a class-file level could be to include the async-http-client project as a sbt-source-dependency .. that way it might be possible to basically take the files and rewrite them directly (and thus making also changes to the constants in AsyncHttpClientConfigHelper .. but its another "hack". |
@domdorn do you have a PR for this? |
@wsargent I tried to adjust the shading process, but the shading library used only allows simple byte-code changes (changing package names) -> I was unable to change the constant. |
Hmm... I've got an idea... what if instead of replacing the variables in the ahc.properties, we're just adding to them?
to the file? That way, we still be providing the default file, and also provide our own properties. People can still change their settings in the other config file. WDYT? |
completely replacing the configuration properties resulted in errors when users where using the unshaded AHC-Client in their applications together with play-ws. As a workaround we take the original properties and _add_ our own properties to the file. This way, the unshaded client still finds its properties while our own version can be configured independently
Okay, I can address that in a patch release. |
* #87 add original + shaded configuration properties completely replacing the configuration properties resulted in errors when users where using the unshaded AHC-Client in their applications together with play-ws. As a workaround we take the original properties and _add_ our own properties to the file. This way, the unshaded client still finds its properties while our own version can be configured independently * #87 add original + shaded configuration properties forgot to add newline.
Closing by way of #149 |
completely replacing the configuration properties resulted in errors when users where using the unshaded AHC-Client in their applications together with play-ws. As a workaround we take the original properties and _add_ our own properties to the file. This way, the unshaded client still finds its properties while our own version can be configured independently
forgot to add newline.
* #87 add original + shaded configuration properties completely replacing the configuration properties resulted in errors when users where using the unshaded AHC-Client in their applications together with play-ws. As a workaround we take the original properties and _add_ our own properties to the file. This way, the unshaded client still finds its properties while our own version can be configured independently * #87 add original + shaded configuration properties forgot to add newline.
Sorry for cross-posting. I've written down the details of this issue at:
playframework/playframework#7056
It looks like (at least in my Play 2.6.0-M1 app) that the shaded AsyncHttpClientDefaults class reads the ahc-default.properties that are pulled in from the non-shaded version on my classpath.
The issue probably comes from
https://github.com/AsyncHttpClient/async-http-client/blob/async-http-client-project-2.0.27/client/src/main/java/org/asynchttpclient/config/AsyncHttpClientConfigHelper.java#L47
Where the current ThreadContext Classloader is used to lookup the properties instead a classloader based on the current class (which would then find the ahc-default.properties with the play.shaded prefix.
The text was updated successfully, but these errors were encountered: