Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
爱吃血肠
spring-framework
提交
c2bd229d
S
spring-framework
项目概览
爱吃血肠
/
spring-framework
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
S
spring-framework
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
c2bd229d
编写于
2月 15, 2019
作者:
J
Juergen Hoeller
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Clarify role of 'aware' callback interfaces
上级
ac0e5d8e
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
41 addition
and
43 deletion
+41
-43
src/docs/asciidoc/core/core-beans.adoc
src/docs/asciidoc/core/core-beans.adoc
+22
-24
src/docs/asciidoc/core/core-resources.adoc
src/docs/asciidoc/core/core-resources.adoc
+19
-19
未找到文件。
src/docs/asciidoc/core/core-beans.adoc
浏览文件 @
c2bd229d
...
...
@@ -3746,16 +3746,16 @@ Thus, beans can programmatically manipulate the `ApplicationContext` that create
through the `ApplicationContext` interface or by casting the reference to a known
subclass of this interface (such as `ConfigurableApplicationContext`, which exposes
additional functionality). One use would be the programmatic retrieval of other beans.
Sometimes this capability is useful. However, in general, you should avoid it, because
it
couples the code to Spring and does not follow the Inversion of Control style, where
collaborators are provided to beans as properties. Other methods of the
`ApplicationContext` provide access to file resources, publishing application events,
and
accessing a `MessageSource`. These additional features are described in
Sometimes this capability is useful. However, in general, you should avoid it, because
it couples the code to Spring and does not follow the Inversion of Control style,
where
collaborators are provided to beans as properties. Other methods of the
`ApplicationContext` provide access to file resources, publishing application events,
a
nd a
ccessing a `MessageSource`. These additional features are described in
<<context-introduction>>.
As of Spring 2.5, autowiring is another alternative to obtain a reference to the
`ApplicationContext`. The "`traditional`" `constructor` and `byType` autowiring modes
(as
described in <<beans-factory-autowire>>) can provide a dependency of type
`ApplicationContext`. The "`traditional`" `constructor` and `byType` autowiring modes
(as
described in <<beans-factory-autowire>>) can provide a dependency of type
`ApplicationContext` for a constructor argument or a setter method parameter,
respectively. For more flexibility, including the ability to autowire fields and
multiple parameter methods, use the new annotation-based autowiring features. If you do,
...
...
@@ -3789,11 +3789,10 @@ init-method.
[[aware-list]]
=== Other `Aware` Interfaces
Besides `ApplicationContextAware` and `BeanNameAware` (discussed
<<beans-factory-aware,earlier>>), Spring offers a range of `Aware` interfaces that let
beans indicate to the container that they require a certain infrastructure dependency. As
a general rule, the name is a good indication of the dependency type. The following table
summarizes the most important `Aware` interfaces:
Besides `ApplicationContextAware` and `BeanNameAware` (discussed <<beans-factory-aware,earlier>>),
Spring offers a wide range of `Aware` callback interfaces that let beans indicate to the container
that they require a certain infrastructure dependency. As a general rule, the name indicates the
dependency type. The following table summarizes the most important `Aware` interfaces:
[[beans-factory-nature-aware-list]]
.Aware interfaces
...
...
@@ -3822,7 +3821,7 @@ summarizes the most important `Aware` interfaces:
| `BootstrapContextAware`
| Resource adapter `BootstrapContext` the container runs in. Typically available only in
JCA
aware `ApplicationContext` instances.
JCA
-
aware `ApplicationContext` instances.
| <<integration.adoc#cci, JCA CCI>>
| `LoadTimeWeaverAware`
...
...
@@ -9336,19 +9335,18 @@ specific and appropriate to the actual application context type.
You
can
configure
a
bean
deployed
into
the
application
context
to
implement
the
special
callback
interface
,
`
ResourceLoaderAware
`,
to
be
automatically
called
back
at
initialization
time
with
the
application
context
itself
passed
in
as
the
`
ResourceLoader
`.
You
can
also
expose
properties
of
type
`
Resource
`,
to
be
used
to
access
static
resources
.
They
are
injected
into
it
like
any
other
properties
.
You
can
specify
those
`
Resource
`
properties
as
simple
`
String
`
paths
and
rely
on
a
special
JavaBean
`
PropertyEditor
`
(
which
is
automatically
registered
by
the
context
)
to
convert
those
text
strings
to
actual
`
Resource
`
objects
when
the
bean
is
deployed
.
initialization
time
with
the
application
context
itself
passed
in
as
the
`
ResourceLoader
`.
You
can
also
expose
properties
of
type
`
Resource
`,
to
be
used
to
access
static
resources
.
They
are
injected
into
it
like
any
other
properties
.
You
can
specify
those
`
Resource
`
properties
as
simple
`
String
`
paths
and
rely
on
automatic
conversion
from
those
text
strings
to
actual
`
Resource
`
objects
when
the
bean
is
deployed
.
The
location
path
or
paths
supplied
to
an
`
ApplicationContext
`
constructor
are
actually
resource
strings
and
,
in
simple
form
,
are
treated
appropriately
according
to
the
specific
context
implementation
.
For
example
`
ClassPathXmlApplicationContext
`
treats
a
simple
location
path
as
a
classpath
location
.
You
can
also
use
location
paths
(
resource
strings
)
with
special
prefixes
to
force
loading
of
definitions
from
the
classpath
or
a
URL
,
regardless
of
the
actual
context
type
.
resource
strings
and
,
in
simple
form
,
are
treated
appropriately
according
to
the
specific
context
implementation
.
For
example
`
ClassPathXmlApplicationContext
`
treats
a
simple
location
path
as
a
classpath
location
.
You
can
also
use
location
paths
(
resource
strings
)
with
special
prefixes
to
force
loading
of
definitions
from
the
classpath
or
a
URL
,
regardless
of
the
actual
context
type
.
...
...
src/docs/asciidoc/core/core-resources.adoc
浏览文件 @
c2bd229d
...
...
@@ -323,9 +323,9 @@ The following table summarizes the strategy for converting `String` objects to `
[[resources-resourceloaderaware]]
== The `ResourceLoaderAware` interface
The `ResourceLoaderAware` interface is a special
marker interface that identifies object
s
that expect to be provided with a `ResourceLoader` reference. The following listing shows
the definition of the `ResourceLoaderAware` interface:
The `ResourceLoaderAware` interface is a special
callback interface which identifie
s
components that expect to be provided with a `ResourceLoader` reference. The following
listing shows
the definition of the `ResourceLoaderAware` interface:
====
[source,java,indent=0]
...
...
@@ -338,29 +338,29 @@ the definition of the `ResourceLoaderAware` interface:
----
====
When a class implements `ResourceLoaderAware` and is deployed into an application
context (as a Spring-managed bean), it is recognized as `ResourceLoaderAware` by the
application context. The application context then invokes
`setResourceLoader(ResourceLoader)`, supplying itself as the argument (remember, all
application contexts in Spring implement
the `ResourceLoader` interface).
When a class implements `ResourceLoaderAware` and is deployed into an application
context
(as a Spring-managed bean), it is recognized as `ResourceLoaderAware` by the application
context. The application context then invokes `setResourceLoader(ResourceLoader)`,
supplying itself as the argument (remember, all application contexts in Spring implement
the `ResourceLoader` interface).
Since an `ApplicationContext` is a `ResourceLoader`, the bean could also
implement the `ApplicationContextAware` interface and use the supplied application
context directly to load resources. However, in general, it is better to use the specialized
`ResourceLoader` interface if that is all you need. The code would be coupled only
to the resource loading interface (which can be considered a utility interface) and not to
the whole Spring
`ApplicationContext` interface.
Since an `ApplicationContext` is a `ResourceLoader`, the bean could also
implement the
`ApplicationContextAware` interface and use the supplied application context directly to
load resources. However, in general, it is better to use the specialized `ResourceLoader`
interface if that is all you need. The code would be coupled only to the resource loading
interface (which can be considered a utility interface) and not to the whole Spring
`ApplicationContext` interface.
As of Spring 2.5, you can rely upon autowiring of the `ResourceLoader` as an alternative
to implementing the `ResourceLoaderAware` interface. The "`traditional`" `constructor` and
`byType` autowiring modes (as described in <<beans-factory-autowire>>) are now capable
of
providing a dependency of type `ResourceLoader` for either a constructor argument or a
`byType` autowiring modes (as described in <<beans-factory-autowire>>) are now capable
of
providing a dependency of type `ResourceLoader` for either a constructor argument or a
setter method parameter, respectively. For more flexibility (including the ability to
autowire fields and multiple parameter methods), consider using the annotation-based
autowiring features. In that case, the `ResourceLoader` is autowired into a field,
constructor argument, or method parameter that expects the `ResourceLoader` type as
long as the field, constructor, or method in question carries the `@Autowired`
annotation.
For more information, see <<beans-autowired-annotation>>.
constructor argument, or method parameter that expects the `ResourceLoader` type as
long
as the field, constructor, or method in question carries the `@Autowired` annotation.
For more information, see <<beans-autowired-annotation>>.
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录