Develop Reference

Used entityManager in command dispatch interceptors

I'm using Axon 4.3 with JPA/Spring.
I want to inject entityManager in my interceptor, so i used ContainerManagedEntityManagerProvider in my configuration. but i have this error when i run my application
Description: Parameter 0 of method configureCommandBus in AxonConfig
required a bean of type
'org.axonframework.springboot.util.jpa.ContainerManagedEntityManagerProvider'
that could not be found.
Action: Consider defining a bean of type
'org.axonframework.springboot.util.jpa.ContainerManagedEntityManagerProvider'
in your configuration.
#Configuration
#AutoConfigureAfter(AxonAutoConfiguration.class)
public class AxonConfig {
#Bean
public CommandBus configureCommandBus(org.axonframework.springboot.util.jpa.ContainerManagedEntityManagerProvider containerManagedEntityManagerProvider) {
CommandBus commandBus = SimpleCommandBus.builder().build();
commandBus.registerDispatchInterceptor(
new CatalogDispatchInterceptor(containerManagedEntityManagerProvider.getEntityManager()));
return commandBus;
}
}
public class CatalogDispatchInterceptor implements MessageDispatchInterceptor<CommandMessage<?>> {
private final EntityManager entityManager;
public CatalogDispatchInterceptor(EntityManager entityManager) {
this.entityManager = entityManager;
}
#Override
public BiFunction<Integer, CommandMessage<?>, CommandMessage<?>> handle(
List<? extends CommandMessage<?>> messages) {
return (index, command) -> {
(CreateCatalogCommand.class.isInstance(command.getPayloadType())) { }
return command;
};
}
}

The ContainerManagedEntityManagerProvider instance created by Axon, if you are using the Spring Boot Starter, through the JpaAutoConfiguration looks as follows:
#Bean
#ConditionalOnMissingBean
public EntityManagerProvider entityManagerProvider() {
return new ContainerManagedEntityManagerProvider();
}
Hence my first try would be to wire in a EntityManagerProvider instead of the ContainerManagedEntityManagerProvider. If that doesn't work, then you're dealing with a Spring bean ordering issue, which is somewhat out of the (axon) framework's scope I think. You could always just create the ContainerManagedEntityManagerProvider yourself of course, which i am pretty certain of will solve the problem at hand.
Hope either solution helps you out Aymen!

How to ask for Prototype bean in Spring service class without applicationContext

I have a component defined with prototype scope. I want to use that component in my service class. I want spring to provide me a new instance of that Bean everytime I call for it.
Component Class:
#Getter
#Setter
#Component
#Scope("prototype")
public class ProtoTypeBean {
//.. Field variables
}
Service Class:
#AllArgsConstructor
#Service
public class ServiceClass {
ProtoTypeBean prototypeBean;
ArrayList<ProtoTypeBean> prototypeBeans;
public void demoMethod(ArrayList<String> someArrayList) {
for(var singleString: someArrayList) {
prototypeBean.setFieldValue(singleString);
prototypeBeans.add(prototypeBean);
}
System.out.println(prototypeBeans.toString());
}
}
By using this configuration, I am getting the same instance of ProtoTypeBean in my prototypeBeans ArrayList. The question is, how would I make Spring understand to give me a new instance of prototypeBean every time I am calling it into the foreach loop?
I found I can use ApplicationContext.getBean() to get a new instance of the Bean in foreach loop but I also heard that it's a bad practice. So kindly help me with the best practice.

Use an ObjectProvider to lazily get the result you want. However the first prototype scoped bean will not be represented in the list of beans as, well they are prototype scoped.
#AllArgsConstructor
#Service
public class ServiceClass {
private final ObjectProvider<ProtoTypeBean> provider;
public void demoMethod(ArrayList<String> someArrayList) {
PrototypeBean pb = provider.getIfUnique();
for(var singleString: someArrayList) {
pb.setFieldValue(singleString);
pb.add(prototypeBean);
}
System.out.println(prototypeBean.toString());
}
}
Also if you don't need all the dependency injection, proxy creation etc. for your object then why bother. There is nothing wrong with just the new keyword in a Spring application. Not everything has to be managed by Spring.

Set up your prototype bean similar to this:
#Getter
#Setter
#Component
#Scope("prototype")
public class ProtoTypeBean {
final private String param;
public ProtoTypeBean(final String p) {
this.param = p;
}
}
Now, in your service class use a BeanFactory to create the beans for you:
#Service
#AllArgsConstructor
public class ServiceClass {
private final BeanFactory factory;
private List<ProtoTypeBean> prototypeBeans;
#Autowired
public ServiceClass(final BeanFactory f) {
this.factory = f;
}
public void demoMethod(List<String> someArrayList) {
this.prototypeBeans = someArrayList
.stream()
.map(param -> factory.getBean(ProtoTypeBean.class, param))
.collect(Collectors.toList());
}
}

I came across this issue recently. I am sure there must be a better way than mine, but this is how I did it:
public class ServiceClass {
ArrayList<ProtoTypeBean> prototypeBeans = new ArrayList<>();
#Autowired
ApplicationContext ctx;
public void demoMethod(ArrayList<String> someArrayList) {
for(var singleString: someArrayList) {
//magic is in below line.. getting a bean from ApplicatioContext.
ProtoTypeBean prototypeBean= ctx.getBean("protoTypeBean"); //Or ctx.getBean(ProtoTypeBean.class);
prototypeBean.setFieldValue(qBean.getFieldValue());
prototypeBeans.add(prototypeBean);
}
System.out.println(prototypeBeans.toString());
}
This way, Spring container always give you a new instance. And it is totally managed by Spring container.
The way you tried it, I tried that as well, but it would always inject one instance at the time of autowiring, hence defeating the purpose of prototyping.
You could have gone the route of using new Keyword. But then that is just regular Java instantiation and I think that new instance is not managed by Spring because it is annotated with #Component instead of #Configuration. I could be wrong here though.

Parameter 0 of constructor in ..... Spring Boot

I have a problem when launch my app. Could somebody help me to solve this issue?
Parameter 0 of constructor in com.journaldev.elasticsearch.service.BookServiceImpl required a bean of type 'com.journaldev.elasticsearch.dao.search.BookRepositorySearch' that could not be found.
Action:
Consider defining a bean of type 'com.journaldev.elasticsearch.dao.search.BookRepositorySearch' in your configuration.
GenericRepository
public interface GenericRepository<T, K> {
Map<String, Object> get(final K id);
}
GenericRepositoryImpl
public class GenericRepositoryImpl<T, K extends Serializable> implements GenericRepository<T, K> {
private RestHighLevelClient restHighLevelClient;
private ObjectMapper objectMapper;
public GenericRepositoryImpl(ObjectMapper objectMapper, RestHighLevelClient restHighLevelClient) {
this.objectMapper = objectMapper;
this.restHighLevelClient = restHighLevelClient;
}
#Override
public Map<String, Object> get(K id) {
return null;
}
}
BookRepositorySearch
#Component
public interface BookRepositorySearch extends GenericRepository<Book, Long> {}
BookService
public interface BookService {
Map<String, Object> get(final Long id);
}
BookServiceImpl
#Service
public class BookServiceImpl implements BookService {
private final BookRepositorySearch bookRepositorySearch;
public BookServiceImpl(BookRepositorySearch bookRepositorySearch) {
this.bookRepositorySearch = bookRepositorySearch;
}
#Override
public Map<String, Object> get(Long id) {
return null;
}
}

From your previous comments, looks like you want to keep BookRepositorySearch as an interface. If that's the case, you need to create a concrete instance of that interface and put #Component on that.
You don't need #Component on your interface declaration and you can't extend a class in an interface.
public interface BookRepositorySearch {}
Create a concrete type that implements the interface and extends extends GenericRepository<Book, Long> you want to autowire and put #Component on it:
#Component
public class BookRepositorySearchImpl
implements BookRepositorySearch
extends GenericRepository<Book, Long>
{}
https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-factory-class-ctor
Instantiation with a constructor
When you create a bean by the
constructor approach, all normal classes are usable by and compatible
with Spring. That is, the class being developed does not need to
implement any specific interfaces or to be coded in a specific
fashion. Simply specifying the bean class should suffice. However,
depending on what type of IoC you use for that specific bean, you may
need a default (empty) constructor.
The Spring IoC container can manage virtually any class you want it to
manage; it is not limited to managing true JavaBeans. Most Spring
users prefer actual JavaBeans with only a default (no-argument)
constructor and appropriate setters and getters modeled after the
properties in the container. You can also have more exotic
non-bean-style classes in your container. If, for example, you need to
use a legacy connection pool that absolutely does not adhere to the
JavaBean specification, Spring can manage it as well.

I solved it with this configuration.
Look for #EnableAutoConfiguration in your Configuration file.
#Configuration
#EnableJpaRepositories(basePackages = "com.akog02.repostories")
#EntityScan(basePackages = "com.akog02.domain")
#EnableTransactionManagement
#EnableAutoConfiguration
public class WebConfiguration {
}

First of, You need to "tell" spring what to pass as a parameter. The simplest option is the one mentioned by #Berger in a comment. If for some reason that is not a good approach for you (eg. BookRepositorySearch is not a spring managed bean), you can make a java config file with some more logic:
#Configuration
public class Config {
// you can use #Autowired here
#Bean
public BookService bookService() {
return new BookServiceImpl(--pass your parameter here, get it however you want--)
}
}
edit:
Apparently Spring doesn't require #Autowired anymore (thanks #Mark Rotteveel).
So the problem is that spring doesn't have an instance of your class. The reason for that is (I think) that you use a class parameter instead of an interface. If You just create a marker interface that BookRepositorySearch implements and use that as an argument instead of the actual inplementation, I would expect it to work.
Another solution is what I wrote above already, but for the BookRepositorySearch class.
#Configuration
public class Config {
// you can use #Autowired here
#Bean
public BookRepositorySearch bookRepositorySearch () {
return new BookRepositorySearch();
}
}
This way Spring will have it's beloved instance ;)

How do you inherit a class as an interface?
#Component
public interface BookRepositorySearch extends GenericRepository<Book, Long> {}
Change this interface with a class then try again.
#Component
public class BookRepositorySearch extends GenericRepository<Book, Long> {}

You must add #EnableJpaRepositories("org.tennis.Tennnis.dao") in Prin

Autowired gives Null value in Custom Constraint validator

I am totally new to Spring and I have looked in to a few answers on SO for the asked problem. Here are the links:
Spring 3.1 Autowiring does not work inside custom constraint validator
Autowiring a service into a validator
Autowired Repository is Null in Custom Constraint Validator
I have a Spring project in which I want to use Hibernate Validator for an object validation. Based on what I read online and a few forums I tried to inject validator as follows:
#Bean
public Validator validator() {
return new LocalValidatorFactoryBean().getValidator();
}
But wherever I was using
#Autowired
Validator validator;
It was taking Spring's validator implementation instead of the Hibernate's validator. I couldn't figure out how to exactly inject Hibernate validator and simply Autowire it across other classes so I used a cheap trick, now my Java Config looks like this
#Bean
public Validator validator() {
// ValidatorImpl is Hibernate's implementation of the Validator
return new ValidatorImpl();
}
(I would really appreciate if someone can actually point me into the right direction on how to avoid getting Hibernate Validator in this Hacky way)
But lets come to the main issue here:
Here is custom validation definition
#Target( { METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER } )
#Retention(RUNTIME)
#Constraint(validatedBy = EmployeeValidator.class)
#Documented
public #interface EmployeeValidation {
String message() default "{constraints.employeeConstraints}";
public abstract Class<?>[] groups() default {};
public abstract Class<? extends Payload>[] payload() default {};
}
My Custom Validator
public class EmployeeValidator implements ConstraintValidator<EmployeeValidation , Object> {
#Autowired
private EmployeeService employeeService;
#Override
public void initialize(EmployeeValidation constraintAnnotation) {
//do Something
}
#Override
public boolean isValid(String type, ConstraintValidatorContext context) {
return false;
}
}
In the above Custom Constraint Validator I get the employeeService null. I know that any implementations of ConstraintValidator are not instantiated when Spring is starting up but I thought adding the ValidatorImpl() will actually fix that. But it didn't.
Now I am stuck with a really hacky workaround and I do not want to continue with a code like that. Can someone please help me with my situation.
P.S. These are my imports in the Java Config file:
import org.hibernate.validator.HibernateValidator;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.MessageSource;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
import org.springframework.context.support.ReloadableResourceBundleMessageSource;
import org.springframework.core.env.Environment;
import org.springframework.validation.Validator;
import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean;
import org.springframework.web.servlet.LocaleResolver;
import org.springframework.web.servlet.ViewResolver;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport;
import org.springframework.web.servlet.i18n.CookieLocaleResolver;
import org.springframework.web.servlet.i18n.LocaleChangeInterceptor;
import org.springframework.web.servlet.view.InternalResourceViewResolver;

I hope the solution will help someone:
#Bean
public Validator validator () {
ValidatorFactory validatorFactory = Validation.byProvider( HibernateValidator.class )
.configure().constraintValidatorFactory(new SpringConstraintValidatorFactory(autowireCapableBeanFactory))
.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();
return validator;
}
Initializing the validator with SpringConstraintValidatorFactory so that injection works and providing the validator implementation to be Hibernate.class works in the following manner:
Your objects will be validated by the library of your choice
Your custom validators will be able to use Spring's functionality while having validation to be executed by Hibernate.
How it works:
Hibernate's ConstraintValidatorFactory does not initialize any ConstraintValidators unless they are called but SpringConstraintValidatorFactory does by giving AutowireCapableBeanFactory to it.
EDIT
As mentioned in one of the comments by #shabyasaschi To inject autowireCapableBeanFactory you can change the method signature as:
Validator validator(final AutowireCapableBeanFactory autowireCapableBeanFactory) {
or add getter and setter for it in the config file as follows:
public AutowireCapableBeanFactory getAutowireCapableBeanFactory() {
return autowireCapableBeanFactory;
}
public void setAutowireCapableBeanFactory(AutowireCapableBeanFactory autowireCapableBeanFactory) {
this.autowireCapableBeanFactory = autowireCapableBeanFactory;
}

You can fix this with two aproaches:
Try to inject Services on your validator using Spring.
Initialize it manually overriding Validator's initialize method.
I had the same problem time ago and finally i decided to use second option avoiding tons of problems.
As you point you must define one initialize method on your validator and there you can use a ServiceUtils to get the service bean you need:
#Autowired
private EmployeeService employeeService;
#Override
public void initialize(EmployeeValidation constraintAnnotation) {
//Use an utility service to get Spring beans
employeeService = ServiceUtils.getEmployeeService();
}
And ServiceUtils is a normal Spring bean with a static reference to itself used in the static methods.
#Component
public class ServiceUtils {
private static ServiceUtils instance;
#Autowired
private EmployeeService employeeService;
/* Post constructor */
#PostConstruct
public void fillInstance() {
instance = this;
}
/*static methods */
public static EmployeeService getEmployeeService) {
return instance.employeeService;
}
}
So you are using Spring to inject the services you need but not in the usual way.
Hope this helps.

In your bean definition
#Bean
public Validator validator() {
return new LocalValidatorFactoryBean().getValidator();
}
What's the type of Validator in the method definition? You should make sure it returns javax.validation.Validator, not Validator from Spring.
Letting Spring bootstrap the validator will it also cause to pass a SpringConstraintValidatorFactory to Hibernate Validator which will enable dependency injection within constraint validators.

There is nothing wrong with your code It depends how are you creating your ValidatorFactory.
Create a bean and let Spring handle it.
#Bean
public ValidatorFactory validatorFactory(){
return Validation.buildDefaultValidatorFactory();
}

Think about it. There should have been no issue with using the #Autowired inside a Constraint validator class. This means that something is wrong.
This issue has been reported on various platform and I have not seen a good solution. I have seen some workaround though.
Here is what I found.
You may notice that the validation is happening twice. the first time it should work but the second time you got a null related error message. The problem should be that the entity or the class that you is being validated is being used twice in your controller. For example, you may want validate the entity class and try to save it at the same time in the same method in the controller method. when you try to save the entity, it will try to validate the object again and this time the #Autowired object will be null.
Here is what you can do for this scenario
You can use dto to carry the validation annotation and copy the property of the dto class to your entity class before you save it into the database. your scenario may be different but the solution approach should be the same.
Below is an illustration of code that works
public ResponseEntity<InstitutionModel> create(#Valid #RequestBody InstitutionDto institutiondto) {
Institution institution = new Institution();
BeanUtils.copyProperties(institutiondto, institution);
return Optional.of(this.institutionService.save(institution)).map(institutionModelAssembler::toModel)
.map(ResponseEntity::ok).orElse(ResponseEntity.notFound().build());
}

private XXXService xxxService = SpringContextHolder.getBean(XXXService.class);

Thats worked for me. For guys who search at now
public class EmployeeValidator implements ConstraintValidator<EmployeeValidation , Object> {
private EmployeeService employeeService;
public EmployeeValidator(EmployeeService employeeService){
this.employeeService = employeeService;
}
...
}

Spring 3.2 Autowire generic types

So I have a number of generics in Spring 3.2 and ideally my architecture would look something like this.
class GenericDao<T>{}
class GenericService<T, T_DAO extends GenericDao<T>>
{
// FAILS
#Autowired
T_DAO;
}
#Component
class Foo{}
#Repository
class FooDao extends GenericDao<Foo>{}
#Service
FooService extends GenericService<Foo, FooDao>{}
Unfortunately with multiple implementations of the generics the autowiring throws an error about multiple matching bean definitions. I assume this is because #Autowired processes before type erasure. Every solution I've found or come up with looks ugly to me or just inexplicably refuses to work. What is the best way around this problem?

How about adding a constructor to the GenericService and move the autowiring to the extending class, e.g.
class GenericService<T, T_DAO extends GenericDao<T>> {
private final T_DAO tDao;
GenericService(T_DAO tDao) {
this.tDao = tDao;
}
}
#Service
FooService extends GenericService<Foo, FooDao> {
#Autowired
FooService(FooDao fooDao) {
super(fooDao);
}
}
Update:
As of Spring 4.0 RC1, it is possible to autowire based on generic type, which means that you can write a generic service like
class GenericService<T, T_DAO extends GenericDao<T>> {
#Autowired
private T_DAO tDao;
}
and create multiple different Spring beans of it like:
#Service
class FooService extends GenericService<Foo, FooDao> {
}

Here is a closest solution. The specialized DAOs are annotated at the business layer. As in the question from OP, the best effort would be having an annotated DAO in the EntityDAO generic template itself. Type erasure seems to be not allowing the specialized type information to get passed onto the spring factories [resulting in reporting matching beans from all the specialized DAOs]
The Generic Entity DAO template
public class EntityDAO<T>
{
#Autowired
SessionFactory factory;
public Session getCurrentSession()
{
return factory.getCurrentSession();
}
public void create(T record)
{
getCurrentSession().save(record);
}
public void update(T record)
{
getCurrentSession().update(record);
}
public void delete(T record)
{
getCurrentSession().delete(record);
}
public void persist(T record)
{
getCurrentSession().saveOrUpdate(record);
}
public T get(Class<T> clazz, Integer id)
{
return (T) getCurrentSession().get(clazz, id);
}
}
The Generic Entity Based Business Layer Template
public abstract class EntityBusinessService<T>
implements Serializable
{
public abstract EntityDAO<T> getDAO();
//Rest of code.
}
An Example Specialized Entity DAO
#Transactional
#Repository
public class UserDAO
extends EntityDAO<User>
{
}
An Example Specialized Entity Business Class
#Transactional
#Service
#Scope("prototype")
public class UserBusinessService
extends EntityBusinessService<User>
{
#Autowired
UserDAO dao;
#Override
public EntityDAO<User> getDAO()
{
return dao;
}
//Rest of code
}

You can remove the #autowire annotation and perform delayed “autowire” using #PostConstruct and ServiceLocatorFactoryBean.
Your GenericService will look similar to this
public class GenericService<T, T_DAO extends GenericDao<T>>{
#Autowired
private DaoLocator daoLocatorFactoryBean;
//No need to autowried, autowireDao() will do this for you
T_DAO dao;
#SuppressWarnings("unchecked")
#PostConstruct
protected void autowireDao(){
//Read the actual class at run time
final Type type;
type = ((ParameterizedType) getClass().getGenericSuperclass())
.getActualTypeArguments()[1];
//figure out the class of the fully qualified class name
//this way you can know the bean name to look for
final String typeClass = type.toString();
String daoName = typeClass.substring(typeClass.lastIndexOf('.')+1
,typeClass.length());
daoName = Character.toLowerCase(daoName.charAt(0)) + daoName.substring(1);
this.dao = (T_DAO) daoLocatorFactoryBean.lookup(daoName);
}
daoLocatorFactoryBean does the magic for you.
In order to use it you need to add an interface similar to the one below:
public interface DaoLocator {
public GenericDao<?> lookup(String serviceName);
}
You need to add the following snippet to your applicationContext.xml
<bean id="daoLocatorFactoryBean"
class="org.springframework.beans.factory.config.ServiceLocatorFactoryBean">
<property name="serviceLocatorInterface"
value="org.haim.springframwork.stackoverflow.DaoLocator" />
</bean>
This is a nice trick and it will save you little boilerplate classes.
B.T.W I do not see this boilerplate code as a big issue and the project I working for uses matsev approach.

Why do you want a generic service ? Service classes are meant for specific units of work involving multple entities. You can just inject a repository straight into a controller.
Here is an example of generic repository with constructor argument, you could also make each method Generic instead and have no constructor argument. But each method call would require class as parameter:
public class DomainRepository<T> {
#Resource(name = "sessionFactory")
protected SessionFactory sessionFactory;
public DomainRepository(Class genericType) {
this.genericType = genericType;
}
#Transactional(readOnly = true)
public T get(final long id) {
return (T) sessionFactory.getCurrentSession().get(genericType, id);
}
Example of bean definition for the generic repository - you could have multple different beans, using different contstructor args.
<bean id="tagRepository" class="com.yourcompnay.data.DomainRepository">
<constructor-arg value="com.yourcompnay.domain.Tag"/>
</bean>
Depdncy injection of bean using resource annotation
#Resource(name = "tagRepository")
private DomainRepository<Tag> tagRepository;
And this allows the Domainreposiroty to be subclassed for specific entities/methods, which woul dallow autowiring :
public class PersonRepository extends DomainRepository<Person> {
public PersonRepository(){
super(Person.class);
}
...

You should use autowiring in classes which extends these generics

For this question one needs to understand about what autowire is. In common terms we can say that through autowire we create a object instance/bean at the time of deployment of the web app. So now going with the question if you are declaring autowiring in multiple places with the same name. Then this error comes. Autowiring can be done in multiple ways so if you are using multiple type of autowiring technique, then also one could get this error.

Complete Generic Solution using Spring 4:
Domain Class
#Component
class Foo{
}
#Component
class Bar{
}
DAO Layer
interface GenericDao<T>{
//list of methods
}
class GenericDaoImpl<T> implements GenericDao<T>{
#Autowired
SessionFactory factory;
private Class<T> domainClass; // Get Class Type of <T>
public Session getCurrentSession(){
return factory.getCurrentSession();
}
public DaoImpl() {
this.domainClass = (Class<T>) GenericTypeResolver.resolveTypeArgument(getClass(), DaoImpl.class);
}
//implementation of methods
}
interface FooDao extends GenericDao<Foo>{
//Define extra methods if required
}
interface BarDao extends GenericDao<Bar>{
//Define extra methods if required
}
#Repository
class FooDao extends GenericDaoImpl<Foo> implements FooDao{
//implementation of extra methods
}
#Repository
class BarDao extends GenericDaoImpl<Bar> implements BarDao{
//implementation of extra methods
}
Service Layer
interface GenericService<T>{
//List of methods
}
class GenericServiceImpl<T> implements GenericService<T>{
#Autowire
protected GenericDao<T> dao; //used to access DAO layer
}
class FooService extends GenericService<Foo>{
//Add extra methods of required
}
class BarService extends GenericService<Bar>{
//Add extra methods of required
}
#Service
class FooServiceImpl extends GenericServiceImpl<Foo> implements GenericService<Foo>{
//implementation of extra methods
}
#Service
class BarServiceImpl extends GenericServiceImpl<Bar> implements GenericService<Bar>{
//implementation of extra methods
}