2014-08-25 Tweets

Spring Boot Presentation at AustinGUG

On June 12, Vasu Srinivasan spoke at the Austin Groovy and Grails User Group about Spring Boot. Here are my notes from the meeting.

Video: Battle of Software Languages
What is wrong with current Spring?
Scalability is an issue
Stateless services are better
Do we really need WebSphere for everything?
Rampup time can be pretty high to get things going

Why Spring Boot?
xml for configuration: verbose, bloated, error-prone
Many web app frameworks that started after Spring do not use XML
Ramp up time is important
Opinionated frameworks are becoming fashionable
Spring has to compete with Ratpack, DropWizard, Sinatra, Scalatra, micro-services architecture
Spring has a lot of libraries and components, it needs a way to tie them together

Convention over configuration

What is it?
It’s a container project for creating new Spring projects
It comes with Tomcat or Jetty
It has a lot of starter POMs for lot of libraries:: web jdbc, log, data
It has actuators (health, metrics, beans info, etc)
It supports XML, Java annotated and Groovy bean configuration (not much doc on Groovy)
Supports many databases
Can be used for web/non-web (batch) functionality
Supports many views (jsp, thymeleaf, groovy template engine)

Tradition Spring apps usually Java, what about Groovy?
spring-cli lets you use Groovy, then spring run app.groovy
You can use Groovy as THE language:
apply plugin:’groovy’

You can use Groovy bean instead of xml
GroovyBeanDefinitionreader, likd Grails resources.groovy
Groovy Template Engine
You can use GORM
Annotate with @Entity

Immediate advantages with Groovy
Practical and time-saving annotations: @ToString, @Log, @EqualsAndHashCode
Groovy 2.3 has fast JSON conversions
Groovy Strings
Spock testing
You can compile with @CompileStatic to get faster performance

Go to http://start.spring.io/ to create project

You can use logback, that is what Spring team recommends
The command is gradle bootRun
The for prod, gradle buildJar

Good, Baffling, Unexpected
REST is easy, deployment is easy
Java annotated config is good
Gradle support is good

So many ways to do properties
Decide early, YAML is recommended
Too many logging frameworks
No out of the box support for profiles
Lots of annotations
I mean a LOT of annotations
Many places to put views

Not all xml config an be done with Groovy
No way to directly convert Grails domain objects to JSON
Some things are broke in 1.1, like Gorm

With IntelliJ, you must run in IDE, not with Gradle
Sometimes port is not released
You need to associate template files with Groovy

Nice to have: Groovy config support
Expose entities as REST entities
Maybe it’s in the works

Is it for you?
Are you using Spring?
Do you want better deployment, you want to scale


Another Update For Groovy Validators

I made an enhancement to the Groovy Validator project.

I added a boolean called “throwException” that will throw an exception if one of the fields does not validate. It is optional, and defaults to false. If an exception is thrown, it will print out the value and the constraints.

You can use it for POGOs with the AnnotationProcessor class like this:

AnnotationProcessor.process( Book, true )

You might get a message like this:

"Hey" is a String with a length outside the range of 5 and 10"

You can also use it with immutable objects annotated with the AstImmutableConstructor annotation. This would be a second boolean after the Map with your properties, since the first boolean controls validation:

def thirdImObject = new ImmutableObject002( 
[ firstString: "Hi Once Again", firstInt: 123456789, firstLong: 22L ], 
true, true )

In that case, you get a message with a line for each field. So you might get a whopper message like this:

Groovy validation exception: 
"eeeeeeeeeee" is a String with a length outside the range of 5 to 10 characters 
"NNNNNNNNNNNNNNNN" is a String with a length outside the range of 0 to 15 characters 
101.0 is a double outside the range 10.0 and 100.0 
101.0 is a float outside the range 10.0 and 100.0
101 is an integer outside the range 10 and 100 
101 is a long outside the range 0 and 100

If “thowException” is true for a POGO, the field will either retains its pre-existing value (if it had one) or be set to null. If “throwException” is true for an immutable object, the object will not be created.

You’re welcome.

2014-08-11 Tweets

Grails and PostgreSQL

In addition to the Austin Groovy and Grails User Group, I also go to the  Austin Postgres Users Group.

At the last APUG meeting there was no set agenda or presentation. They just had a Q&A with whoever wanted to answer. The company that hosts the APUG is a heavy Postgres user.

I had a few questions. The basic thrust was: What are some things DBAs wish developers knew about databases or did differently?

One answer was that developers should learn to think in sets. If you need to change a bunch of records in the database, just run a query that will update them all at once. A lot of developers would get a query (with an ORM) that would put the objects into a list, then iterate through the list and update them one at a time. This would be a much heavier load on the database. Just run a query.

In GORM, you can call .withSession on your domain classes to get the Hibernate session, and use that to run queries.

Another suggestion was to deal with views instead of tables. I really do not have any knowledge about that WRT Grails.

The last thing that I remember is that you should not think that you are the only person who touches the database. Someone else will want to run queries, and perhaps add data to it. Many web frameworks (like Grails and Rails) have database constraints if you access the database through the web app. But outside the app, you are on your own.

One small project I will start is I will go through the Grails constraints (see here and here) and see how to create them in Postgres. I might do MySQL as well. There are a few that Grails will put in the database when it is generated by Grails, like uniqueness, foreign keys, and whether or not a field can be null. But for most of them, they only exist in Grails.



Back From Gr8Conf

I went to Gr8Conf last week.

I really cannot think of a whole lot to say at the moment. I am excited that there is a lot going in the Groovy and Grails space.

Right now I will have to go through all my Grails apps and change the controllers so the create, edit and delete actions in the controllers send their work to Grails services.

I have been working on using the Grails Shiro plugin. I asked for help with it from the guy who used to maintain it, Peter Ledbrook. I was not able to get examples from other apps to work. He was not able to get things running for me either. It turns out the app I was working with was also using the Shiro-UI plugin. There were two “Auth” controllers, and that was messing things up.

I have tried working with the Grails Spring Security Core plugin. It is easy to get up and running, but writing tests for an app that uses it is pretty hard. I got it working myself, but it took a lot of Googling (and as many  of you know, you Google after you have driven yourself crazy trying to figure it out on your own). The way I got it to work was a bit of a jumble in my opinion, with some Spock mocking mixed in with some core Groovy mocking. I realized why it was so hard when one of the presenters said that services should only be called from controllers. Spring Security Core requires you to run the plugin as a service from your User domain classes.

I will try to write some tests for an application using the Shiro plugin. Hopefully it will be easier.

I think the reason I had so much grief with the Spring Security tests is because a lot of tutorials do not really cover services too much. Since they are not covered, I guess people don’t think about them too much. One person I talked to said that one reason for that might be that the controller generators do not put edit, save and delete in services, so people think they can get by without them.

I might post my notes online later.

2014-07-28 Tweets