<@U0JRS2YUB> We used Spring for dependency injecti...

# announcements

[janvladimirmostert]

@sreich We used Spring for dependency injection, Spring Data with Hibernate, Spring AMQP to get RabbitMQ access, Spring Integration for connecting stuff, Spring MVC for HTTP endpoints, Spring Web Services for SOAP, Spring ROO for DB model generation, etc
We used a lot of Spring components!

Now we simply don’t use dependency injection anymore, the Kotlin syntax is powerful enough to write our own interfaces that wraps singletons, so where we need that pattern, it’s simple enough to do it ourselves.
Spring Data we ditched as well as aspectJ and Spring Roo which were all wrapping Hibernate objects (Spring Roo generates Hibernate / JPA objects with so much AspectJ boilerplate that it just had to go), using straight Hibernate with some Kotlin method extensions meant our only dependency is now Hibernate and since there’s no annotation scanning, startup time of the project has reduced dramatically.
Further, we get a lot more control over the process since ditching Spring wanting to manage the whole EntityManager lifecycle.
Our Hibernate models also went from 1000s of lines to just the bare-minimum code needed to represent the database model since all generated Spring Roo stuff disappears, getters and setters disappear, etc.

Spring AMQP we replaced with straight RabbitMQ Client library and using some extension methods, we made it idiomatic Kotlin in order to get exactly what we need without any of the stuff we don’t need.

Spring MVC we replaced with VertX + VertX Web, although I quite like Spring MVC, I like VertX so much better. Spring MVC has so much in it that we don’t need - Spring MVC is bloated compared to VertX, application startup is now in the millisecond range instead of taking 5 seconds to startup.

Spring Web we’re still considering options, the way it can generate a WSDL is quite neat, but we’ll probably make the WSDL a static file and use some form of XML parsers combined with VertX. We have a lot of code that needs to work at the servlet level and still need to access the spring context, going vertx we get rid of the servlet and spring context which means we’ll reduce clunky inject spring context code into servlets or extracting servlet http requests into spring context.

Spring Integration we easily replaced with Apache Camel, we’re looking at writing our own Kotlin DSL for Apache Camel, but so far the Java methods with some extension methods is working quite well for us.

Spring Security we just rolled our own - extension methods + VertX gives you many options for request filtering.
Spring Security was painful to work with, certain things we had to bend backwards so that Spring Security could work and then getting the annotations working was painful - now we just have Kotlin code, much easier to reason about the security that having to guess what Spring Security is doing.

To replace Spring Config, we just rolled a simple 100 line lib that gives us exactly what we needed with regards to configs and we can actually do with it exactly as we please, even have it reload configs in realtime whereas this was difficult with Spring.