This Week in Spring - November 17, 2015

Engineering | Josh Long | November 17, 2015 | ...

My goodness the time has flown! We're already staring down the beginning of 2016!

Welcome to another installation of This Week in Spring! This week I'm in beautiful Casablanca, Morocco for Devoxx Morocco! This is the fifth Devoxx this year - with events in Belgium, UK, France, Poland and now Morocco - and I have the rare honor of having spoken at all of them! #fullDevoxx

We've got a lot to cover this week so let's get to it!

This Week in Spring - November, 10, 2015

Engineering | Josh Long | November 10, 2015 | ...

Welcome to another installation of This Week in Spring! This week I'm in Antwerp, Belgium for the grand mother of all Devoxxes (Devoxxen?), Devoxx Belgium! I'm here along with several members of the team and if you're around, don't hesitate to say hi!

This Week in Spring (PCF 1.6 edition!) - November 3, 2015

Engineering | Josh Long | November 03, 2015 | ...

Welcome to another installation of This Week in Spring! This week I'm in Sofia, Bulgaria for one of my favorite shows, the epic Java2Days event!

Last week saw the release (finally!) of Pivotal Cloud Foundry 1.6, which contains more than a year and half of highly anticipated features and heavy lifting. The new release includes, among many other things, support for platform-managed GitLab, JFrog Artifactory, and CloudBees Jenkins CI; support for microservices infrastructure including the Spring Cloud Config Server, and Spring Cloud Eureka; and support for Docker container images and .NET applications; and support for running on Microsoft Azure. This release is packed with all sorts of features optimized for the continuous and safe delivery of software into production and I…

Spring XD 1.3 Demo: Flo for Batch

Engineering | Pieter Humphrey | November 03, 2015 | ...

Flo for Batch pipeline builds upon the newly supported Batch DSL in Spring XD that can be used to create composite batch workflows involving sequential, parallel or even the combination of both jobs.

This Week in Spring (JavaOne 2015 Edition) - October 27, 2015

Engineering | Josh Long | October 28, 2015 | ...

Welcome to another installation of This Week in Spring! This week I'm at JavaOne 2015 in San Francisco along with the rest of the Pivotal team. This week the Pivotal Spring team is out in full force, come stop by and say hi!

There are some great new SpringOne2GX 2015 recordings on line as well as some great community content this week so let's get to it!

React.js and Spring Data REST: Part 5 - Security

Engineering | Greg L. Turnquist | October 28, 2015 | ...
To see updates to this code, visit our React.js and Spring Data REST tutorial.

In the previous session, you made the app dynamically response to updates from other users via Spring Data REST’s built in event handlers and the Spring Framework’s WebSocket support. But no application is complete without securing the whole thing so that only proper users have access to the UI and the resources behind it.

Feel free to grab the code from this repository and follow along. This session is based on the previous session’s app with extra things added.

Adding Spring Security to the project

Before getting underway, you need to add a couple dependencies to your project’s pom.xml file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.thymeleaf.extras</groupId>
    <artifactId>thymeleaf-extras-springsecurity4</artifactId>
</dependency>

This bring in Spring Boot’s Spring Security starter as well as some extra Thymeleaf tags to do security look ups in the web page.

Defining the security model

In the past session, you have worked with a nice payroll system. It’s handy to declare things on the backend and let Spring Data REST do the heavy lifting. The next step is to model a system where security controls need to be instituted.

If this is a payroll system, then only managers would be accessing it. So kick things off by modeling a Manager object:

@Data
@ToString(exclude = "password")
@Entity
public class Manager {
public static final PasswordEncoder PASSWORD_ENCODER = new BCryptPasswordEncoder();

private @Id @GeneratedValue Long id;

private String name;

private @JsonIgnore String password;

private String[] roles;

public void setPassword(String password) {
	this.password = PASSWORD_ENCODER.encode(password);
}

protected Manager() {}

public Manager(String name, String password, String... roles) {

	this.name = name;
	this.setPassword(password);
	this.roles = roles;
}

}

  • PASSWORD_ENCODER is the means to encrypt new passwords or to take password inputs and encrypt them before comparison.
  • id, name, password, and roles define the parameters needed to restrict access.
  • The customized setPassword() ensures that passwords are never stored in the clear.

There is a key thing to keep in mind when designing your security layer. Secure the right bits of data (like passwords) and do NOT let them get printed to console, into logs, or exported via JSON serialization.

  • @ToString(exclude = "password") ensures that the Lombok-generated toString() method will NOT print out the password.
  • @JsonIgnore applied to the password field protects from Jackson serializing this field.

Creating a manager’s repository

Spring Data is so good at managing entities. Why not create a repository to handle these managers?

@RepositoryRestResource(exported = false)
public interface ManagerRepository extends Repository<Manager, Long> {
Manager save(Manager manager);

Manager findByName(String name);

}

Instead of extending the usual CrudRepository, you don’t need so many methods. Instead, you need to save data (which is also used for updates) and you need to look up existing users. Hence, you can use Spring Data Common’s minimal Repository marker interface. It comes with no predefined operations.

Spring Data REST, by default, will export any repository it finds. You do NOT want this repository exposed for REST operations! Apply the @RepositoryRestResource(exported = false) annotation to block it from export. This prevents the repository from being served up as well as any metadata.

Linking employees with their managers

The last bit of modeling security is to associate employees with a manager. In this domain, an employee can have one manager while a manager can have multiple employees:

@Data
@Entity
public class Employee {
private @Id @GeneratedValue Long id…

The Spring Boot Dashboard in STS - Part 3: Spring Boot Devtools reloaded

Engineering | Martin Lippert | October 22, 2015 | ...

Welcome back Spring community,

to this final part of our series about the new Spring Boot Dashboard in the Spring Tool Suite. In this final part we will take a deeper look at using the Spring Boot Devtools in combination with the boot dashboard. Again, this feature is new with Spring Boot 1.3, so you need to be on that version in order to use the following features.

Quickly deploy code changes

For local apps, using the Spring Boot Devtools is extremely easy and straightforward. As soon as you add the Spring Boot Devtools to your project as a dependency (there is an easy menu option for that in the Spring category of your context menu) and start your app, it will listen for local changes to configuration and class files and kick a restart of the app for you automatically. You don’t even need to restart the app yourself, the Spring Boot Devtools will do that for you automatically. Since STS/Eclipse produces and updates class files whenever you save a file, all this happens automatically for you when working within STS.

This story gets more interesting if you run your Spring Boot apps on a remote runtime like Cloud Foundry. In principle, you can use the Spring Boot Devtools in such a remote setting as well, but it requires a bit more work. The good news is that the Spring Boot Dashboard helps you with that.

As soon as you deploy or restart (and therefore update) a Spring Boot app on Cloud Foundry (using the boot dashboard) that has the Spring Boot Devtools on its classpath, the boot dashboard will configure the boot app on CF for the remote usage of the devtools automatically. This includes primarily the setting of a remote secret - to allow remote devtools access to it.

Once the devtools-enabled boot app is running on Cloud Foundry, you can easily start the boot devtools remote client application for it. This client application runs locally on your machine and connects to the remote application on Cloud Foundry. It watches for file changes, uploads them to the app on Cloud Foundry and triggers a restart of the app on Cloud Foundry.

Since the remote client app will watch for file changes within the project on your local machine, you can continue to work within your IDE as usual. Changed files are automatically updated to the Cloud Foundry version of the app by the remote client app. The counterpart on Cloud Foundry will restart the boot app once those changed files are stored to the app on Cloud Foundry. This works for newly compiled source code as well as for changed resource files.

This allows you to achieve quick turnaround cycles when working on your project even if it is deployed to a remote cloud runtime.

Debugging in the cloud

In addition to the automatic restart feature, the Spring Boot Devtools also enable full debugging of remote apps on a cloud runtime. This is supported by the Spring Boot Dashboard in STS, too. If you have the Spring Boot Devtools on the classpath of your application, you can press the (re)debug button for the Cloud Foundry instance of the app. This will restart the app on Cloud Foundry in debug mode, automatically start the corresponding remote client app on your machine, and hook up the Eclipse debugger to it.

You can debug the application that is running on the cloud runtime in the same way as local applications, including setting breakpoints, inspecting variables, or even hot-swapping code. However, the automatic restart feature is not available for apps running in debug mode (due to technical limitations of the boot devtools at the moment).

If you try the remote debugging of apps on Cloud Foundry, you will notice a significant slowdown in debugging. This is caused by the tunneling of the remote debug protocol of the JVM through a HTTP connection, something the remote debug protocol is not designed for. We are working on improving this by using a different transport mechanism. But the remote debugging of the app on Cloud Foundry should be something you rarely do. For more frequent debugging you might want to consider running and debugging the app locally and connecting it up with the rest of your application services via the ngrok tunneling feature that we described in the previous part of this blog series.

Conclusion

This concludes the blog series on the Spring Boot Dashboard, a new feature in the Spring Tool Suite since its 3.7.1 release. Let us know about your experiences using the dashboard.

This Week in Spring ( SpringOne2GX replay / Pieter Humphrey edition!) - October 21, 2015

Engineering | Josh Long | October 21, 2015 | ...

Welcome to another installation of This Week in Spring! This week is the first week (of many) where the crazy awesome [https://twitter.com/pieterhumphrey](Pieter Humphrey) has released scores of SpringOne2GX 2015 videos for our binge watching enjoyment! Most of this week's bountiful roundup is thanks to Pieter's meticulous transcoding, uploading and posting videos from SpringOne2GX 2015 - thanks Pieter! So without further ado, let's take a look at some of this week's selection including a LOT of content from SpringOne2GX, including..

SpringOne2GX 2015 replay: Booting IoT with Grails

Engineering | Pieter Humphrey | October 19, 2015 | ...

Recorded at SpringOne2GX 2015.

Speakers: Colin Harrington, OCI Web

Slides: http://www.slideshare.net/SpringCentral/booting-iot-with-grails

In a world of the cloud, virtualization, containerization, microservices and nanoservices we talk about scaling up, scaling out, and decoupling our systems, but typically miss scaling down to an embedded platform. At the same time that we have moved away from heavy monolithic web containers, we've seen a rise of powerful low cost embedded Linux devices such as the RaspberryPi.

The Spring Boot Dashboard in STS - Part 2: Working with Cloud Foundry

Engineering | Martin Lippert | October 15, 2015 | ...

Welcome back Spring community,

In this second part of our blog series about the new Spring Boot Dashboard in the Spring Tool Suite we will move beyond local applications in your workspace and take a look at remote apps deployed to a cloud runtime. If you missed the first part, please take a look it to get familiar with the boot dashboard in STS first.

Cloud runtime support

The initial remote target that we support in the Boot Dashboard is Cloud Foundry. Neither the design nor the implementation of the Boot Dashboard limits this to be the only supported remote target, it is just the first one that we worked on.

The goal for us was to provide a similar experience as for local apps, giving you an easy way to interact, start, stop, update, and lookup log output of your Spring Boot apps on Cloud Foundry. Therefore you can add a Cloud Foundry section to the boot dashboard using the big plus icon in the toolbar.

Once you entered your credentials and selected an org/space, a new section will appear in the boot dashboard, listing the apps that are deployed to this space on Cloud Foundry. You can see the name of the app as well as the number of instances that are configured and that are up and running.

The basic actions work for one or multiple apps on CF in the same or a very similar way to how they work for local apps. You can jump to the console output and it will appear in the console view of STS/Eclipse, you can start and stop apps, you can double-click them to get to a browser window for the running app, you can configure a default path for the app, and you can add/remove tags to/from those apps. You can even execute some of the actions (like start and stop) across targets, if you select multiple entries in the boot dashboard across those target sections.

In addition to the common actions that are suitable for local and apps on Cloud Foundry, there are certain additional actions specifically for apps on Cloud Foundry. The boot dashboard allows you, for example, to delete an app entirely from Cloud Foundry, or to easily jump to the web console.

Deploying to Cloud Foundry

Up to here, we talked about existing apps on Cloud Foundry. But how do you get your apps deployed to Cloud Foundry? There are various ways, using the CLI or the Eclipse Plugin for Cloud Foundry. The boot dashboard offers you another option: you can drag&drop your Spring Boot application directly onto the Cloud Foundry target in the dashboard and it will deploy the Spring Boot app to CF. This is as easy as its sounds.

If your application contains a manifest.yml file, this will be used to configure the application for Cloud Foundry. This typically contains the name of the app, the domain, memory settings, number of instances, and potentially a lot more.

If you don’t have a manifest.yml file in your project, the deploy action will prompt you in a dialog for the basic information it needs to deploy the app.

But take care: if the project contains a manifest.yml file, it will be used to deploy and configure the app. Changes to the configuration on CF that you might have made via the web console will be lost the next time you restart/redeploy/update your app using the boot dashboard. Either configure everything in the manifest.yml file or go without it altogether - at least for the moment. We will be working to improve this to allow more flexible ways of dealing with manifest.yml files and external changes to the config of your app, but that is something to be done in future releases of STS.

Once the app is deployed, the boot dashboard will keep the association between the project in your workspace and the deployed app on Cloud Foundry (and will show this association in the boot dashboard).

Keeping this association between your workspace project and the app on Cloud Foundry makes changes to this app a lot easier. If you change the code in your workspace and press the (re)start button for the app on CF, the boot dashboard will automatically re-push the app (the changes) to Cloud Foundry.

Once you have deployed your apps on Cloud Foundry, you often don’t need to work on everything locally at the same time. Usually you focus on certain parts of the application and sometimes you would like to use use even both: some services running on Cloud Foundry and some services running on your local machine in your IDE. But how do they interact?

Tunneling local services for mixed deployments

As an early experiment, we built a specific feature into the boot dashboard that lets you use all your services and apps on CF and have them call individual services running on your local machine. That way you can focus on individual projects of your landscape and continue to use Cloud Foundry for the rest of your world. You can quickly iterate and work on the code locally - and test it while working with the other parts on Cloud Foundry. Isn’t that great?

They way this works is: You have a service discovery mechanism for your microservices in place. At the moment we support the Eureka service discovery service for this feature. You can start your local Spring Boot app using a special action called “(re)start and expose app via ngrok”. Executing this action will (re)start your local app on your machine. At the same time the action will create a public visible tunnel to this app using the ngrok service. As a result, you get a publicly visible URL that routes all its traffic to your local machine and to the local Spring Boot app that is running on your local machine. The app is automatically configured to register with the remote Eureka using this publicly visible tunnel URL.

Clients to this service will now get this tunnel URL from Eureka instead of (or in addition to) the default instance of your service that might be running on Cloud Foundry already - and will call your locally running service instead of the one on CF. You can iterate on your local service quickly or even debug it.

This mixed deployment scenario is obviously not useful for production or team environments, where multiple people are using the applications on CF simultaneously. But this is extremely useful for testing and development environments.

The support for Cloud Foundry is just a starting point here. The Spring Boot Dashboard is by no means limited or focused on Cloud Foundry. Other remote cloud runtimes could and will be added in the future. One of the next runtimes that we are going to work on is Lattice, but other runtimes are very welcome as well. If you are interested in collaborating on this, let us know. The Spring Boot Dashboard is open-source under the EPL and we would be more than happy to collaborate with you on additional features and adding support for more cloud runtimes to it.

Outlook

The third part of this series will introduce you to the built-in support for the Spring Boot Devtools and how you can use them from within the Boot Dashboard to make quick modifications to your apps (even on CF) and how to do remote debugging on CF.

Get the Spring newsletter

Stay connected with the Spring newsletter

Subscribe

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Tanzu Spring offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all