在新的机器上，我们希望安装 OpenJDK 11。 可以分别执行下面的命令来进行安装。 查看可用的版本 使用命令 dnf search jdk 来搜索可用的版本。 Last metadata expiration check: 0:16:42 ago on Fri 13 Nov 2020 09:42:19 AM EST. ================================================= Name & Summary Matched: jdk ================================================== java-11-openjdk-demo.x86_64 : OpenJDK Demos 11 java-1.8.0-openjdk-demo.x86_64 : OpenJDK Demos 8 java-11-openjdk-jmods.x86_64 : JMods for OpenJDK 11 java-11-openjdk-src.x86_64 : OpenJDK Source Bundle 11 java-1.8.0-openjdk-src.x86_64 : OpenJDK Source Bundle 8 java-11-openjdk.x86_64 : OpenJDK Runtime Environment 11 copy-jdk-configs.noarch : JDKs configuration files copier java-1.8.0-openjdk.x86_64 : OpenJDK Runtime Environment 8 java-11-openjdk-javadoc.x86_64 : OpenJDK 11 API documentation java-1.8.0-openjdk-javadoc.noarch : OpenJDK 8 API documentation java-11-openjdk-devel.x86_64 : OpenJDK Development Environment 11 java-1.8.0-openjdk-devel.x86_64 : OpenJDK Development Environment 8 java-11-openjdk-headless.x86_64 : OpenJDK Headless Runtime Environment 11 java-1.8.0-openjdk-accessibility.x86_64 : OpenJDK 8 accessibility connector java-1.8.0-openjdk-headless.x86_64 : OpenJDK Headless Runtime Environment 8 java-11-openjdk-javadoc-zip.x86_64 : OpenJDK 11 API documentation compressed in single archive java-1.8.0-openjdk-javadoc-zip.noarch : OpenJDK 8 API documentation compressed in single archive ===================================================== Summary Matched: jdk ===================================================== jmc-core.noarch : Core API for JDK Mission Control jmc.x86_64 : JDK Mission Control is a profiling and diagnostics tool icedtea-web.noarch : Additional Java components for OpenJDK - Java browser plug-in and Web Start implementation 从上面的搜索结果中，我们可以看到版本java-11-openjdk-devel.x86_64 是我们需要的版本。       安装 在确定需要安装的包后，可以运行下面的命令： dnf install java-11-openjdk-devel.x86_64 来进行安装。       在上面的命令行中，输入 Y 来进行安装。 随后就可以看到安装成功的界面。       校验安装 在安装成功后，运行命令 java --version 来确定安装的 Java 版本是否正确。 [root@vps263579 ~]# clear [root@vps263579 ~]# java --version openjdk 11.0.9 2020-10-20 LTS OpenJDK Runtime Environment 18.9 (build 11.0.9+11-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11-LTS, mixed mode, sharing) [root@vps263579 ~]#     https://www.ossez.com/t/centos-8-openjdk-11/705

在 CentOS 8 上安装 jenkins 之前，需要确定已经正确安装了 JDK。 安装 JDK 的方法，请参考：CentOS 8 安装 OpenJDK 11 设定仓库和安装 在安装 Jenkins 之前，需要在你的操作系统中设置好仓库。 依次运行下面的命令： sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key sudo dnf update sudo dnf install jenkins sudo systemctl daemon-reload   CentOS-jenkins-install-01910×527 8.97 KB   运行 Jenkins 使用下面的命令来运行： systemctl start jenkins 随后可以使用 systemctl status jenkins 来查看运行的状态。   CentOS-jenkins-install-02927×527 35.1 KB   校验安装 如果一切顺利，可以通过 IP 地址，访问 8080 端口。   CentOS-jenkins-install-03941×585 29.8 KB   如果你能够看到上面的界面，就说明你的 Jenkins 已经安装成功了。 https://www.ossez.com/t/centos-8-jenkins/706

在调试一个 JQuery 页面的时候，浏览器提示错误。 Uncaught ReferenceError: $ is not defined   jquery-011091×434 16.2 KB   解决办法 你需要查看下你的 Jquery script。 如果你使用的是： <script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script> 那么你需要将 slim 去掉，修改为： <script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script> 就可以了。 https://www.ossez.com/t/jquery-uncaught-referenceerror-is-not-defined/640

在使用 CORS 测试的时候，我们得到下面的错误提示： Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8080/search/user. (Reason: header ‘authorization’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response).     问题解决 如果你使用的是 Spring 进行 API 编写的话。 出现这个问题的原因在于你返回的 http 请求的 header Authorization 这个选项。 在你的过滤器中，你应该添加下面的一段内容： httpServletResponse.setHeader("Access-Control-Allow-Headers", "Authorization, Origin, X-Requested-With, Content-Type, Accept"); 需要注意的是，根据官方的文档中的说明 Access-Control-Allow-Headers: * 是可以使用通配符的。 但是 Authorization 的头不能使用通配符，必须单独列出。 因此，需要在 Spring API 返回的头中添加上面的代码。 上面的代码表示告诉前端 CORS 的设置，以避免出现跨域访问的问题。     上面的配置，你可以在 Spring 的过滤器中进行配置。 当你配置成功后重启服务器，在进行跨域测试。 你会看到测试成功的提示：     同时在浏览器的网络调试部分，我们应该能够看到相应的头中也添加了 Authorization。     跨域访问比较难调试的问题就是不同的地方有不同的错误，需要根据前端和后端同时来进行调试。但，浏览器的调试窗口也给了比较完整的提示。 按照浏览器的调试提示来调试就可以了。 https://www.ossez.com/t/spring-api-cors-reason-header-authorization-is-not-allowed/639

在开发 API 和前端的时候，最麻烦的就是一个 CORS 测试。 你不知道你的 API 是否允许 CORS，也不知道是不是因为前端的原因。 但是 CORS 这个跨域访问确实让人非常头疼。 ## 写个页面 为了解决这个问题，我们用 HTML 写了个页面，这个页面可以对跨域访问进行一些小测试。 请查看页面在 GitHub 上的完整源代码： https://github.com/cwiki-us-demo/java-tutorials/blob/master/src/main/resources/html/cors.html 上面的代码主要是通过 JQuery 发送一个跨域请求到 API，来判断 API 返回的数据是否能够支持跨域访问。 另外，如果你的的 API 还需要添加 Bearer 访问令牌的话，你可以在输入对话框中输入需要的 Bearer Token。 否则你可以留空，AJAX 的请求将不会设置访问令牌。     如果没有问题，你将会看到弹出成功的对话框。 如果没有任何反应，你需要通过浏览器的 F12 ，打开调试对话框，然后查看网络。     比如说，上面的图片中，我们得到的错误代码是 403，这是因为我们没有设置 Token 的值，我们的 API 是需要设置 Token 值的。   https://www.ossez.com/t/spring-api-cors/638

现在很多编译器和软件都开始要求使用 JDK 11 了。 因此我们希望在 CentOS 上安装 JDK 11。 运行下面的命令： yum install java-11-openjdk-devel 如果你的系统中还装有不同版本的 JDK 的话。你需要运行： alternatives --config java 来选择默认的 JDK。     随后你就可以验证安装的 JDK 了。 https://www.ossez.com/t/centos-7-jdk-11/637

利益相关，都用过。现公司是 MS 的合作伙伴，主推 Azure。 但是开发来说 Azure 实在是不敢恭维，对开源社区实在是太闹心，各种 SDK 文档太差了。 抛开价格不说，主要说说功能。 AWS 各种开发文档非常稳定，健全，界面好用，SDK 还没有出现过 Testing 过不去的情况。 如果你是 Java 的深度使用者，AWS 不要太容易。 各种 SDK 和文档基本上都能让你解决问题，至少不会迷失在界面中的各种授权。 唯一差点就是报表和统计功能，这东西是大学生的毕业设计吗？太难看，太粗糙。 Azure 开发文档就各种蛋疼了。配置一团糟，经常不知道要干什么，Azure 主要和微软的产品深度融合。如果你的公司是微软产品的重度使用者，包括数据库。Azure 绝对是不错的选择。     Google 说心里话，Google 这云服务是打酱油的吗？压根没有花心思呀。至少现在不在考虑范围内了。     好不容易给 Google 找个图，还是乌云，不过也挺应景的。 总结来说就是： 如果你的公司走的是开源路线，Spring 全家桶，加上 MySQL 的开源数据库，准备 CentOS 搞搞，Oracle 这东西也用不上的话，还是用 AWS 吧。 Azure 和微软的产品融合度太深，你没有办法跳出微软的魔掌。政府不缺钱的话，整微软没啥问题。 小公司，光一个 Office 的许可证都能头疼半天。所谓的安全性，有时候在经济利益驱动下真的是可以牺牲的。 Azure 的安全性其实就是深入到每一步的权限认证，这个真的是双刃剑，权限认证太多，让开发小组特别头疼，经常错误原因莫名其妙。 举例来说，配置一个无服务数据库，因为超过 1 小时没有连接，服务器会自动进入休眠状态。如果你这时候用连接，直接错误。因为服务器要重启嘛，重启要时间呀。 很多人总迷信 MSSql 和 Oracle，不可否认，这大厂的东西确实不错。 PGSQL 和 MariaDB 对初创企业来说真不错的。就那么多数据量，MSSQL 和 Oracle 装都装晕了。Sql 函数有时候还不通用。启动个客户端都要半天。 离开数据谈云服务都是耍流氓。 一句话来说，AWS 对开源社区比较友好，Azure 不弄晕你不偿命。 https://www.ossez.com/t/azure-aws-google/636

我们会使用 Postman 测试 API 的测试功能。 如果我们直接使用 Postman 发送数据到 API ，API 会返回二进制的数据，然后 Postman 会尝试打开，很不幸的是，你将会看到下面的内容。 解决问题的办法 有 2 个办法可以解决这个问题。 一个是在发送的时候，用发送和下载来替代发送按钮。 另一个办法就是在返回的结果中保存文件。 在返回结果的右下角可以选择保存文件。 这样你的返回结果就可以保存为文件了。 https://www.ossez.com/t/postman-api/635

你的 API 可能会返回下面的情况。 { "timestamp": "2020-11-02T18:14:55.353+00:00", "status": 400, "error": "Bad Request", "message": "", "path": "/myfile/upload" } Postman 的截图为：     很多人看到这个错误可能就是一脸茫然，错误到底在那里？ 首先可以确定的是，你的 API 并没有获得你的请求数据，可以忽略去调试 API，这个问题就是你发送给 API 的数据的问题。 最有可能的是前端提交数据的字段名称或者是字段类型和后台的实体类型不一致。比如说你后台需要的是 JSON 数据，结果你发了一个文件过去。 还有一个情况就是你提供的字段在后台没有映射，但是后台需要一个字段不为空。 如上面我们的 400 错误，错误的原因就是字段 filename，我们使用的是 filename，但是后台使用的字段是 file_name。 这会导致后台的变量 file_name 没有办法获得参数而向前台发出 400 错误。   变量名和后台不一致，后台使用变量：file_name。 因此，你只需要改正变量名就可以了。 https://www.ossez.com/t/postman-bad-request/634

在 Confluence 的页面中，你可以对 Confluence 进行下面的一些操作： 拷贝（Copy）一个页面或者子页面 删除（Delete）一个页面或者一个页面的特定版本 通过 页面通知（page notifications）通知功能来对页面进行关注并且了解有关页面的更新 通过 页面历史（page history）功能来管理和比较页面的版本历史。 搜索（Search）页面的内容，同时也包括附件。 导出页面为 Word, PDF, HTML 或 XML 格式 点赞（Like）一个页面 我们建议你不要在页面或者附件名中使用特殊字符串。如果你使用了特殊的字符串，页面或者附件可能不能在 Confluence 的搜索中找到，同时也有可能导致 Confluence 的功能损坏。 如果你对一个页面进行重命名，Confluence 将会自动更新与你重命名相关的所有页面。但是针对一些 宏（Macros）中的内容，Confluence 是没有办法进行更新的。外部站点的链接将会被损坏，除非你使用的是永久链接。请参考 Working with Links 页面中的内容来获得更多的信息。 Confluence 的页面的一些基本操作是在页面右上角功能下拉菜单中显示出来的。     可以通过单击上面的链接，进入你需要的功能。 Confluence 页面大小的说明 根据 Confluence 官方的文档说明，Confluence 页面不支持过大的内容，差不多在 5MB 左右。 在你对大的页面内容进行保存的时候你可能会遇到 Confluence 的一些问题。Confluence 能够支持大概 5MB 的内容（这个 5MB 的内容不包括页面中的附件）。基本上相当于 800,000 个单词（字符）。如果你发现你的 Confluence 页面在保存的时候比较困难，你应该将这个页面拆分成更小的页面。 同时也不建议在一个页面中存储过多的内容，这会加大页面载入难度和速度。 https://www.ossez.com/t/confluence-6/633