Unable to import Okhttp tls to kotlin project - kotlin

I am trying to import OkHttp TLS to be able to use certificates and other OkHttp TLS functionality
my build.gradle.kts looks like this
implementation ("com.squareup.okhttp3:okhttp-tls")
However, gradle is unable to find this module
Could not find com.squareup.okhttp3:okhttp-tls
Unsure if okhttp tls is not imported this way any longer

Maybe you want to try the following
implementation("com.squareup.okhttp3:okhttp:4.10.0")
You can take a closer look at the docs
dependencies {
// define a BOM and its version
implementation(platform("com.squareup.okhttp3:okhttp-bom:4.10.0"))
// define any required OkHttp artifacts without version
implementation("com.squareup.okhttp3:okhttp")
implementation("com.squareup.okhttp3:logging-interceptor")
}

Related

How to provide an HttpClient to ktor server from the outside to facilitate mocking external services?

I am trying to provide an HttpClient from the outside to my ktor server so that I can mock external services and write tests, however I get this exception when I run my test:
Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
io.ktor.server.application.DuplicatePluginException: Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
at app//io.ktor.server.application.ApplicationPluginKt.install(ApplicationPlugin.kt:112)
at app//com.example.plugins.HTTPKt.configureHTTP(HTTP.kt:13)
at app//com.example.ApplicationKt.module(Application.kt:14)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:39)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:38)
and thats a bit unexpected to me because I am not applying the Compression plugin twice as far as I can tell. If I run the server normally and manually call my endpoint with curl then it works as expected. What am I doing wrong?
I added a runnable sample project here with a failing test.
sample project
official ktor-documentation-sample project.
The problem is that you have the application.conf file and by default, the testApplication function tries to load modules which are enumerated there. Since you also explicitly load them in the application {} block the DuplicatePluginException occurs. To solve your problem you can explicitly load an empty configuration instead of the default one:
// ...
application {
module(client)
}
environment {
config = MapApplicationConfig()
}
// ...

How to generate openapi client from uri in Gradle

I'm probably trying to do something strange, since this doesn't seem like a common question (or maybe I'm asking it all wrong). I was expecting this to be straightforward.
Basically, what I am looking for is a way to do the same as the following, except by using the gradle openapi-generator plugin:
openapi-generator generate -i www.example.com/openapi-doc -g spring
What I have tried is the following (and the associated errors):
inputSpec.set("www.example.com/openapi-doc") --> Cannot convert URL {} to a file
inputSpec.set(URL("www.example.com/openapi-doc").readText()) --> specified for property 'inputSpec' does not exist
The actual code looks something like this:
tasks.register<GenerateTask>("generateClient") {
validateSpec
generatorName.set("spring")
library.set("spring-cloud")
// inputSpec.set("$openapiSpecDir/client/openapi.json") <-- *I am currently using a file, which I don't want to do*
inputSpec.set("https://www.example.com/openapi-doc")
outputDir.set(generatedClientDir)
apiPackage.set("org.example.api")
modelPackage.set("org.example.model")
skipOverwrite.set(false)
templateDir.set("$rootDir/src/main/resources/openapi/templates/client")
configOptions.put("java8", "false")
configOptions.put("serializationLibrary", "jackson")
configOptions.put("dateLibrary", "java8")
}
Assuming you're using the OpenAPI Generator Gradle Plugin, at the time of writing this answer, getting the inputSpec from a URL is not supported. However, for Maven this has been implemented (Issue #2241 closed with PR #3826), so chances are good to have it implemented with a feature request that gets the Gradle plugin on par with its Maven counterpart.
That being said, you may want to look into Gradle Download Task. Gradle Download Task is a plugin that let's you download files from a URL. The downloaded file can be used to feed it into the OpenAPI generator.

Failed to resolve: org.jetbrains.anko:anko:1.10.5

i have add $anko_version in build.gradle(project)
and the add dependencies in build.gradle(app) but Failed when i try to sync.
I just implemented, and it works
implementation "org.jetbrains.anko:anko:0.10.5"
You should use the latest version for anko, and that is
implementation "org.jetbrains.anko:anko:0.10.5"
There is no version like 1.10.5. Check the anko documentation

Apache CXF + JavaFX No conduit initiator was found for the namespace

I'm triying to run a JavaFX Rest client using CXF. A very simple test. When I try to get an URL I get the org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http. I took a look at some related questions here, but no luck. Any help would be appreciated.
Then only maven dependency I added was cxf-rt-rs-client 3.1.0
The code is:
WebClient client = WebClient.create("http://www.stackoverflow.com");
client.type("text/html").accept("text/html");
System.out.println(client.get());
Stacktrace:
Caused by: org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http.
at org.apache.cxf.bus.managers.ConduitInitiatorManagerImpl.getConduitInitiator(ConduitInitiatorManagerImpl.java:110)
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:104)
at org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:77)
at org.apache.cxf.message.ExchangeImpl.getConduit(ExchangeImpl.java:159)
at org.apache.cxf.interceptor.MessageSenderInterceptor.getConduit(MessageSenderInterceptor.java:71)
at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:624)
at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1100)
The shading overwrites bus-extension.txt file. Programmatically your can fix it by initializing it.
void initializeCxf() {
final Bus defaultBus = BusFactory.getDefaultBus();
final ConduitInitiatorManager extension = defaultBus.getExtension(ConduitInitiatorManager.class);
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory());
}
Based on the comment by #hba you can also try following in case the above does not work
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory(defaultBus));
You are fine with your Maven dependencies.
Client construction looks a bit off per CXF 3.x guides, wherein JAX-RS 2.0 is supported.
See AX-RS 2.0 Client API.
Try this code:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
Response response = target.request().get();
System.out.println(response.getEntity().getClass().getName());
Using this code, you will learn the response entity is an input stream .. a sequence of characters being the HTML content of the StackOverflow home page.
If you're feeling adventurous, and to demonstrate I'm not a charlatan, add the following dependency to your POM:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
and then attempt this:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
System.out.println(IOUtils.toString((InputStream) target.request().get().getEntity(), "UTF-8"));
You will be rewarded with a textual rendering (on standard output) of the StackOverflow home page – equivalent to performing a "view source" operation in your browser.
I don't know what your ultimate goal is, but if you're attempting to build anything useful from information on the StackExchange network, I suggest use of their APIs documented here.
Best of luck!
I got the same exception when using Apache CXF REST client in JavaFX project. The code is below:
MyClass rest = (MyClass) JAXRSClientFactory.create(endpoint, MyClass.class, Collections.singletonList(new JacksonJsonProvider()));
System.out.println("Service health: " + rest.health());
A test with plain Java project works fine with the same code and same dependencies. It is apparently a conflict between JavaFX and Apache CXF. I am trying to figure out why.
If you guys already solved this issue, that should be great to update this thread, which is the only result on Google search.
Updated solution:
After a while, I found that the default Maven project does not include enough the dependencies in the plugin "maven-dependency-plugin". I tried to add more packages in the list but still not work. So the final solution is in this thread: How to package an Apache CXF application into a monolithic JAR with the Maven "shade" plugin. Shade plugin is much better and works.

Weblogic 12c HibernateValidator ClassLoading issue

Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.