When creating a new Spring Boot project using Spring Initializr and adding Azure Support, it adds a dependency to com.microsoft.azure:azure-spring-boot-starter.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
The spring cloud documentation says:
The Azure Support entry contains auto-configuration support for Azure
managed services [...]
Now I'd like to send and receive messages from Azure Service Bus and the documentation wants me to add a dependency to azure-servicebus.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
implementation 'com.microsoft.azure:azure-servicebus'
Okay fine. When I now switch over to Microsoft and read the documentation about Service Bus there, it mentions two libraries, where Microsoft states the second one is dated and legacy.
azure-messaging-servicebus (latest) implementation 'com.azure:azure-messaging-servicebus:7.0.0'
azure-servicebus (legacy) 'com.microsoft.azure:azure-servicebus'
Question
Is the Spring Boot documentation just outdated?
I have read somewhere that libraries in com.microsoft.com are for managing the resource itself, while libraries in com.azure are for managing the data. Is this true?
What is meant by auto-configuration support?
As you can see I am very confused which dependencies I need to add. Also I don't get the difference between packages from com.azure and com.microsoft.azure.
Can someone please shed some light on this?
Related
I'm new to metrics in general and especially Micrometer, so this might be a dumb question:
Micrometer describes itself on the home page as a "facade" "without vendor lock-in", "think SLF4J, but for metrics". With "built-in support for [...] Netflix Atlas". The docs say it's included in Spring Boot 2.
So what I'd expect is the ability to configure the monitoring system on start-up - just as I would with SLF4J. So this doc describes a setting management.metrics.export.atlas.enabled (among others) for Spring Boot. But even with this setting auto-wiring a MeterRegistry registry fails as follows:
Parameter 4 of constructor in [snip] required a bean of type 'io.micrometer.core.instrument.MeterRegistry' that could not be found.
Action:
Consider defining a bean of type 'io.micrometer.core.instrument.MeterRegistry' in your configuration.
Google led me to Baeldung where I read about some micrometer-registry-atlas dependency plus providing a MeterRegistrybean of type AtlasMeterRegistry. This works, but it's not what I call a "facade without vendor lock-in", but I guess I'm just doing it wrong?
How can I provide the monitoring system during runtime, switching between Atlas and any other without re-compiling?
#crusy you are actually right, but the feature is part of the Actuator module. This is not well documented and I was lucky to find the answer in the Spring Boot Gitter channnel https://gitter.im/spring-projects/spring-boot/archives/2019/01/24?at=5c4980b00721b912a5cdc02f.
You will notice that the Metrics section in the Spring Boot documentation is under Actuator: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-metrics.
This means that in order for Micrometer to work out of the box, you need to include Actuator in your build. E.g for Gradle:
implementation ('org.springframework.boot:spring-boot-starter-actuator')
The MeterRegistry bean will be there now.
One of the definitions I found on Wikipedia says that vendor lock-in:
makes a customer dependent on a vendor for products and services,
unable to use another vendor without substantial switching costs.
Micrometer helps to unify interfaces to collect metrics (timers, gauges, counters, etc.), but there is no standard on how these metrics are shipped to backends (Atlas, Prometheus, etc.). That is the main reason why you need to define a specific library (micrometer-registry-atlas), properties, and sometimes also additional configuration.
Micrometer doesn't bring costs needed to switch to another backend to zero, but at least they are kept to minimum.
I created my project by using S/4HANA SDK (spring boot archetype), now I need the functionality to provision some ODATA services so I also introduce the dependency com.sap.cloud.servicesdk.provodatav4 to my project and then create metadata file and odata service implementation class. However, after packaging my project into jar file and run it, I get null pointer exception from the class com.sap.cloud.sdk.service.prov.v4.rt.core.web.ODataApplicationInitializer. After seeing the source code of this class, it seems it use "File" object to get metadata file from classpath, but this way doesn't work in a jar file. My question is: does it mean I have to change the packaging way to "war" in order to use this SDK for odata service development? Thanks very much.
The unfortunate answer is that, as of today, the Service SDK (not the S/4HANA Cloud SDK) is only compatible with pure Tomcat environments and assumes the Servlet standard as well as surrounding mechanisms as the default mean. The reasons for this is that the Service SDK is an integral part (the runtime) of the SAP Cloud Application Programming Model which is self-contained and may not be combined with arbitrary frameworks such as Spring Boot.
Adding to Philipp's answer that this is not supported, you may be able to use the traditional deployment here. However, since this is likely not supported officially, I would encourage to consider an alternative approach.
I have been using the Spring Framework for about 4 years now, and now Spring Boot for the last couple of months. My Spring MVC applications are usually deployed on a Java EE container such as JBoss/WildFly or WebLogic. Doing so allows me to use JNDI for things like datasources or any other sensitive data that involve secrets/passwords. That makes my app "consume" that JNDI resource based on its name.
Now with Spring Boot and especially for self-contained microservices (embedded tomcat), that information is now stored within the application (application.properties and/or in Spring Java Config classes), so versioned in Git.
That makes that information a lot more exposed to other developers, which I'm not very comfortable with. I also don't like having those details show up in SonarQube and Jenkins (through workspaces).
Question is: Are there any best practices for this specific requirement?
* UPDATE *
I see some articles here and there about the use of Jasypt, but I wonder if it's still a valid library to use since the last stable release is dated from 2014.
Thank you
You could consider using a vault. Spring supports a few of them out of the box. You can find more information here http://projects.spring.io/spring-vault/.
If you have spring cloud in your stack, then it's very easy. Use encrypt the value and put it in the application properties. Follow the instruction mentioned here.
Other way is, set the values as environmental variables and using the environmental variables in the application properties. Instructions here
I am trying to implement cache mechanism provide by Spring Data GemFire. Has anyone implemented a solution? I need to check on performance and ease to implement it.
Sonal-
First, you can find plenty of examples in the Spring User Guides, here, for example...
Accessing Data with GemFire,
Caching Data with GemFire, and ...
Accessing GemFire Data with REST
Additionally, there is a Spring GemFire Examples project here.
I have also started work on building a "Reference Implementation" (RI) for Spring Data GemFire/Geode, here. I have much work to do with this project yet, like documentation (READMEs) in the Repo, but I do plan to keep it up-to-date with my latest developments since I use the code as a basis for all my conference talks. Anyway, there is plenty of code examples and tests in this GitHub project to keep you busy for awhile.
Then, the Spring Data GemFire and Spring Data Geode GitHub projects themselves, have plenty of tests to show you how to address different application concerns (Configuration, Data Access, Function Execution, etc, etc).
Of particular interests might be the new Annotation-based configuration model for SDG^2 that I am working on. This is currently a WIP and I am also working on User Guide documentation for this feature/functionality, but it is established and even inspired by the auto-configuration features and Annotations provided by Spring and Spring Boot (e.g. #EnableXYZ).
Users have even started using the Annotation-based configuration model without significant documentation in place since it builds on concepts already available and familiar in Spring Boot. In fact combining these SDG specific Annotations with Spring Boot makes for a very powerful combination while preserving simple/easy nature to get started, 1 of my primary goals.
Given the lack of documentation yet, you can find more out in the Spring IO blog, where I first blogged about it here. Then I expanded on this article in a second blog, talking specifically about security.
And if you are really curious, you can follow the latest developments of the Annotation configuration model in my testing efforts.
Finally, of course, as I have already alluded to, as any good developer knows, getting started is as easy following the examples and reviewing Spring Data GemFire Reference Guide and Javadoc.
Don't forget to familiarize yourself with Pivotal GemFire as well! Javadoc here.
Hope this helps!
-John
Has anyone integrated Spring Dynamic Modules (or Eclipse Gemini Blueprint) with Netbeans Platform? I cannot find any information on this.
I was thinking about potential use of Spring Services within the Netbeans Platform Application. Is this reasonable?
Thanks!
I don't know anything about Spring Dynamic Modules, but as long as it produces regular Spring services and DAOs, it's totally do-able. I outlined the process in this post. I am now also considering writing up a blog post complete with code examples on this topic since this seems to be a common issue. I'll update this answer with a link as soon as I'm done.