Craig Walls

Ranch Hand
+ Follow
since Sep 19, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Craig Walls

Tim: Good examples.

In any case, the debate over singletons and concurrency issues are really more general Java questions and not Spring-specific. Not being a regular around here, I'll let everyone else decide how they want to deal with this thread (IMO, it belongs in a separate forum), but going forward I'll dismiss myself from this discussion unless the question pertains to Spring or Spring Boot.
2 years ago
In my experience, static variables are hardly ever a solution to anything. They seem tempting at times, but become painful as your application evolves. I like statics for constants, but that's about it.

I wouldn't go so far as to say that Singleton is an anti-pattern. It has its place.

And, to be clear, a Singleton bean in Spring isn't exactly the same thing as a Singleton type in Java. A Singleton bean means that Spring will create one and only one instance of the type with the given specifications...but others (including Spring) may create another instance of the same type with different specifications. This is definitely useful, because in most cases there's no need to have more than one instance of a component...and doing so would increase the classloading profile (in terms of memory used by each instance and instance-creation/garbage-collection) of the app. A singleton in Java means that there's one and only one instance ever.

The gotcha with singletons is that (as I've mentioned already in this thread) they probably should be immutable. If you keep request-specific data in a controller's instance variables, for example, then you're asking for trouble.

Of course, not all beans in a Spring container have to be singleton. The default is for Spring to create singletons, but you can specify other scopes, such as prototype (one instance per injection point), request (one instance per request), or session (one instance per session). And you can create custom scopes. But the reason for singleton being default is because, as I mentioned, most components don't need multiple instances and creating/maintaining multiple instances can have a negative performance impact. Just keep those singleton beans immutable and you'll be doing fine.
2 years ago
Whether you use Groovy or Java (or Kotlin or Scala or whatever) is really just a preference thing. Certainly you can get some productivity and code simplification gains by using a non-Java JVM language, but aside from the benefits provided by the language itself, I'm not sure that there's any benefits or negatives from using other languages with Spring Boot. Of course, if you're using the Spring Boot CLI, then Groovy is required.

Both IntelliJ and Spring Tool Suite (which is built on Eclipse) have excellent Spring Boot support. Being an STS user, I know most about what it offers, such as a project initialization wizard (based on what is offered at and really nice configuration property-name completion for and application.yml files. And there's a really nice Spring Boot Dashboard for easily firing up applications (either local or cloud-based) from the IDE. I know IntelliJ has a similar project initialization wizard (also based on, but I'm unsure what else it offers.

Certainly, the book covers the Actuator. As for what other modules, I'm not sure what you're asking for. But I can say that it definitely covers the top 4 main features of Spring Boot: Auto-configuration, starter dependencies, the Actuator, and the Spring Boot CLI. It also covers how to override/influence auto-configuration, how to take advantage of testing facilities offered by Spring Boot, how to set configuration properties (including profiled configuration), various deployment strategies afforded by Spring Boot, and even has a chapter touching on using Grails with Spring Boot (given that Grails 3.0 is based on Spring Boot). That said, it is very focused on Spring Boot itself, not on the greater Spring Framework and family of projects. Therefore, it doesn't go in depth on anything outside of Spring Boot any more than necessary to tell the Spring Boot story. If you are looking for in-depth coverage of other Spring projects, then Spring in Action 4th Edition is where you'll find it.
2 years ago
It's been silent here since late yesterday, so while I await more questions, let me clarify something about Spring Boot that I think a lot of people miss out on...

A lot of times when Spring Boot is demonstrated, it's done using the Spring Boot CLI and a tiny 60-character or so Groovy script (which I posted in another thread on this forum). That's a fun demo and is an extreme case of how simple Spring Boot can be, but it also turns away some developers who view it as a toy. They think that there's no way that they're ever going to develop and run production apps by writing really short Groovy scripts and running them on their production hardware by running something at the command line.

But to be clear, that's neither a toy nor is it the only way to develop Spring Boot apps. Here are the 3 main options available (and there are variations of each of these):

* Groovy scripts run through the Spring Boot CLI: Again, these are just plain, uncompiled Groovy scripts sitting in a directory. You run them with the CLI `spring run` command. You get all of the benefits of auto-configuration *plus* you get the benefit of some automatic import and dependency resolution. In other words, the CLI knows how to automatically resolve dependencies for some types and automatically add certain packages to the set of default packages so that you don't have to explicitly add import lines in the code. As I said, it makes for a great demo...but it doesn't mean that it's a toy. One way that it could be used in production is by placing the Groovy scripts inside of a Docker container and executing the CLI from the Dockerfile's entry point. You can also deploy these scripts to CloudFoundry with `cf push` and CloudFoundry will know what to do with them. And if you're worried about running tests, which is something that a conventional build normally does, there's also a `spring test` command to handle that for you. The only major downside with the CLI is that you can't use JSP for templates (but is that really such a bad thing?); you'll need to consider an alternative such as Thymeleaf, Velocity, or Groovy templates.
* Java (or any JVM language) code built with Maven or Gradle into an executable JAR file. This is a more familiar development model and more comfortable for most developers. You write Java code in your favorite IDE (Spring Tool Suite and IntelliJ IDEA both have excellent Spring Boot support) and use Maven or Gradle to build the code into an executable JAR. You get all of the benefits of Spring Boot auto-configuration, but you don't get the benefit of automatic dependency and import resolution like you would with the CLI. With an executable JAR file, you can deploy most anywhere that an executable JAR file can run, including CloudFoundry and within a Docker container. And because the servlet container is embedded in the JAR file (you choice of Tomcat, Jetty, or Undertow), you know you get a consistent platform no matter where it is run. (And I believe JSP is not going to work with executable JAR files here, the same as with the CLI.)
* Java (or any JVM language) code built with Maven or Gradle into a WAR file. This is the most familiar development model. This is essentially the same as building to an executable JAR file except that you have the option of deploying the app in a traditional way to an app server such as WebLogic or WebSphere. And you definitely get to use JSP if you want with WAR files. Oh...and if you want it is possible to build the app as an executable WAR file; that is, a WAR file that can both be deployed in a traditional way *and* be run from the command line. (Neat trick, but I'm iffy on what practical value it offers.)

There are variations for all of these, but these are the primary 3 ways to develop Spring Boot apps. Keep in mind that at no point is any code generated and the opinions imposed on your project by Spring Boot are concerning Spring configuration, not your application code.

2 years ago

Palak Mathur wrote:My personal preference is XML configuration. Java based configurations are a pain. It would be nice if we can migrate to some other format like yaml, json. Your code and configurations separation should be maintained and non-Java configurations help you do that.

Everyone has an opinion on XML configuration, for sure. I was skeptical of Java configuration when it first came along, but having worked with it for awhile, I've come to prefer it over XML. Even then, when possible I'd prefer other options where no configuration is required (as in component-scanning/auto-wiring and Spring Boot auto-configuration).

And although Spring doesn't officially support any other non-Java configuration other than XML (unless you count Groovy as non-Java), the framework is extendable enough that anyone could come along and build support for YAML or JSON configuration on top of it. Even so, Java configuration affords some possibilities that XML does not, such as type safety, refactorability, and "intelligent" configuration.

I agree that business logic and configuration code should be kept separate. But Java configuration doesn't prevent you from doing that just because the syntax is the same. Naming conventions and package placement can go a long way to keep configuration code separate from business logic code.

But don't worry. XML configuration won't be going away anytime soon. Even with Spring Boot, all you need is a @ImportResource annotation to add XML config to your app.
2 years ago
Firstly, I've never heard of Symfony 2, but that's likely because I very rarely venture into PHP space.

That said, Spring Boot *is* opinionated when it comes to how to configure Spring, but is not opinionated with regard to how you use Spring. That's because as soon as you form a strong opinion toward one library, templating engine, or whatever, you shut out a lot of other options. Flexibility is the key.

Even so, there *are* more opinionated frameworks layered on top of Spring and Spring Boot. You mentioned Grails; Grails 3.0 is nothing but a layer on top of Spring Boot with an opinionated programming model around how controllers, models, and templates are created. There's also JHipster, an opinionated framework on top of Spring Boot that provides for how to build Spring apps with Angular front-ends. Those are two that come to mind, but I'm sure there are more. (There's also Spring Roo, while not built on top of Spring Boot, is a layer on top of Spring itself that is very opinionated with regard to templating and model creation...and the use of AspectJ.)

I don't doubt the productivity you described with Symfony. But I could show you similar productivity stories in Spring Boot. In fact, I can easily imagine a rapid development of a large scale (>100 entities, using the metric you cite) app using Spring Boot + Spring Data JPA + Spring Data REST + Lombok and leaving the templating choice up to the developer (or pushing UI work into a JS framework such as Angular).

Having seen other threads where you've brought up the same question before, I'm not sure anything I've said will sway your opinion. And that's okay. You favor a strongly opinionated stack (which you can still build...explicitly or implicitly...on top of Spring Boot), whereas Spring and Spring Boot favor flexibility. At the end of the day, neither of us is wrong...we just differ in opinion.
2 years ago

Walter Andresen wrote:does it mean that the bean must tread safe?

As has been mentioned, this isn't really a Spring question...more of a general Java question, so I'll toss one more response your way then move on...

Thread safety becomes a lot less important if the object in question is immutable. Who cares how many threads are accessing an object if none of those threads are allowed to change the object? They don't need to be synchronized or any such thing. Moreover, thread-safety and synchronization doesn't guarantee that a thread won't change a value that another thread is counting only guarantees that they won't change it at the same time that the other thread is working with it (during the lock period). You could extend the lock period so that each thread has a full lock for the life of the thread, but then you will run into performance issues while all of the threads line up to wait for their turn.

Again, the best way to avoid concurrency issues is to employ immutability...that is, set those properties when the object is created (via constructor args) and don't offer setter methods where anyone can change them. Immutable objects are inherently thread-safe. But if immutability isn't an option, then judicious use of synchronization is okay...just be aware of the potential for performance problems.
2 years ago
The best way to avoid anyone messing with the properties of a singleton bean like that is to (1) make them final and (2) not provide setter methods for them. Ideally, provide the values via constructor args and not by setters.

That said, I recognize there are cases where you need setter methods for non-final properties. In that case, it may be best to only inject those objects as an interface type that doesn't offer setter methods. Without those setter methods, it'd be difficult (not impossible) to change the values.

In the end, however, if members of the team are hell-bent on changing values that shouldn't be changed, the best way of dealing with it is with code review and frank discussion about why changing them is wrong. In short, although there are technical remedies, the real problem is a people problem, not a technical problem.
2 years ago
As I replied to Aaron Brooks in this post (, Spring Boot is a fantastic way to get started with Spring. No need to learn how to write XML configuration or Java-based configuration until you need it. In fact, I was thinking earlier today that "Spring" is really best described as "Advanced Spring Boot".

2 years ago

paul nisset wrote:60 characters for an app is pretty impressive .

Since it was mentioned:

That's every single character of code required. The only prerequisite is that you have installed the Spring Boot CLI and run it with "spring run H.groovy". It will handle any HTTP request to localhost:8080 with "Hi!".

Note that the CLI is an optional (albeit, not a toy) approach to working with Spring Boot. You certainly can still use Java built with Maven or Gradle to produce executable JARs or WAR files.
2 years ago

Aaron Brooks wrote:Would "Spring Boot in Action" be a reasonable place to pick up / start over from, or would you recommend a different book first before diving into this one?

Indeed, Spring Boot is a great way to dive into Spring. It's entirely possible to write a complete (albeit extremely simple) Spring app using Spring Boot in less than a minute and fewer than 60 characters of code. It'd be impossible to achieve that kind of "getting started" story in Spring without Spring Boot. You can build on that experience to build more feature-filled applications, taking full advantage of Spring Boot to get stuff done quickly.

That's more or less the flow of the first couple of chapters of "Spring Boot in Action", so yes...I do think it'd be a great place to get started from. At some point you'll likely need to know more about how to explicitly configure Spring (because there are some things that Spring Boot can't do on its own and some other things you may want to override with explicit configuration). Because the focus is on Spring Boot, "Spring Boot in Action" doesn't go in depth on explicit configuration, even though it does show a few examples of how to do that. For a more in-depth coverage of how to do explicit configuration with Spring, I'd refer you to "Spring in Action, 4th Edition".

But since you asked about how to get started, then I certainly suggest "Spring Boot in Action". Once you've mastered that, you can pick up "Spring in Action" to figure out how to take your learning further.
2 years ago

paul nisset wrote:How does Spring Boot differ from Spring Roo ?

I briefly compared them in a separate thread, but here's another take on it...

Spring Roo made it easy to get started with Spring development by enabling you to specify features you want to add to your project and having it generate code for those pieces. For instance, you could ask for a new model object and it would generate a model class for you; ask for a controller and you get a basic controller; ask for scaffolding for a model and you get scaffolding. In most/all cases, you get a Java class that you can edit alongside an AspectJ inter-type declaration (, an introduction) that you're supposed to check into source control, but not touch. For scaffolding purposes, Roo would also generate (and to some degree maintain) JSPX files for your views. You can edit the JSPX files, but care has to be taken to ensure you don't edit something that Roo will regenerate for you.

The AspectJ ITDs made a lot of people uncomfortable, either because fear of AspectJ or because you can't edit them. And the "Real Object Oriented" nature of Spring Roo (which is where Roo got its name...not from kangaroos) wasn't welcome by many developers who demanded that Roo bend to fit more common patterns.

In short, Spring Roo employs code generation to promote a very opinionated programming model...and it's not even an opinion that many developers are comfortable with.

In contrast, Spring Boot, while somewhat opinionated, doesn't enforce any opinions on the patterns you use to develop your app. Its opinions are focused primarily on how to configure the components your app uses--You're welcome to do whatever you want with your application code. And...those opinions are easily overridden by simply writing explicit configuration; auto-configuration will step back if it sees that you've already configured something it was going to configure. And there's no code generation of any kind. All of the code you check into source code is code you write and you're welcome to edit it however you see fit. And although you're welcome to use AspectJ if you want, Spring Boot doesn't require it.
2 years ago
All that said, if the decision has been made to use Spring on a project, then the question of whether or not to use Spring Boot is pretty simple. In short: Why would you want to write and maintain code that configures your components in Spring if you don't have to?

There's a significant amount of Spring configuration that is common and quite similar between almost all Spring applications. Taking Spring MVC as an example, everyone using Spring MVC has to *at least* configure DispatcherServlet in web.xml and has to create a configuration class that's annotated with @EnableWebMvc (or alternatively an XML file with <mvc:annotation-driven/>) before they can even write a controller to handle a request. And that same kind of common configuration is found in all areas of Spring, not just MVC.

So the question is: If everyone has to write that configuration, then...why does everyone have to write that configuration?!?!? Can't Spring just *know* that I need that stuff? Why must I write so much common configuration to satisfy the framework? Why can't the first line of code I write be something that directly addresses the functionality of the app?

And that's the question that Spring Boot answers. Auto-configuration determines what common stuff your app will need and will automatically make it available for you. In the Spring MVC example, that means the first line of code you write is for a controller that handles a web request. You do not have to configure DispatcherServlet and you do not have to create a configuration file that enables Spring MVC. You just write a controller and Spring Boot takes care of the rest.
2 years ago
The best answer I can give you is that you've not talked to the right companies. Spring Boot is widely adopted. As I mentioned in another thread, there are many well known and respected companies across all industries using Spring Boot.

I can also offer that Spring Boot is relatively new (only a few years old) and that it's not always easy to retrofit an existing Spring app to be based on Spring Boot (not impossible, but not necessarily easy as I've already mentioned in another thread). There were plenty of Spring applications written before Spring Boot and plenty of teams who haven't been brought up to speed on Spring Boot yet. But that doesn't mean that Spring Boot isn't widely adopted. It just means that those projects and teams haven't adopted it yet.
2 years ago
It kind of depends. With microservices and the patterns and support for them being relatively new, not all teams are able to "think in microservices" very effectively. For such a team to attack an app as a microservices-based app might result in a misapplication of the technologies and patterns and be worse than a monolithic implementation. It *might* be better for such a team to start with a monolith and then later peel off microservices.

That said, the benefits of microservices (there are many, but focused scalability and continuous delivery are the two that come immediately to mind) are great enough that it might be worthwhile to get up to speed with microservices and what is required before starting a new project and then deciding whether or not to go with microservices or a monolith.

I guess I can't say what the right approach is for a new project. It's not a one size fits all kind of thing. It depends on the team and the goals of the project. Personally, I lean toward microservices but that's more of a symptom of what I do day-to-day than it is a dogmatic application of microservices. I'd say that if the team does not have a good grasp on what is expected to develop microservices and doesn't have the time nor interest to get up to speed, then they should definitely go with a monolith. But if they feel that they have a grasp on it and if the project's goals justify it, then go for microservices.

The good news is that regardless of what you decide, Spring Boot is a fit for either.
2 years ago