- 10 12月, 2010 1 次提交
-
-
由 Thomas Risberg 提交于
-
- 08 12月, 2010 4 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
AbstractEnvironment delegates to an underlying ConfigurationService when processing methods such as getProperty(String name, Class<?> targetType) Accessor methods have been added to the ConfigurableEnvironment interface that allow this service to be updated or replaced.
-
由 Chris Beams 提交于
There is no longer a reserved default profile named 'default'. Rather, users must explicitly specify a default profile or profiles via ConfigurableEnvironment.setDefaultProfiles(String...) - or - spring.profile.default="pD1,pD2" Per above, the setDefaultProfile(String) method now accepts a variable number of profile names (one or more). This is symmetrical with the existing setActiveProfiles(String...) method. A typical scenario might involve setting both a default profile as a servlet context property in web.xml and then setting an active profile when deploying to production.
-
由 Chris Beams 提交于
-
- 07 12月, 2010 1 次提交
-
-
由 Chris Beams 提交于
Provides a richer set of Matcher implementations than JUnit's hamcrest package.
-
- 06 12月, 2010 1 次提交
-
-
由 Chris Beams 提交于
Before this change, the following properties could be used to manipulate Spring profile behavior: -DspringProfiles=p1,p2 -DdefaultSpringProfile=pD These properties have been renamed to follow usual Java conventions for property naming: -Dspring.profile.active=p1,p2 -Dspring.profile.default=pD
-
- 01 12月, 2010 3 次提交
-
-
由 Chris Beams 提交于
'default' is now a reserved profile name, indicating that any beans defined within that profile will be registered unless another profile or profiles have been activated. Examples below are expressed in XML, but apply equally when using the @Profile annotation. EXAMPLE 1: <beans> <beans profile="default"> <bean id="foo" class="com.acme.EmbeddedFooImpl"/> </beans> <beans profile="production"> <bean id="foo" class="com.acme.ProdFooImpl"/> </beans> </beans> In the case above, the EmbeddedFooImpl 'foo' bean will be registered if: a) no profile is active b) the 'default' profile has explicitly been made active The ProdFooImpl 'foo' bean will be registered if the 'production' profile is active. EXAMPLE 2: <beans profile="default,xyz"> <bean id="foo" class="java.lang.String"/> </beans> Bean 'foo' will be registered if any of the following are true: a) no profile is active b) 'xyz' profile is active c) 'default' profile has explicitly been made active d) both (b) and (c) are true Note that the default profile is not to be confused with specifying no profile at all. When the default profile is specified, beans are registered only if no other profiles are active; whereas when no profile is specified, bean definitions are always registered regardless of which profiles are active. The default profile may be configured programmatically: environmnent.setDefaultProfile("embedded"); or declaratively through any registered PropertySource, e.g. system properties: -DdefaultSpringProfile=embedded Assuming either of the above, example 1 could be rewritten as follows: <beans> <beans profile="embedded"> <bean id="foo" class="com.acme.EmbeddedFooImpl"/> </beans> <beans profile="production"> <bean id="foo" class="com.acme.ProdFooImpl"/> </beans> </beans> It is unlikely that use of the default profile will make sense in conjunction with a statically specified 'springProfiles' property. For example, if 'springProfiles' is specified as a web.xml context param, that profile will always be active for that application, negating the possibility of default profile bean definitions ever being registered. The default profile is most useful for ensuring that a valid set of bean definitions will always be registered without forcing users to explictly specify active profiles. In the embedded vs. production examples above, it is assumed that the application JVM will be started with -DspringProfiles=production when the application is in fact in a production environment. Otherwise, the embedded/default profile bean definitions will always be registered.
-
由 Chris Beams 提交于
Earlier naming reflected initial conception of 'environment-specific bean definitions'. This notion has evolved into bean definitions specific to particular profiles, and the new naming more clearly expresses it.
-
由 Chris Beams 提交于
-
- 18 11月, 2010 1 次提交
-
-
由 David Syer 提交于
-
- 17 11月, 2010 1 次提交
-
-
由 David Syer 提交于
-
- 16 11月, 2010 5 次提交
-
-
由 Chris Beams 提交于
Add .expression as a build path dependency to satisfy imports in Spr7538Tests.java
-
由 David Syer 提交于
-
由 David Syer 提交于
-
由 David Syer 提交于
-
由 David Syer 提交于
-
- 09 11月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 08 11月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 01 11月, 2010 1 次提交
-
-
由 Costin Leau 提交于
- minor performance improvements to servlet and portlet handlers
-
- 30 10月, 2010 3 次提交
-
-
由 Costin Leau 提交于
+ add updated IDE classpath + add updated OSGi manifest
-
由 Costin Leau 提交于
+ add updated IDE classpath + add updated OSGi manifest
-
由 Costin Leau 提交于
+ initial commit of caching abstraction + main API + Spring AOP and AspectJ support + annotation driven, declarative support + initial namespace draft
-
- 29 10月, 2010 5 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
由 Costin Leau 提交于
+ add missing test class
-
由 Costin Leau 提交于
+ add test for XML config with errors
-
由 Costin Leau 提交于
+ add c: namespace
-
- 26 10月, 2010 2 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
Branch in question is 'env' branch from git://git.springsource.org/sandbox/cbeams.git; merged into git-svn repository with: git merge -s recursive -Xtheirs --no-commit env No merge conflicts, but did need to git rm spring-build prior to committing. With this change, Spring 3.1.0 development is now happening on SVN trunk. Further commits to the 3.0.x line will happen in an as-yet uncreated SVN branch. 3.1.0 snapshots will be available per the usual nightly CI build from trunk.
-
- 21 10月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 20 10月, 2010 6 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 18 10月, 2010 1 次提交
-
-
由 Ramnivas Laddad 提交于
Fixed configuration of AnnotationAsyncExecutionAspect (was incorrectly under the same name as that for transaction management aspect)
-
- 16 10月, 2010 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-