概述Spring Boot 提供了 Maven 插件 spring-boot-maven-plugin，可以很方便的将我们的 Spring Boot 项目打成 jar 包或者 war 包。考虑到部署的便利性，我们绝大多数（99.99%）的场景下，都会选择打成 jar 包，这样一来，我们就无需将项目部署于 Tomcat、Jetty
作用域不同，写在某一个namespace里面，是在该namespace中起作用，写在外面，则是全局作用域了，测试一下就知道了。
例如，两个开发团队可能都创建了名为File的类，但如果这两个类位于不同的名称空间中，那么就不会出现冲
到这里先知道 main 函数参数的形式即可，它第一个参数为 int 类型的变量，第二个参数是一个char* 类型的指针数组
"/"代表触发步进(step)，"/"前面的值代表初始值("*"等同"0")，后面的值代表偏移量，比如"0/25"或者"*/25"代表从0分钟开始
Visual Studio 2019下载安装步骤可以看： 这里不赘述，默认电脑上已经安装好了。1、打开安装好的Visual Studio后，选择创建新项目。2、找到选择C#下面的Windows 窗体应用，然后下一步起名和文件存放位置 如果找不到Windows 窗体应用，就参考这篇文章： 原因是在安装Visual Studio 2019的时候没有选择安装.Net的相关组件，如果安装的时候没点，那么就
前序前面我的一系列文章对 Spring AOP 进行了比较详细的讲述，相信对于 Spring AOP 你有一个比较深入的理解，如果你不是很了解，建议先查看我前面的这一系列文章，因为 Spring 事务是借助于 Spring AOP 实现的。由于这段时间有点忙（太懒了~），没能及时更新 Spring AOP 在 Spring 内部的应用相关内容，趁着对它还有一点印象，我们一起来看看 Spring 事
通过前面关于 Spring AOP 的所有文章，我们对 Spring AOP 的整个 AOP 实现逻辑进行了比较详细的分析，例如 Spring AOP 的自动代理，JDK 动态代理或 CGLIB 动态代理两种方式创建的代理对象的拦截处理过程等内容都有讲到。本文将会分析 Spring AOP 的注解驱动，如何引入 AOP 模块，包括如何处理 Spring AOP 的 XML 配置。在 Spring
在前面几篇文章依次介绍了 Spring AOP 自动代理的整个过程，入口在 AbstractAutoProxyCreator 这个类中，它实现了几种 BeanPostProcessor接口，结合 Spring IoC，在 Bean 的加载过程中支持创建代理对象，通常在 Bean 的初始化后，也就是 Bean 处于一个“成熟态”的时候进行 AOP 代理。整个的处理过程比较复杂，需要找到当前 Spri
在前面的《Spring AOP 自动代理（一）入口》文章中，分析了 Spring AOP 自动代理的入口是 AbstractAutoProxyCreator 对象，其中自动代理的过程主要分为下面两步：筛选出能够应用于当前 Bean 的 Advisor找到了合适 Advisor 则创建一个代理对象， JDK 动态代理或者 CGLIB 动态代理上一篇《Spring AOP 自动代理（二）筛选合适的通知
在上一篇《Spring AOP 自动代理（一）入口》文章中，分析了 Spring AOP 自动代理的入口是 AbstractAutoProxyCreator 对象，其中自动代理的过程主要分为下面两步：筛选出能够应用于当前 Bean 的 Advisor找到了合适 Advisor 则创建一个代理对象， JDK 动态代理或者 CGLIB 动态代理本文就接着上篇文章来分析筛选合适的通知器的处理过程，包含&
C#（C-Sharp）是Microsoft的新编程语言，被誉为“C/C++家族中第一种面向组件的语言”。然而，不管它自己宣称的是什么，许多人认为C#更像是Java的一种克隆，或者是Microsoft用来替代Java的产品。事实是否是这样的呢？ 本文的比较结果表明，C#不止是Java的同胞那么简单。如果你是一个Java开发者，想要学习C#或者了解更多有关C#的知识，那么本文就是你必须把最初10分钟
通过上一篇文章《Spring AOP 总览》我们对 Spring AOP 有了一个整体的认识，那么从本篇文章开始，我们一起来看看 Spring AOP 和 Spring IoC 是如何整合的，自动代理的过程做了哪些事情？首先我们得清楚 Bean 的加载过程，整个过程中会调用相应的 BeanPostProcessor 对正在创建 Bean 进行处理，例如：在 Bean 的实例化前，会调用
通过上一篇 《初识 JDK、CGLIB 两种动态代理》 文章我们对 Spring AOP 底层的 JDK 动态代理和 CGLIB 动态代理有了一定的了解，也知道如何简单地使用两种动态代理创建代理对象。相信上篇文章可以让你对 Spring AOP 有了一个初步的认识，那么接下来我们准备进入 Spring AOP 源码学习阶段。在开始 Spring AOP 源码学习前，本文会对 S
前段时间，我对 Spring IoC 的源码进行了比较全面的学习，并写下了数篇文章进行知识分享。在学习完 Spring IoC 的源码后，也没敢懈怠，趁热打铁，阅读了 Sping AOP 的相关源码，在有了 Spring IoC 的基础之后，你会发现 Spring AOP 的源码并不复杂，嘿嘿 ~在开始 Spring AOP 源码分析之前，我们先来了解一下其底层 JDK 动态代理和 CGLIB 动
目录什么是 AOP？为什么要引入 AOP？简述 AOP 的使用场景？简述 AOP 中几个比较重要的概念你知道哪几种 AOP 框架？什么是 AOP 代理？讲讲 JDK 动态代理？讲讲 CGLIB 动态代理？JDK 动态代理和 CGLIB 动态代理有什么不同？Spring AOP 和 AspectJ 有什么关联？Spring AOP 中有哪些 Advice 类型？Spring AOP 中 Adviso
@Bean 等注解的实现原理通过前面的一系列文章我们了解到 @Component 注解（及其派生注解）标注的 Class 类都会被解析成 BeanDefinition（Bean 的“前身”），然后会被初始化成 Bean 对象。那么 @Bean 注解不是 @Component 的派生注解，且用于标注方法，该注解的解析过程在前面的文章中没有提
Spring 应用上下文 ApplicationContext前面一系列文章都是围绕 BeanFactory 进行分析的，BeanFactory 是 Spring 底层 IoC 容器的实现，完成了 IoC 容器的基本功能。在实际的应用场景中，BeanFactory 容器有点简单，它并不适用于生产环境，我们通常会选择 ApplicationContext。ApplicationContext 就是大
// groovy 中定义变量// def 是弱类型，groovy会自动根据情况来给变量赋予对应的类型def i = 18;println i;// 字符串定义str1 =
更多信息详见spring官方文档y：https://spring.io/blog/2020/10/29/notice-of-permissions-changes-to-repo-spring-io-fall-and-winter-2
@Autowired 等注解的实现原理在上一篇《Bean 的属性填充阶段》文章中讲到，在创建一个 Bean 的实例对象后，会对这个 Bean 进行属性填充。在属性填充的过程中，获取到已定义的属性值，然后会通过 InstantiationAwareBeanPostProcessor 对该属性值进行处理，最后通过反射机制将属性值设置到这个 Bean 中。在 Spring 内部有以下两个 Instant
Bean 的属性填充阶段当我们显示或者隐式地调用AbstractBeanFactory 的 getBean(...) 方法时，会触发 Bean 的加载，在《开启 Bean 的加载》文章中分析了整个加载过程。对于不同作用域的 Bean，底层都会调用 AbstractAutowireCapableBeanFactory 的 createBea
单例 Bean 的循环依赖处理我们先回到《Bean 的创建过程》中的“从缓存中获取单例 Bean”小节，当加载一个 Bean 时，会尝试从缓存（三个 Map）中获取对象，如果未命中则进入后面创建 Bean 的过程。再来看到《Bean 的创建过程》中的“提前暴露当前 Bean”小节，当获取到一个实例对象（还未设置属性和初始化）后，会将这个“早期对象”放入前面的缓存中（第三个 Map），这里暴露的对象
Bean 的实例化阶段当我们显示或者隐式地调用AbstractBeanFactory 的 getBean(...) 方法时，会触发 Bean 的加载，在《开启 Bean 的加载》文章中分析了整个加载过程。对于不同作用域的 Bean，底层都会调用 AbstractAutowireCapableBeanFactory 的 createBean
Bean 的创建过程上一篇《开启 Bean 的加载》文章分析了 Bean 的整个加载过程，当我们显示或者隐式地调用AbstractBeanFactory 的 getBean(...) 方法时，会触发 Bean 的加载，会进行一系列的处理，具体实现可查看上一篇文章。对于不同作用域的 Bean，底层都会调用 AbstractAutowireCapableBean
目录1.global全局变量2.query查询3.function函数4.LHS加强4.1 复合值限制in/not in4.2 条件元素eval4.3 条件元素not4.4 条件元素exists4.5 规则继承5.RHS加强5.1 halt5.2 getWorkingMemory5.3 getRule6.总结参考资料1.global全局变量global关键字用于在规则文件中定义全局变量，它可以让应
目录0.项目搭建1. 规则文件1.1 构成1.2规则体2.基础语法2.1 注释2.2 Pattern模式匹配2.3比较操作符2.3.1 实践2.3执行指定规则3.Drools内置方法3.1update方法3.2 insert方法3.3 retract方法4. 规则属性4.1 enabled属性4.2 dialect属性4.3 salience属性4.4 no-loop属性4.5 activatio
本文主要对Drools的使用业务场景做简单介绍。规则引擎规则引擎：全称为业务规则管理系统，英文名为BRMS(即Business Rule Management System)。规则引擎的主要思想是将应用程序中的业务决策部分分离出来，并使用预定义的语义模块编写业务决策（业务规则），由用户或开发者在需要时进行配置、管理。 需要注意的是规则引擎并不是一个具体的技术框架，而是指的一类系统，即业务规则管理
开启 Bean 的加载前面的一些列文章对面向资源（XML、Properties）、面向注解定义的 Bean 是如何被解析成 BeanDefinition（Bean 的“前身”），并保存至 BeanDefinitionRegistry 注册中心里面，实际也是通过 ConcurrentHashMap 进行保存。Spring 底层 IoC 容器 DefaultListableBeanFactory，实现
BeanDefinition 的解析过程（面向注解）前面的几篇文章对 Spring 解析 XML 文件生成 BeanDefinition 并注册的过程进行了较为详细的分析，这种定义 Bean 的方式是面向资源（XML）的方式。面向注解定义 Bean 的方式 Spring 的处理过程又是如何进行的？本文将会分析 Spring 是如何将 @Component 注解或其派生注解 标注
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
