Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Drop Portlet MVC support

Browse Source 
This commit also removes the corresponding deprecated Servlet MVC variant and updates DispatcherServlet.properties to point to RequestMappingHandlerMapping/Adapter by default.

Issue: SPR-14129
This commit is contained in:
Juergen Hoeller
2016-07-04 23:33:45 +02:00
parent ae0b7c26c5
commit 2b3445df81
235 changed files with 94 additions and 39747 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
src/asciidoc/core-beans.adoc
View File

@@ -2274,7 +2274,7 @@ the __scope__ of the objects created from a particular bean definition. This app
powerful and flexible in that you can __choose__ the scope of the objects you create
through configuration instead of having to bake in the scope of an object at the Java
class level. Beans can be defined to be deployed in one of a number of scopes: out of
the box, the Spring Framework supports seven scopes, five of which are available only if
the box, the Spring Framework supports six scopes, five of which are available only if
you use a web-aware `ApplicationContext`.
The following scopes are supported out of the box. You can also create
@@ -2301,11 +2301,6 @@ The following scopes are supported out of the box. You can also create
| Scopes a single bean definition to the lifecycle of an HTTP `Session`. Only valid in
the context of a web-aware Spring `ApplicationContext`.
| <<beans-factory-scopes-global-session,globalSession>>
| Scopes a single bean definition to the lifecycle of a global HTTP `Session`. Typically
only valid when used in a Portlet context. Only valid in the context of a web-aware
Spring `ApplicationContext`.
| <<beans-factory-scopes-application,application>>
| Scopes a single bean definition to the lifecycle of a `ServletContext`. Only valid in
the context of a web-aware Spring `ApplicationContext`.
@@ -2422,29 +2417,28 @@ runtime more than once, see <<beans-factory-method-injection>>
[[beans-factory-scopes-other]]
=== Request, session, global session, application, and WebSocket scopes
=== Request, session, application, and WebSocket scopes
The `request`, `session`, `globalSession`, `application`, and `websocket` scopes are
__only__ available if you use a web-aware Spring `ApplicationContext` implementation
(such as `XmlWebApplicationContext`). If you use these scopes with regular Spring IoC
containers such as the `ClassPathXmlApplicationContext`, an `IllegalStateException` will
be thrown complaining about an unknown bean scope.
The `request`, `session`, `application`, and `websocket` scopes are __only__ available
if you use a web-aware Spring `ApplicationContext` implementation (such as
`XmlWebApplicationContext`). If you use these scopes with regular Spring IoC containers
such as the `ClassPathXmlApplicationContext`, an `IllegalStateException` will be thrown
complaining about an unknown bean scope.
[[beans-factory-scopes-other-web-configuration]]
==== Initial web configuration
To support the scoping of beans at the `request`, `session`, `globalSession`,
`application`, and `websocket` levels (web-scoped beans), some minor initial
configuration is required before you define your beans. (This initial setup is __not__
required for the standard scopes, `singleton` and `prototype`.)
To support the scoping of beans at the `request`, `session`, `application`, and
`websocket` levels (web-scoped beans), some minor initial configuration is
required before you define your beans. (This initial setup is __not__ required
for the standard scopes, `singleton` and `prototype`.)
How you accomplish this initial setup depends on your particular Servlet environment.
If you access scoped beans within Spring Web MVC, in effect, within a request that is
processed by the Spring `DispatcherServlet` or `DispatcherPortlet`, then no special
setup is necessary: `DispatcherServlet` and `DispatcherPortlet` already expose all
relevant state.
processed by the Spring `DispatcherServlet`, then no special setup is necessary:
`DispatcherServlet` already exposes all relevant state.
If you use a Servlet 2.5 web container, with requests processed outside of Spring's
`DispatcherServlet` (for example, when using JSF or Struts), you need to register the
@@ -2562,29 +2556,6 @@ can be used to assign a component to the `session` scope.
----
[[beans-factory-scopes-global-session]]
==== Global session scope
Consider the following bean definition:
[source,xml,indent=0]
[subs="verbatim,quotes"]
----
<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>
----
The `globalSession` scope is similar to the standard HTTP `Session` scope
(<<beans-factory-scopes-session,described above>>), and applies only in the context of
portlet-based web applications. The portlet specification defines the notion of a global
`Session` that is shared among all portlets that make up a single portlet web
application. Beans defined at the `globalSession` scope are scoped (or bound) to the
lifetime of the global portlet `Session`.
If you write a standard Servlet-based web application and you define one or more beans
as having `globalSession` scope, the standard HTTP `Session` scope is used, and no
error is raised.
[[beans-factory-scopes-application]]
==== Application scope
@@ -2681,11 +2652,11 @@ understand the "why" as well as the "how" behind it.
To create such a proxy, you insert a child `<aop:scoped-proxy/>` element into a scoped
bean definition (see <<beans-factory-scopes-other-injection-proxies>> and
<<xsd-configuration>>). Why do definitions of beans scoped at the `request`, `session`,
`globalSession` and custom-scope levels require the `<aop:scoped-proxy/>` element?
Let's examine the following singleton bean definition and contrast it with what you need
to define for the aforementioned scopes (note that the following `userPreferences` bean
definition as it stands is __incomplete__).
<<xsd-configuration>>). Why do definitions of beans scoped at the `request`, `session`
and custom-scope levels require the `<aop:scoped-proxy/>` element? Let's examine the
following singleton bean definition and contrast it with what you need to define for
the aforementioned scopes (note that the following `userPreferences` bean definition
as it stands is __incomplete__).
[source,xml,indent=0]
[subs="verbatim,quotes"]
@@ -2721,7 +2692,7 @@ actually is invoking a method on the proxy. The proxy then fetches the real
method invocation onto the retrieved real `UserPreferences` object.
Thus you need the following, correct and complete, configuration when injecting
`request-`, `session-`, and `globalSession-scoped` beans into collaborating objects:
`request-` and `session-scoped` beans into collaborating objects:
[source,xml,indent=0]
[subs="verbatim,quotes"]
@@ -3501,16 +3472,6 @@ dependency type:
| Spring JMX notification publisher
| <<jmx-notifications>>
| `PortletConfigAware`
| Current `PortletConfig` the container runs in. Valid only in a web-aware Spring
`ApplicationContext`
| <<portlet>>
| `PortletContextAware`
| Current `PortletContext` the container runs in. Valid only in a web-aware Spring
`ApplicationContext`
| <<portlet>>
| `ResourceLoaderAware`
| Configured loader for low-level access to resources
| <<resources>>
@@ -7600,9 +7561,7 @@ is configured with two PropertySource objects -- one representing the set of JVM
These default property sources are present for `StandardEnvironment`, for use in standalone
applications. {api-spring-framework}/web/context/support/StandardServletEnvironment.html[`StandardServletEnvironment`]
is populated with additional default property sources including servlet config and servlet
context parameters. {api-spring-framework}/web/portlet/context/StandardPortletEnvironment.html[`StandardPortletEnvironment`]
similarly has access to portlet config and portlet context parameters as property sources.
Both can optionally enable a {api-spring-framework}/jndi/JndiPropertySource.html[`JndiPropertySource`].
context parameters. It can optionally enable a {api-spring-framework}/jndi/JndiPropertySource.html[`JndiPropertySource`].
See the javadocs for details.
====

1521
src/asciidoc/web-portlet.adoc
View File

File diff suppressed because it is too large Load Diff

5
src/asciidoc/web.adoc
View File

@@ -11,15 +11,12 @@ Spring Framework's own web framework, <<mvc,Spring Web MVC>>, is covered in the
first couple of chapters. Subsequent chapters are concerned with Spring Framework's
integration with other web technologies, such as <<jsf,JSF>>.
Following that is coverage of Spring Framework's MVC <<portlet,portlet framework>>.
The section then concludes with comprehensive coverage of the Spring Framework
<<websocket>> (including <<websocket-stomp>>).
* <<mvc>>
* <<view>>
* <<web-integration>>
* <<portlet>>
* <<websocket>>
--
@@ -29,8 +26,6 @@ include::web-view.adoc[leveloffset=+1]
include::web-integration.adoc[leveloffset=+1]
include::web-portlet.adoc[leveloffset=+1]
include::web-websocket.adoc[leveloffset=+1]
include::web-cors.adoc[leveloffset=+1]

44
src/test/java/org/springframework/core/env/EnvironmentSystemIntegrationTests.java vendored
View File

@@ -1,5 +1,5 @@
/*
* Copyright 2002-2015 the original author or authors.
* Copyright 2002-2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -16,7 +16,6 @@
package org.springframework.core.env;
import java.io.File;
import java.io.IOException;
@@ -57,10 +56,6 @@ import org.springframework.web.context.support.GenericWebApplicationContext;
import org.springframework.web.context.support.StandardServletEnvironment;
import org.springframework.web.context.support.StaticWebApplicationContext;
import org.springframework.web.context.support.XmlWebApplicationContext;
import org.springframework.web.portlet.context.AbstractRefreshablePortletApplicationContext;
import org.springframework.web.portlet.context.StandardPortletEnvironment;
import org.springframework.web.portlet.context.StaticPortletApplicationContext;
import org.springframework.web.portlet.context.XmlPortletApplicationContext;
import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;
@@ -518,36 +513,6 @@ public class EnvironmentSystemIntegrationTests {
assertEnvironmentAwareInvoked(ctx, prodEnv);
}
@Test
public void staticPortletApplicationContext() {
StaticPortletApplicationContext ctx = new StaticPortletApplicationContext();
assertHasStandardPortletEnvironment(ctx);
registerEnvironmentBeanDefinition(ctx);
ctx.setEnvironment(prodEnv);
ctx.refresh();
assertHasEnvironment(ctx, prodEnv);
assertEnvironmentBeanRegistered(ctx);
assertEnvironmentAwareInvoked(ctx, prodEnv);
}
@Test
public void xmlPortletApplicationContext() {
AbstractRefreshablePortletApplicationContext ctx = new XmlPortletApplicationContext();
ctx.setEnvironment(prodEnv);
ctx.setConfigLocation("classpath:" + XML_PATH);
ctx.refresh();
assertHasEnvironment(ctx, prodEnv);
assertEnvironmentBeanRegistered(ctx);
assertEnvironmentAwareInvoked(ctx, prodEnv);
assertThat(ctx.containsBean(DEV_BEAN_NAME), is(false));
assertThat(ctx.containsBean(PROD_BEAN_NAME), is(true));
}
@Test
public void abstractApplicationContextValidatesRequiredPropertiesOnRefresh() {
{
@@ -605,13 +570,6 @@ public class EnvironmentSystemIntegrationTests {
assertThat(defaultEnv, instanceOf(StandardServletEnvironment.class));
}
private void assertHasStandardPortletEnvironment(WebApplicationContext ctx) {
// ensure a default portlet environment exists
Environment defaultEnv = ctx.getEnvironment();
assertThat(defaultEnv, notNullValue());
assertThat(defaultEnv, instanceOf(StandardPortletEnvironment.class));
}
private void assertHasEnvironment(ApplicationContext ctx, Environment expectedEnv) {
// ensure the custom environment took
Environment actualEnv = ctx.getEnvironment();