Everything使用技巧www.hi-channel.com出品本文为H4海畅智慧原创文章，未经允许不得进行商业盈利性转载,非盈利性商业转载请注明出处www.hi-channel.com 1.Everything下载地址http://www.voidtools.com/本教材使用版本参见www.hichannel.net下载地址2.Everything手机版本可以实时手机连接看视频哦，请加入Q
Drools 为了对非开发人员更加友好，提供了dsl语言的支持，通过dsl再转换成drl文件来进行执行。DSL简介DSL == Domain Specific Language 以贴近业务领域的方式,即以类自然语言的方式来构造软件,使得我们不用花费太多精力就能看懂代码所对应的业务含义 。 它是创建规则语言的一种方式，致力于解决我们的问题域 。 DSL相当于一个转换器,它能将某一领域内的术语
1.人类可读的规则这一章的标题可能会冒犯一些开发人员。到目前为止，我们所讨论的所有规则都不是人类可读的吗?难道我们人类吗?本章背后的想法是引入其他方法来定义Drools中的规则，这些规则更便于用户使用。在本章中，“人”指的是非技术人员。 到目前为止，我们已经介绍了一种定义规则和知识的方法:DRL语言。这种语言即使在大多数情况下是不合适的，对于没有技术背景的用户来说也是不合适的。即使这样，DRL也需
决策表我们在drools规则引擎初探里做了简单介绍，这里主要是介绍如何通过java代码来把这个excel文件和drools关联起来，如何使其达到我们想要的效果。这里假设我们在resources目录下有这么一个文件：/drools/decisiontable/mydecisiontable.xls然后在http://docs.jboss.org/drools/release/6.4.0.Final/
KieServices：kie整体的入口,可以用来创建Container,resource,fileSystem等KieContainer： KieContainer就是一个KieBase的容器，可以根据kmodule.xml 里描述的KieBase信息来获取具体的KieSessionKieBase： KieBase就是一个知识仓库，包含了若干的规则、流程、方法等，在Drools中主要就是规则和方
一、简介JetCache是一个基于Java的缓存系统封装，提供统一的API和注解来简化缓存的使用。 JetCache提供了比SpringCache更加强大的注解，可以原生的支持TTL、两级缓存、分布式自动刷新，还提供了Cache接口用于手工缓存操作。 当前有四个实现：RedisCache、RedisLettuceCache、CaffeineCache、LinkedHashMapCache。特性：通
前序前面我的一系列文章对 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 动态代理本文就接着上篇文章来分析筛选合适的通知器的处理过程，包含&
通过上一篇文章《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 就是大
更多信息详见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 的加载前面的一些列文章对面向资源（XML、Properties）、面向注解定义的 Bean 是如何被解析成 BeanDefinition（Bean 的“前身”），并保存至 BeanDefinitionRegistry 注册中心里面，实际也是通过 ConcurrentHashMap 进行保存。Spring 底层 IoC 容器 DefaultListableBeanFactory，实现
BeanDefinition 的解析过程（面向注解）前面的几篇文章对 Spring 解析 XML 文件生成 BeanDefinition 并注册的过程进行了较为详细的分析，这种定义 Bean 的方式是面向资源（XML）的方式。面向注解定义 Bean 的方式 Spring 的处理过程又是如何进行的？本文将会分析 Spring 是如何将 @Component 注解或其派生注解 标注
解析自定义标签（XML 文件）上一篇《BeanDefinition 的解析阶段（XML 文件）》文章分析了 Spring 处理 org.w3c.dom.Document 对象（XML Document）的过程，会解析里面的元素。默认命名空间（为空或者 http://www.springframework.org/schema/beans）的元素，例如 <
BeanDefinition 的解析阶段（XML 文件）上一篇文章《BeanDefinition 的加载阶段（XML 文件）》获取到 org.w3c.dom.Document 对象后，需要通过 DefaultBeanDefinitionDocumentReader 进行解析，解析出 XML 文件中定义的 BeanDefinition 并进行注册，先来回顾一下上一篇文章中的这段代
BeanDefinition 的加载阶段（XML 文件）上一篇文章 《Bean 的“前身”》 对 BeanDefinition 进行了介绍，Bean 是根据 BeanDefinition 配置元信息对象生成的。我们在 Spring 中通常以这两种方式定义一个 Bean：面向资源（XML、Properties）、面向注解，那么 Spring 是如何将这两种方式定义的信息转换成 B
目录1. 什么是 Spring Framework ？2. Spring Framework 的优势和不足？3. 你对 IoC 的理解？4. 为什么需要 IoC ？5. IoC 和 DI 的区别？6. IoC 容器的职责？7. 什么是 Spring IoC 容器？8. 构造器注入和 Setter 注入9. BeanFactory 和 ApplicationContext 谁才是 Spring Io
@SuppressWarnings，表示警告抑制，告诉编译器不用提示相关的警告信息。"rawtypes"，这个参数是告诉编译器不用提示使用基本类型参数时相关的警告信息。一般是在通过传参调用某个方法的时候进行标识。SuppressWarnings中类似的参数还有很多，比如：all: to suppress all warningsboxing: to suppress warnings relati
TypeDescriptor：类型描述符该类位于org.springframework.core.convert包下，convert包主要用于类型转换相关功能，在类型转换过程中，通常需要从一个类型转为另一个类型，而Java类型包含基本类型，数组、集合、泛型以及普通类型，该类试图将这些不同的类型使用一种统一的类型来表示，因此方法中提供了各种静态方法和不同的类型来获取一个TypeDescriptor实
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
