- 13 May, 2015 16 commits
-
-
Dave Syer authored
-
Dave Syer authored
Also fix bug in includes/excludes
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
-
Dave Syer authored
Different physical sources for the same logical metric just need to publish them with a period-separated prefix, and this reader will aggregate (by truncating the metric names, dropping the prefix). Very useful (for instance) if multiple application instances are feeding to a central (e.g. redis) repository and you want to display the results. Useful in conjunction with a MetricReaderPublicMetrics for hooking up to the /metrics endpoint.
-
Dave Syer authored
User can add a @Bean of type JmxMetricWriter and get all values automatically exported in a form that is usable in jconsole or jvisualvm.
-
Dave Syer authored
Also rename Codahale* to Dropwizard* and move them to a new package
-
Dave Syer authored
This seems pretty efficient (approx 12M write/s as opposed to 2M with the DefaultCounterService). N.B. there is no need to change most of the rest of the metrics stuff because metrics are write-often, read- seldom, so we don't need high performance reads as much. The Spring Integration configuration and Dropwizard support has changed a bit. Functionally very similar and probably opaque to users, but now the messaging operates as an Exporter on a @Scheduled method, and Dropwizard is a replacement [Gauge,Counter]Service. Metrics are all collected live in-memory (and can be very fast with Java 8), buffered there and shipped out to a MessageChannel (if one exists with id "metricsChannel") in a background thread. We can still use Java 8 library APIs (like LongAdder) but to compile to java 7 compatible byte code we have to forgo the use of lambdas :-( and shorthand generics (<>). Fixes gh-2682, fixes gh-2513 (for Java 8 and Dropwizard users).
-
Stephane Nicoll authored
Expose the underlying cache infrastructure bean if Boot auto-configures it. This is the case for ehCache, hazelcast and JCache. This change has two side effects: 1. It is now possible to customize the underlying cache infrastructure and let Boot only wrap it in the Spring's CacheManager abstraction. No customizations are applied if the caching-specific service is customized 2. Such infrastructure is disposed when the application terminates as it is now defined as `@Bean` and both `close()` and `shutdown()` methods are invoked if present on the target type. While the latter can be troublesome, we feel that a particular cache instance is not meant to be shared and must be disposed when the application terminates. Closes gh-2848
-
Stephane Nicoll authored
Rework 155c60b7 to structure the code consistently, in particular with a more natural order of attributes. Update test to use non-default values to ensure that the customization has been applied. See gh-2793
-
Eddú Meléndez authored
Update the CLI init command to expose additional attributes supported by Spring Initializr. These are: groupId, artifactId, version, name, description and language. Closes gh-2793 and gh-2907
-
Andy Wilkinson authored
Document new configuration properties and remove redundant code
-
- 12 May, 2015 3 commits
-
-
Andy Wilkinson authored
This commit adds support for configuring the JSP servlet’s init parameters via the environment using server.jsp-servlet.init-parameters.*. As part of this change the configuration of registerJspServlet and jspServletClassName have been moved onto a new type, JspServlet, and the existing setters on ConfigurableEmbeddedServletContainer have been deprecated. In addition to providing a model for configuring the JSP servlet that’s consistent with the model for other configuration (SSL, for example), this change also means that the class name and whether or not the servlet is registered at all can now also be configured via the environment. Closes gh-2825
-
Andy Wilkinson authored
-
Dave Syer authored
Some of the features of the launch.script were not exposed for users to be able to control at runtime. It now accepts things like PID_FOLDER and LOG_FOLDER as environment variables, and also adopts a clear naming convention where only the inputs are UPPER_CASE.
-
- 11 May, 2015 14 commits
-
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Previously, CommonsLoggingLiquibaseLogger referred to its configured level and the underlying Commons Logging log when determining if logging was enabled for a particular level. This did not work as intended as setLogLevel was never called leaving the configured level stuck at its default value of INFO. As a result of this any logging at levels below INFO would not be output, irrespective of the configuration of the underlying logging framework. This commit updates CommonsLoggingLiquibaseLogger to rely purely on the Commons Logging log when determining whether or not logging for a particular level is enabled. This brings the implementation into line with liquibase-slf4j [1] which provides similar functionality, albeit using SLF4J rather than Commons Logging Closes gh-2916 [1] https://github.com/mattbertolini/liquibase-slf4j/blob/master/src/main/java/liquibase/ext/logging/slf4j/Slf4jLogger.java
-
Andy Wilkinson authored
Closes gh-2935
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Previously, when SpringApplicationContextLoader created a SpringApplication and used it to load the test’s application context, it relied upon SpringApplication correctly deducing the application’s main class. This would result in the wrong class being deduced as the application’s main method is not called so the test runner’s main method would be found instead. This commit updates SpringApplicationContextLoader to explicitly set SpringApplication’s main class to be the current test’s class. While not strictly the application’s main class, it is the next best thing available in this situation and prevents misleading log messages and application versions from being logged. Fixes gh-2930
-
Andy Wilkinson authored
-
Andy Wilkinson authored
When a Java 8 JVM is launched with -XX:MaxPermSize a warning message is output indicating that the option will be ignored. This causes the CLI tests that assert that no error output has been produced to fail. This commit updates the CLI's integration test harness to remove JAVA_OPTS from the environment of the CLI process. This prevents any unwanted max perm size configuration from leaking into that environment and breaking the build.
-
Andy Wilkinson authored
-
Andy Wilkinson authored
When a Java 8 JMV is launched with -XX:MaxPermSize a warning message is output indicating that the option will be ignored. This causes the CLI tests that assert that no error output has been produced to fail. This commit updates the CLI's integration test harness to remove JAVA_OPTS from the environment of the CLI process. This prevents any unwanted max perm size configuration from leaking into that environment and breaking the build.
-
Mario A. Alvarez Garcia authored
Closes gh-2928
-
Davide Angelocola authored
Closes gh-2931
-
Andy Wilkinson authored
Closes gh-2932
-
Andy Wilkinson authored
Closes gh-2754
-
Andy Wilkinson authored
Spring Framework 4.2 introduces improved support for CORS. Notably this means that a DispatcherServlet will now process an OPTIONS request if it contains an Origin header, without having to enable OPTIONS request dispatching for every endpoint. This commit takes advantage of these changes in Spring Framework 4.2 by configuring the controller that wraps Jolokia’s AgentServlet to handle OPTIONS requests. This allows Jolokia’s CORS support to be configured using Jolokia’s standard configuration, as described in section 4.1.5 of the Jolokia documentation [1]. Closes gh-1987 [1] https://jolokia.org/reference/html/security.html
-
- 07 May, 2015 2 commits
-
-
Andy Wilkinson authored
For reasons that I don’t understand, Maven has decided to stop running the javadoc:jar task as part of the package phase. It appears to be related to the addition of the build-helper plugin in spring-boot-dependencies. Binding javadoc:jar to the prepare-package phase convinces Maven to run it, apparently without any unwanted side effects.
-
Andy Wilkinson authored
Previously, the CLI’s dependency management used proprietary Properties file-based metadata to configure its dependency management. Since spring-boot-gradle-plugin’s move to using the separate dependency management plugin the CLI was the only user of this format. This commit updates the CLI to use Maven boms to configure its dependency management. By default it uses the spring-boot-dependencies bom. This configuration can be augmented and overridden using the new @DependencyManagementBom annotation which replaces @GrabMetadata. Closes gh-2688 Closes gh-2439
-
- 06 May, 2015 5 commits
-
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Craig Walls authored
While this is a breaking change, continuing with Spring Social Facebook 1.1.x is also broken as it is no longer compatible with Facebook's API. Upgrading to 2.0.1.RELEASE may require some changes to be made to users' applications, but it will allow their applications to use the Facebook API once again. Closes gh-2837
-
Andy Wilkinson authored
-
pasali authored
Closes gh-2920
-