Monday 28 November 2016

Spring as a Spec?

We've been maintaining Spring integrations bits in Infinispan for quite a while. Our development version, Infinispan 9, contains a set of changes in those modules which deserve some explanation...

Versions... versions everywhere...




When you use Infinispan, you rely on some, very specific version. The same applies to Spring. Before Infinispan 9 our integration modules had a compile-time dependency to a very specific version of Spring. In practice, we imposed this specific version to each project which used our integration bits. The question is - what to do to use some other version of Spring or Spring Boot? Till Infinispan 9, the simplest solution was to exclude Spring from infinispan-spring4-embedded (or infinispan-spring4-remote) artifact using Maven exclusions. Not a very nice and intuitive solution was it?


How about treating Spring as a Spec or API


You probably noticed, when you use JPA you don't care about underlying implementation. Is it Hibernate, OpenJPA... it doesn't matter?

If you think carefully about Spring for a while, it's a bit similar. All core classes might be delivered using standard dependency mechanism (adding spring-beans, spring-context manually), using Spring Boot (adding spring-boot-starter) or even using 3rd party integration tools like DropWizard. In case of a bigger project, a decision whether or not use any of those solutions needs to be taken long before Infinispan is chosen as a Distributed Store or Cache.

At this point, we can do a mental experiment - treat Spring classes as a Spec or API and those delivery mechanisms treat as implementations.


Scope? Provided, of course!


From Infinispan integration perspective we need the Spring API (the classes) and we don't care about the implementation (delivery mechanism). Having this in mind we decided to change Spring's scope in Infinispan modules to provided.


I use Infinispan and Spring, what shall I do?


Starting from Infinispan 9, you can stop using exclusions. You probably already use Spring and your favorite delivery mechanism (Spring Boot for example). Then add infinispan-spring4-embedded or infinispan-spring4-remote artifact. Finally, you need to decide how would you like to use Infinispan - via Uber Jars (infinispan-embedded and infinispan-remote) or using Small Jars (infinispan-core for example).

That's it! Have fun!



Wednesday 16 November 2016

Infinispan 8.2.5.Final

Dear Infinispan users,

we have just released Infinispan 8.2.5.Final which fixes a number of community-reported issues. Get the bits from our download page. As usual feedback is always welcome.

Friday 11 November 2016

Hotrod clients C++/C# 8.1.0.Alpha2 released!

Dear Infinispan community,

I'm pleased to announce that the C++/C# clients version 8.1.0.Alpha2 are out!

Some of the good news coming with this release:
  • more bugs fixed than added
  • SNI support
  • C++ Client listener for remote events

Download it from the usual link http://infinispan.org/hotrod-clients/


We're trying to keep track of the 8.1 trip at this Jira url:
Features list for 8.1
Feedbacks, proposals, hints are welcome!

Cheers,
The Infinispan Team

Wednesday 2 November 2016

Infinispan coming to Devoxx Morocco!

Tomorrow Thursday, 3rd November, I'll be speaking at the Devoxx Morocco conference (Casablanca, Morocco) about writing apps in functional reactive programming style with Infinispan, Elm and Node.js. If you're interested in the topic and live in the area, make sure you come to my talk!

To find out more, head to the Devoxx Morocco site, where you can find exact details about the rest of the programme, location...etc.

Cheers,
Galder