Spring Modules had a #Cacheable annotation:
org.springmodules.cache.annotations.Cacheable
Now that Spring Module is deprecated, what is the recommendation for caching? And is still still possible to work with ehCache?
Users of Spring Modules have rather been left out on a limb. There's no direct replacement for #Cacheable that I'm aware of.
Spring does have some support for EhCache, though, in the form of EhCacheFactoryBean and related classes (see javadoc). This gives a pretty easy way of creating and managing EhCache instances, but you then have to make use of it manually.
The distribute cache server is memcached. I has api to java.
http://memcached.org/
This project is intended as a direct replacement: http://code.google.com/p/ehcache-spring-annotations/
This is now found in spring-context. I have not checked how far back it is, but it is in the 4.1.4.RELEASE.
\org\springframework\cache\annotation\
Related
I am new to Spring cache abstraction. I have explored it using ehcache and apache ignite caching providers.
I want to know if spring cache abstraction supports the caching strategies of Write-behind and write-through.
Thanks,
bs
There is no direct support for cache-through in the declarative Spring abstraction.
And in a way it makes sense, since the abstraction lets you surround methods with caching related annotations. But with a cache-through pattern, the whole method would only be a cache interaction: a get for read, or a put for write. Not the if-then-else that the annotation abstracts.
However, if you use the CacheManager and Cache interfaces provided by Spring directly in your code, you can perfectly use them in a cache-through way.
Ignite cache has a notion of CacheStore interface that used in cases when there is a need to wire the cache with a persistent store (RDBMS, MongoDB, Hadoop, etc.). This interface provides write-through/write-behind and read-through semantics. Please refer to this documentation for more details.
Also I would recommend taking look at various examples that demonstrates how particular CacheStore implementations are used in Ignite. The examples are available in Ignite release bundles.
I want to use Ehcache in my portlet application. If I want to remove data from cache, it is better to use #CacheEvict or #TriggersRemove?
According to documentation it looks like #CacheEvict and #TriggersRemove annotations are very similar.
disclaimer: I am working on the Spring caching abstraction (amongst other things).
These are two annotations from two different projects. I don't know much about TriggersRemove but from what I can see, it is ehcache specific.
The caching abstraction in the Spring Framework is completely decoupled from the underlying infrastructure so you can use that with basically any caching library out there, including ehcache. If you want your code to be independent from the caching library you use, I'd advise not to use TriggersRemove. If that's not a problem for you, check the documentation of each solution and choose accordingly.
Does anyone know any Java frameworks that follows the repository approach with automatic implementation of query methods (e.g. findByNameAndLastName(…)) but not tied to Spring, only pure JPA. Such feature also exists in GORM. I would like to see if there is any project that can be used in Guice or pure JavaEE environment without bringing Spring as a dependency.
(Disclaimer: I am the author of Spring Data JPA)
There is the CDI Query Module which is very similar to what Spring Data JPA. There's also a DeltaSpike module.
Note that Spring Data JPA ships with a CDI extension that creates repository proxies as plain CDI beans and does not bootstrap a Spring container. There are APIs that allow the creationg of repository proxies programmatically such as:
EntityManager em = // … obtain EntityManager
JpaRepositoryFactory factory = new JpaRepositoryFactory(em);
UserRepository repository = factory.getRepository(UserRepository.class);
Yes, it still requires Spring libraries to be present on the classpath but it is then using them similar to how you would use Commons Collection or the like. We try not to reinvent the wheel and the Spring libraries we depend on provide a lot of useful code that we do not have to re-code.
So if it's Spring as DI container you're worrying about, feel free to give the CDI extension of Spring Data JPA a choice. If you don't want to use any Spring whatsoever (for whatever reason), have a look at the alternatives.
Based on Oliver's information, followed up as also interested in this topic --
CDI Query joining Deltaspike mail thread: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Porting-the-CDI-Query-extension-project-to-DeltaSpike-td4329922.html
Deltaspike base link: http://deltaspike.apache.org/index.html
Getting started: http://deltaspike.apache.org/documentation.html
Just did their 0.4th release as of 5/31/2013.
However, have not done enough of a review to contrast/compare Deltaspike versus Spring-Data w/ CDI extensions (spring-data being very mature).
Take a look at Tomato on github!
It is a functional replacement for Spring JPA, has zero dependencies, performs better and is far easier to use. It will reduce your data access code by 98% and deliver the results you want right out of the box.
https://rpbarbati.github.io/Tomato.
If you want free, fully functional dynamic forms and/or tables for any Tomato entity or hierarchy, that can also be customized easily, try the angular based companion project...
https://rpbarbati.github.io/Basil
Both are current, maintained projects.
Try it yourself, or contact the author at rodney.barbati#gmail.com with questions.
Spring is a popular framework, however I have difficulties to see in which situation the framework would actually help.
Currently I'm using the following:
* Tomcat
* Jersey
* Jackson
* Hibernate
Together this results in a Webservice, created by annotations, automatic JSON (un)marshalling and a comfortable Object/Relational Mapping.
So honestly at the moment I'm not missing anything, but I might just not know what great thing I'm missing... Could you help me out with this?
Thank you
Spring is a big framework providing a lot of functionality. It's hard to talk about advantages without knowing what functionality are you trying to use in the project.
Most probably you talk about Spring as an IoC container. It is very important part of Spring, but there is also AOP, transaction management, JDBC abstraction layer, authentication and authorization, testing and some more.
In a nutshell, Spring offers you uniform way to control dependencies between your objects. This is called inversion of control or dependency injection. Using it you can create pluggable, testable code that is easy to maintain.
In addition it gives you gazillion utility classes that just make life easier. For example, Hibernate is much easier to maintain via Spring facilities. It kind of brings together many different technologies under the same roof.
All websites state that the Spring core container is the basis for complete Spring framework i.e., it is used across
the all modules like AOP, JDBC module, Web module, etc. As per my understanding, the Spring core container's main purpose is
to inject dependencies, so avoiding the need of factory classes and methods. Is that correct?
Second question: When it is said, Spring core container is the basis for complete Spring framework (e.g., for Spring AOP). As per my understanding, in Spring AOP also, getting the object of classes like
ProxyFactoryBean is achieved by core container. Right?
Thirdly, it is stated that Spring core container avoids the need for programming the use of singletons. How come singleton
classes are avoided by core container?
yep
yep
All beans declared in Spring config files are singleton by default. They are instantiated when your application starts.
First off, your understanding of what you get from Spring is about right. So let's get on to your third question, the interesting one.
The key is it's not that you don't have singletons, it's that they're singletons by configuration. This is a vital difference, as it means you can avoid all the complicated singleton enforcement code (the source of frequent problems) and instead just write exceptionally simple programs that focus on the business end of things. This is particularly important when you are writing a program with non-trivial object lifetimes: for example, in a webapp it makes it very easy to manage the lifespan of objects that hold state associated with a user's session, since if the objects have session scope, they'll be “singleton per user session”. That's enormously easier to work with than many of the alternatives.
The fact that Spring can also help out with transactions is just perfect as transaction handling is distinctly non-trivial, and AOP is the best solution to them in Java that I've seen (other languages have other options open) with Spring supporting a pretty straight-forward way of doing it. Try to do it properly without if you don't believe me. Spring's pretty much wonderful.