I am working on gRPC client(JavaFX) and server(SpringBoot with gRPC starter). The two application are independent and do not share any files together. The server is complete for testing(here)
I would like to make JavaFX client independently from the gRPC server, i.e without including gRPC server as a maven dependancy in client POM.
What gRPC client specific dependencies can i add in the javafx application and how to send request to the server?
According to the official documentation (http://www.grpc.io/docs/quickstart/java.html) the examples can be used as a starting point https://github.com/grpc/grpc-java/blob/master/examples/build.gradle
The dependencies you need are
compile "io.grpc:grpc-netty:${grpcVersion}"
compile "io.grpc:grpc-protobuf:${grpcVersion}"
compile "io.grpc:grpc-stub:${grpcVersion}"
where ${grpcVersion} is whatever released version of gRPC you may want to use. This notation is for the Gradle build tool, however transforming to Maven coordinates is easy, such as
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty</artifactId>
<version>1.2.0</version>
</dependency>
You'll find another working example at https://github.com/aalmiray/javatrove/tree/master/chat-02
Related
I got completely stuck. I want to use CDI2 with Servlets to write a simple web app. However, the beans not get loaded.
I get the following error in JBoss or Payara or Weld (if running as Main Application):
WELD-001524: Unable to load proxy class for bean Managed Bean [class MyBean] with qualifiers [#Any #Default]
Does anyone still use CDI2 or has a running modern example?
I compile with maven.
warm regards,
Alex
I found it out myself. I had the wrong dependencies. I got confused because of Jakarta. I used the CDI-2 maven dependency. So I updated to Jakarta. Right? This is the way to go, right?
I can deploy. Payara-Micro works. JBoss (WildFly should do the same)
However, Payara Micro does not get track of the URL patterns of simple Servlets, although still, one can call it over the client. (Intellij has a CDI tab, gives a nice overview itself)
...
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>8.0.0</version>
<scope>provided</scope>
</dependency>
I am trying to mock the objects returning from the server to the client. So I need to deploy my Wiremock Code in Server. So is this possible or is there any other way to achieve this scenario?
And I am completely new to Wiremock. So How can I run this on JBoss?
I followed the method of running wiremock-standalone jar and I am able to capture my request and response.
But my main question is, can I able to get mock responses from #Test methods?
You could use Arquillian to test JBoss. You can test microservices using this approach and use Jboss Forge ~ another tool, to speed up the testing/dev. The start guide with Forge is here.
You will just need to add on the pom.xml the dependency for Arquillian:
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
<version>1.0.0.CR9</version>
<scope>test</scope>
</dependency>
To avoid any library clash you can use the standalone version of WireMock. I used it with wildly (JBoss AS) adding the following dependency:
<dependency>
<groupId>com.github.tomakehurst</groupId>
<artifactId>wiremock-jre8-standalone</artifactId>
<version>2.27.2</version>
<scope>test</scope>
</dependency>
For further information see http://wiremock.org/docs/download-and-installation/
What you've done with wiremock-standalone is very similar to what arquillian does in an integration test. You write your server code then you test it inside a container using a client extension.
Try reading the documentation at http://arquillian.org/arquillian-core/
I want to start using the framework Spring Cloud Contract for contract testing. But does Spring Cloud Contract support JavaScript and JMS?
I haven't found any information about this.
As for the JMS, we do support it either via spring-integration or Apache Camel. You can also write your own JMS support. It's enough to register a couple of beans.
As for Javascript and non-jvm languages. There's no out of the box support but we have a process for that. The workflow is described here (in those cases the consumer is a Java app but in the next section I'll describe how the flow would differ) - https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_common_repo_with_contracts or https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_step_by_step_guide_to_cdc. We will try to obviously simplify the process but currently there's a bunch of manual tasks to be done (not very tedious though).
The consumer can very easily download and run the stubs. Just clone https://github.com/spring-cloud-samples/stub-runner-boot, build it and push the fat jar to your Nexus/Artifactory. This application will be used by the consumers to automatically download stubs and run them locally. As a consumer you can then call java -jar stub-runner-boot --stubrunner.ids="com.example.groupid:artifactid:classifier:version:8090" --stubrunner.repositoryRoot="http://localhost:8081/artifactory/libs-release-local" . That way the application will start, download the provided jar with stubs from the given address where your artifactory is. Now your front end application can call the stubs of the producer at localhost:8090.
Of course we will try to simplify the cloning and pushing process (https://github.com/spring-cloud/spring-cloud-contract/issues/37) etc. but for now you have to do those 2 steps manually.
UPDATE:
With this article https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world we're presenting a way how to work in a polyglot environment. It's enough to use the provided docker images to run contract tests against a running application and to run the stub runners too.
Commonly known, that for usage of different jars we need add them to SoapUI/../ext/ directory. for example, for correct work of jdbc requests with IBM/..AS400JDBC Driver we need to add jt400.jar to /ext dir.
But I have problem: my client implements new policy - direct forbidding of using any jars locally, only as dependencies like
<dependency>
<groupId>net.sf.jt400</groupId>
<artifactId>jt400-full</artifactId>
<version>6.0</version>
</dependency>
I successfully uses it in my POM's for CI, but I also need to run my projects in SOAPUI.
So, question is: is there any way to add dependency for external jars, - exists in SoapUI preferences somewhere/somehow? Goal is to remove all jars from soapui/../ext and somehow add dependencies on official.
Sincerely,
Dmitry.
I have thought about this some more: You should be able to roll your own soapui.bat, based on the provided one.
Copy the provided soapui.bat to your desktop.
Modify the variable SOAPUI_HOME to point to your install.
Modify the variable CLASSPATH to include your jars.
Run the modified soapui.bat.
I'm deploying an ear with an EJB onto glassfish 3.1 which I want to call using the appclient script.
The EJB has a method with as parameter a model object which is defined in a separate library.
If I want to use the appclient script I have a Main class with a main method which calls the EJB.
This is also put into a separate jar which is also deployed onto glassfish.
As the model object is located in a separate library I need it in the client jar but also in the EJB.
So I need to reference it somehow in the client jar.
The client jar is a jar (duh) so I cannot add other jars. The Java EE 6 docs say that I should create an ear with the libs but if I do that it doesn't deploy because an ear needs at least an ejb or web module and my client lib has neither.
The solution I found is using the assembly plugin/jar-with-dependencies. This plugin creates a new jar which contains all classes of all dependencies.
This solution works but I'm wondering if this is the way to go or I'm missing something obvious because I cannot imagine this is required. EJB's usually have model objects as parameters so this situation will happen a lot.
So my question is: is there a way to tell glassfish to reference the shared libraries between the app client jar and the ejb jar.
The way I do this is like this:
Separate Maven project with the model. In my case that's a bunch of simple POJOs with JPA and JAX-B annotations, some constants, etc. In Maven, I define this as an OSGi bundle, by specifying <packaging>bundle</packaging>. I call this project MyAppInterface.
Separate Maven projects for other elements that need to deal with the model. In my case, I have one Java EE application with EJBs, Database facade, REST servlet; I have an Integration-Test project which only does tests; a GWT application; etc... In those projects I specify the dependency to the model:
<dependency>
<groupId>com.skalio</groupId>
<artifactId>MyAppInterface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
When deploying MyAppInterface to Glassfish, I use the following syntax:
asadmin deploy --type osgi --name MyAppInterface /path/to/MyAppInterface-1.0-SNAPSHOT.jar
I understand it that this is placing the model on the classpath of Glassfish, similar to a mysql-connector, only OSGi-style.
I let all these projects be built by a central jenkins CI server, which deploys the artifacts to our internal maven repository. We then add the internal repository in pom.xml of each project. As a result, everyone automatically works with the latest stable MyAppInterface, even if they don't have the code checked out in NetBeans / Eclipse.
Let me know if you need more examples.