java-grpc 踩坑记录

最近的项目需要java和python之间的进程通信,想到了之前使用过的的grpc.

参考官方quickstart

  • JDK: version 7 or higher

看起来只依赖jdk,美滋滋

然后按照文档执行

./gradlew installDist

报错:

看起来是gcc或者clang的问题… 先装个clang再说,可能clang太常用了,所以文档没有提到,这下一定可以了。

然而又报错:

??????

看起来是stdc++的lib没有找到。

在centos上安装了:libstdc++.x86_64 4.8.5-28.el7_5.1 @updates
libstdc++-devel.x86_64 4.8.5-28.el7_5.1 @updates
libstdc++-static.x86_64

这回一定没问题了吧?

然而继续报错,变成了javedoc找不到

简直了。。。grpc的文档还是一如既往的辣鸡。。。目前还在坑里面,先把前面踩的坑记录一下。

然后继续报错:

 

好像不是很对啊…

文档固然辣鸡,但是会不会有其他打开方式?

于是跑到工程院那边请教了同事…发现果然打开方式不正确…

正确的方式是直接在依赖管理工具如maven中添加,并不需要手动编译安装…

参考这个搞它一发先

同时按照maven-in-five-minutes 了解一下maven的使用

Although hardly a comprehensive list, these are the most common default lifecycle phases executed.

  • validate: validate the project is correct and all necessary information is available
  • compile: compile the source code of the project
  • test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package: take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • verify: run any checks to verify the package is valid and meets quality criteria
  • install: install the package into the local repository, for use as a dependency in other projects locally
  • deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

There are two other Maven lifecycles of note beyond the default list above. They are

  • clean: cleans up artifacts created by prior builds
  • site: generates site documentation for this project

发现mvn package的时候会报几百行的错误

于是先执行mvn validate验证一下情况,
最上面的错误如下:

参考An exception occurred when I use maven plugin, Why?  发现可能是maven版本不行,去官网下载了目前的最近版本3.5.4,ok了

下一步该进行mvn compile,也ok

然后是mvn test,又是几百行错误…核心的信息是java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument

参考java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument

添加了两个依赖(再次吐槽grpc-java官方文档&demo的不靠谱)

似乎是ok了.

然后执行mvn package,继续报错,好在只有几十行…

摘重点: Unable to find a single main class from the following candidates

看样子是找不到程序入口在哪里了…好像很合理,毕竟grpc-java的example里每个文件都带了main函数

参考SpringBoot: Unable to find a single main class from the following candidates,在pom.xml中添加如下的属性就行了.

 

然后另一边,将python的server启动起来

注意ip和端口号要保持一致. ok了

 

最后的代码请参考grpc-java-maven-exmaple

spring 学习笔记

迫于生计,又要从零开始学习spring.

在这篇文章之前,对java的基础是2015年写过一个java大作业,对spring是一无所知。

为了学习spring,我按顺序做了以下事情:

 

 

 

 

 

 

[spring] 依赖注入

真是个不明觉厉的术语…其实是个特别简单的概念orz

用白话讲,如果一个class A中用到了class B的实例,那么class B的实例就是class A的依赖,如果不是在class A中定义class B的实例,而是通过某个接口,将class B的实例传入classA,就叫依赖注入。

 

依赖注入(DI)和控制反转(IOC)基本是一个意思,因为说起来谁都离不开谁。

简单来说,a依赖b,但a不控制b的创建和销毁,仅使用b,那么b的控制权交给a之外处理,这叫控制反转(IOC),而a要依赖b,必然要使用b的instance,那么

  1. 通过a的接口,把b传入;
  2. 通过a的构造,把b传入;
  3. 通过设置a的属性,把b传入;

这个过程叫依赖注入(DI)。

那么什么是IOC Container?

随着DI的频繁使用,要实现IOC,会有很多重复代码,甚至随着技术的发展,有更多新的实现方法和方案,那么有人就把这些实现IOC的代码打包成组件或框架,来避免人们重复造轮子。

所以实现IOC的组件或者框架,我们可以叫它IOC Container。

作者:phoenix
链接:https://www.zhihu.com/question/32108444/answer/220819349
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

参考资料:

Dependency Injection Demystified

What is dependency injection?