- 18 3月, 2019 1 次提交
-
-
由 Sam Brannen 提交于
-
- 14 9月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-14699
-
- 17 4月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
AbstractApplicationContext collects early ApplicationEvents and publishes them once the multicaster is available Issue: SPR-12902
-
- 10 2月, 2015 2 次提交
-
-
由 Stephane Nicoll 提交于
Add support for annotation-based event listeners. Enabled automatically when using Java configuration or can be enabled explicitly via the regular <context:annotation-driven/> XML element. Detect methods of managed beans annotated with @EventListener, either directly or through a meta-annotation. Annotated methods must define the event type they listen to as a single parameter argument. Events are automatically filtered out according to the method signature. When additional runtime filtering is required, one can specify the `condition` attribute of the annotation that defines a SpEL expression that should match to actually invoke the method for a particular event. The root context exposes the actual `event` (`#root.event`) and method arguments (`#root.args`). Individual method arguments are also exposed via either the `a` or `p` alias (`#a0` refers to the first method argument). Finally, methods arguments are exposed via their names if that information can be discovered. Events can be either an ApplicationEvent or any arbitrary payload. Such payload is wrapped automatically in a PayloadApplicationEvent and managed explicitly internally. As a result, users can now publish and listen for arbitrary objects. If an annotated method has a return value, an non null result is actually published as a new event, something like: @EventListener public FooEvent handle(BarEvent event) { ... } Events can be handled in an aynchronous manner by adding `@Async` to the event method declaration and enabling such infrastructure. Events can also be ordered by adding an `@order` annotation to the event method. Issue: SPR-11622
-
由 Stephane Nicoll 提交于
Update the event publishing infrastructure to support generics-based events, that is support ApplicationListener implementations that define a generic event, something like: public class MyListener implements ApplicationListener<GenericEvent<String>> { ... } This listener should only receive events that are matching the generic signature, for instance: public class StringEvent extends GenericEvent<String> { ... } Note that because of type erasure, publishing an event that defines the generic type at the instance level will not work. In other words, publishing "new GenericEvent<String>" will not work as expected as type erasure will define it as GenericEvent<?>. To support this feature, use the new GenericApplicationListener that supersedes SmartApplicationListener to handle generics-based even types via `supportsEventType` that takes a ResolvableType instance instead of the simple Class of the event. ApplicationEventMulticaster has an additional method to multicast an event based on the event and its ResolvableType. Issue: SPR-8201
-
- 31 1月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-
- 18 12月, 2008 1 次提交
-
-
由 Chris Beams 提交于
Whitespace polishing: leading spaces->tabs; updated eclipse configuration to default to leading tabs for all bundles
-
- 23 10月, 2008 1 次提交
-
-
由 Arjen Poutsma 提交于
-