Methods for statistics are removed in recent version of Spring.
How could we replace the method getTimeSinceLastSend() for DirectChannel ?
Thx.
An internal statistics has been removed in favor Micrometer meters. See respective documentation how to deal with that info from Micrometer API: https://micrometer.io/docs/concepts
Related
Update
this issue is now assigned to CVE-2022-22965. Other than below nice answers, please do check Spring Framework RCE: Early Announcement as it is the most reliable and up-to-date site for this issue.
According to different source, seems we got a serious security issue when using Spring Core library.
https://securityboulevard.com/2022/03/new-spring4shell-zero-day-vulnerability-confirmed-what-it-is-and-how-to-be-prepared/
Quoting from above link, we are in risk if:
You use a Spring app (up to and including version 5.3.17)
Your app runs on Java 9+
You use form binding with name=value pairs – not using Spring’s more popular message conversion of JSON/XML
You don’t use an allowlist –OR– you don’t have a denylist that blocks fields like “class”, “module”, “classLoader”
The link suggested to some solution but doesn't seems easy to implement/reliable.
What should we do to fix this issue, in easiest and most reliable way?
According to the Spring Framework RCE: Early Announcement, upgrading to Spring Framework 5.3.18 or 5.2.20 will fix the RCE.
If you use Spring Boot, Spring Boot 2.5.12 and Spring Boot 2.6.6 fixes the vulnerability.
If you're unable to update:
You can choose to only upgrade Tomcat. The Apache Tomcat team has released versions 10.0.20, 9.0.62, and 8.5.78 all of which close the attack vector on Tomcat’s side.
If you can't do any of the above, the RCE announcement blog post suggests a workaround: Set disallowedFields on WebDataBinder through an #ControllerAdvice:
#ControllerAdvice
#Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {
#InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}
This quick fix will not work if a controller sets disallowedFields locally through its own #InitBinder method, which overrides the global setting. Also, more generally, the workaround will not have an effect if you use alternate REST frameworks such as Jersey (however, it has not yet been demonstrated that such configurations are impacted).
Note: Spring upgrade is needed later on as vulnerability is not in Tomcat
Temporary Workaround is Upgrade tomcat to 10.0.20, 9.0.62, and 8.5.78
Spring Reference
I am working on component that is based on spring framework. We have not yet moved to spring boot.
My requirement is to capture metrics(JVM/http/disk space) for my component which runs on an application server.
I came across micrometer library which can be utilized to capture such metrics and it can be integrated very well with Promotheus.
What I did was that I added the below dependency
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>1.7.5</version>
</dependency>
After adding the dependency I exposed a rest end point and added some simple logic to pull the metrics. Doing that I was able to fetch some basic JVM metrics. I referred the below link for this which explains how to capture metrics.
(https://micrometer.io/docs/ref/jvm)
However in addition to JVM metrics I also want to capture http request metrics(eg. the no of requests, time taken on the http calls to the rest services).
In my application there are quite many rest endpoints. Is there any way to do that. I was not able find any good documentation on that.
Any help would be highly appreciated.
Thanks
Sachin
As you said, Spring Boot does this out of the box so if you can move there, you don't need to do anything.
In order to instrument your web endpoints you can do a few things:
You can create a Filter and instrument all of your calls there.
This is what Spring Boot does, you can take a look/copy WebMvcMetricsFilter
You can add #Timer for your controllers and set-up TimedAspect
You can manually instrument your controllers see the docs
After following the above suggestions I was actually able to see my http metrics
I Simply created a configuration class annotated with #EnableAspectJAutoProxy and defined a bean inside the class as below
#Bean
public TimedAspect timedAspect() {
return new TimedAspect(registry);
}
And then added the #Timed annotation on my REST api POST methods and then I was able to see the statistics in Prometheus dashboard.
This really works!
I'm tasked with the requirement of using Spring Cloud Stream (with Kafka bindings). Going through Spring Cloud Stream's Quick Start and judging from the Config file it uses, LogSinkConfiguration, it seems the recommendation here is to use Spring Integration patterns, e.g. #ServiceActivator(inputChannel = Sink.INPUT) to connect to the input channel. However all the tutorials I've found are using a different set of annotations from the Spring Cloud Stream library (vs Spring Integration), i.e. #StreamListener(Processor.INPUT) in this walk-through.
So which is better/newer/preferred (i.e. what's the "best practice"). Should I use the S.I. way of configuring the sink using #ServiceActivator(inputChannel = Sink.INPUT) or the alternative #StreamListener(Processor.INPUT). Are these two methods of hooking up the sink virtually the same, or are there advantages to using one over the other?
With 2.0 we introduced spring-cloud-function support and with the imminent release of 3.0 we are now fully committed to functional support over any annotation driven (Spring Integration included).
So, to answer your question, functional support is the preferred way. Here is the link to more info and feel free to follow up with more concrete questions.
I have a Spring Data GemFire Region that's configured using annotations below:
#TimeToLiveExpiration(timeout = "100", action = "INVALIDATE")
#PartitionRegion(name = "blockedIPCache")
class BlockedIpEntityType { ... }
My application is a Spring Boot application and I used the following annotations to configure SDG:
#PeerCacheApplication
#EnableGemfireCaching
#EnableCachingDefinedRegions(clientRegionShortcut = ClientRegionShortcut.LOCAL, serverRegionShortcut = RegionShortcut.LOCAL)
#EnableStatistics
#EnableExpiration
#EnableEntityDefinedRegions(basePackageClasses = {...})
#EnableGemfireRepositories(basePackages = {...})
class GemFireConfiguration { ... }
All I want is to insert an object using a Spring Data GemFire Repository and after awhile the entry will be invalidated.
But, I face this Exception when I start my application...
Caused by: java.lang.IllegalStateException: Cannot set idle timeout when statistics are disabled.
at org.apache.geode.internal.cache.AbstractRegion.setCustomEntryIdleTimeout(AbstractRegion.java:1157) ~[geode-core-9.1.1.jar:?]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$ExpirationPolicyMetaData.configure(ExpirationConfiguration.java:511) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$1.postProcessAfterInitialization(ExpirationConfiguration.java:160) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
...
This happens exactly when Spring tries to autowire my Repository related to the Region configured above.
So what I'm doing wrong? And, is there a way to enable Region statistics using Java configuration or Annotations?
Note: Using Spring Data GemFire 2.0.6, Spring 5.0.5, Spring Boot 2.0.1 used in the project.
It turns out, you did not do anything wrong. Unfortunately, you stumbled across a bug(!), for which I have already filed SGF-747 and fixed. I am sorry for the inconvenience this issue may have caused you.
We are planning a Spring Data Lovelace M3 (Milestone 3) release tomorrow (Thursday, 5/17, CET). The release schedule is visible from Spring Release Calendar. All dates are tentative.
As such, you could try the new Spring Data for Pivotal GemFire (SDG) Lovelace bits (i.e. 2.1.0.M3) with the fix. SDG 2.1.0. should work just fine with Spring Boot 2.0.1/2.RELEASE and Spring 5.0.5/6.RELEASE.
However, if you are expecting to get GA bits for SDG containing this fix, then you will have to wait for the next Spring Data Kay Service Release (Kay SR8), or the Spring Data for Pivotal GemFire 2.0.8 Service Release. I am backing porting this fix.
Unfortunately, there is not another Spring Data Kay Service Release (i.e. Kay SR8) planned until probably around July 2nd or 3rd, right after Spring Framework 5.0.7 is released on Monday, July 2nd and just before Spring Boot 2.0.3 is released on Wednesday, July 4th, which is usually when we plan Spring Data Service Releases. Also, know that Spring Boot 2.0.x is based on Spring Data Kay, but should work just fine with SD Lovelace too, as I mentioned previously.
In the meantime, I will try to think of workaround where the convenience of the Annotations (e.g. #EnableEntityDefinedRegions) can still be used. I will post the workaround in SGF-747.
I see that you specified the clientRegionShortcut attribute in the #EnableCachingDefinedRegions annotation but have declared your application to be a #PeerCacheApplication. While there is no harm in doing so, the clientRegionShortcut attribute is useless in this case. Likewise, the serverRegionShortcut attribute would have no meaning if you are application were a #ClientCacheApplication instead; something to keep in mind.
Lastly, I wanted to let you know that the SDG #EnableStatistics annotation does not have the effect you probably think it does.
Specifically, SDG's #EnableStatistics annotation is concerned with enabling Pivotal GemFire's statistics "sampling" as explained here, which is configured by doing this, as also explained in the SDG #EnableStatistics annotation Javadoc, as well as referenced in the SDG Reference Guide.
The "statistics enabling" that ultimately needs to happen is by setting the Region's staticsEnabled attribute property when configuring and creating the Region (e.g. "blockedIPCache").
That is exactly what the #EnableExpiration annotation will indirectly guarantee now, with the fix in SGF-747, without the need to #EnableStatistics.
Anyway, I hope this all makes sense and helps.
Regards,
John
Where is this class "HttpContext" exist in glassfish jersey 2.9 . I was using jersey 1.17.1 to use HttpContext where it was exist in package com.sun.jersey.api.core.HttpContext.
But i did't find it in jersey 2.9.
The direct replacement for HttpContext is not available in Jersey 2.x versions and unfortunately, this breaking change detail hasn't been mentioned anywhere in the migration guide. Instead of searching for direct replacement, if we dig deeper into the interface HttpContext, based on the following method summary refer
we can infer that instead of using HttpContext, we can simply use the following out-of-the-box alternatives.
Instead of HttpContext#getRequest use #Context ContainerRequestContext crc
Instead of HttpContext#getResponse use #Context ContainerResponseContext crc
Instead of HttpContext#getUriInfo use #Context UriInfo uriInfo
Instead of HttpContext#getProperties use ContainerRequestContext#getProperty
Jersey 2.x had a lot of breaking changes, which partly caused by the fact that JAX-RS standard incorporated a lot of things in Jersey 1.x.
To quote https://jersey.java.net/documentation/latest/migration.html#mig-1.x
This chapter is a migration guide for people switching from Jersey 1.x. Since many of the Jersey 1.x features became part of JAX-RS 2.0 standard which caused changes in the package names, we decided it is a good time to do a more significant incompatible refactoring, which will allow us to introduce some more interesting new features in the future. As the result, there are many incompatibilities between Jersey 1.x and Jersey 2.0. This chapter summarizes how to migrate the concepts found in Jersey 1.x to Jersey/JAX-RS 2.0 concepts.
The migration chapter does not indicate what happened to HttpContext, but it no longer exists in its old form.