I'm trying to override this bean which is provided by standard Hybris (OOTB) framework. I would love to override it so it uses my own custom class. Is this possible?
You can create new extended abstract class but it is not used by existing classes. You can use customize functionality to overwrite class and/or spring config. Bu you must careful during patching or updating system.
How to override hybris platform files other than customize
Do you want to inject a custom implementation for one of the properties mapped to the abstract bean definition or do you want the abstract bean to use a custom class that you provide?
The latter just doesnt work, because you would also break all configurations of implementing beans.
You should seek for all beans that use this abstract bean as a parent and think, which of those you want to change and change that. Most likely, those beans will have an alias defined that you can use to change it. :-)
Best Bechte
Related
I have a simple Quarkus resource:
#Path("/rosters")
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public class RosterResource {
private final RosterService rosterService;
public RosterResource(RosterService rosterService){
this.rosterService = rosterService;
}
#GET
#Path("/{rosterId}")
public Response getRoster(#PathParam("rosterId")Long rosterId){
return Response.ok(rosterService.getRosterById(rosterId)).build();
}
}
I am trying to inject the RosterServiceinstance in my resource, but I am getting a javax.enterprise.inject.UnsatisfiedResolutionException. However, if I use the #ApplicationScoped annotation on RosterService, then everything works just fine. Is there a way of injecting the RosterService class in my resource without using annotations? In other words, is there a way of making RosterService discoverable by the Quarkus container without directly annotating the class?
Edit: looking into the CDI docs, it seems that you can manually register beans using a method with a #BuildStep annotation. However, it is not clear to me which class should contain the annotated method)
Another option would be to use a Jandex index
To the best of my knowledge, Quarkus only implements so called annotated bean discovery. That means that all CDI beans in Quarkus have to have a bean defining annotation. #ApplicationScoped is one of them.
EDIT: regarding a Jandex index, that allows you to scan for beans in additional JARs. In other words, it will only expand the set of classes that are scanned for a bean defining annotation.
When it comes to a #BuildStep method -- that is only possible in a Quarkus extension. Extensions are powerful (and indeed they can define additional beans) but also complex. You can start at https://quarkus.io/guides/building-my-first-extension, but it may feel overwhelming. It may also feel like this is not the right thing to do if you want to just make your class a bean -- and that would be true. But if your class comes from an external library that you can't change, extension makes sense.
Is there a specific reason why you don't want to annotate your service class with #ApplicationScoped (or any other of the bean discover/scope annotations)?
The only other way that I'm aware of (instead of annotations) is - as you yourself mentioned - the use of Jandex index.
I have a custom object which I like to share between different Spring-Boot components (e.g. WebHandler, Authenticator, Filter).
Maybe the easiest way is a static object in the main-class but thats not very elegant.
Whats the most common way to do it?
The whole point of spring as a container is to manage your objects.
Now statics do not have a well defined lifecycle ( when exactly this object gets created, who disposes it when the application gets closed, etc)
Speing answers all these questions by using thecdependency injection techniques. If you're already using spring then you should define this 'shared object' as a spring bean (by default it will have scope singleton just like static object that you've proposed but managed by spring container which is better - it will manage the lifecycle of the object by itself)
Then given the classes that must be dependent of the object are beans by themselves you can inject that bean:
class MySharedObject {}
class MyWebHandler implementsWebHandler {
private final MySharedObject mySharedObject;
public MyWebHandler(MySharedObject mySharedObject) {
this.mySharedObject = mySharedObject;
In addition to the lifecycle management this way allows easy unit testing of classes that use the shared object (like 'MyWebHandler' in this case) - now uou can create a stub/mock of the shared object and pass it into the handler - something that cannot really be easily done when using statics
So in summary if you can use spring and define it as a bean - by all means do so, the usage of statics is discouraged if you already have a dependency injection container
If you have shared object first of all it should not contain any state as differents components can change it and also it should be thread safe.
It is fine to reuse it across all components via #Autowired annotation but you need to be sure that it is threadsafe. Spring bean scope singleton is not thread safe out of box it dependes how you write the code.
You can use as static method but it dependes on logic which you have and if those component has an dependency on another objects and if they need to in spring IOC.
Im trying to upgrade my project from spring-boot-1.4.3.RELEASE to spring-boot-1.5.9.RELEASE.
In the 1.4.3.RELEASE the way I have used my custom implementation of repositories is as follow:
Made an interface MyCustomRepositroy that extends JpaRepository
Had a class MyCustomRepositoryImpl that implements MyCustomRepositroy and SimpleJpaRepository. In that class I have changed the behavior of
the of save, find and delete methods, because I needed a
ceratin behavior for entitys of certain type (lets say that I need a
custom save for all entitys that implements Special interface)
I made a MyCustomJpaRepositoryFactoryBean that extends JpaRepositoryFactoryBean. In that factory, I've overridden createRepositoryFactory and gave it my MyRepositoryFactory implementation.
In MyRepositoryFactory implementation I've overridden the getTargetRepository, and getRepositoryBaseClass.In these methods, I check if the entity is of type Special, and if so, I return MyCustomRepositoryImpl, otherwise I return SimpleJpaRepository.
Also, I can get the beanFactory in my MyCustomRepositoryImpl class because I call my own constructor of MyCustomRepositoryImpl that has also a beanFactory parameter via getTargetRepositoryViaReflection.
Now, with the new version (that uses spring-data-commons-1.13.9.RELEASE), I cannot override the Factory class, and hence can't decide for each entitiy which implementation to give, and have no way to get the beanFactory.
Is there any way I can get what I want?
Sorry for the mess, but I cannot post my code here.
P.S - my project is a spring based library, so I can't do anything to the entitys because my clients declare them, all I know that some entitys implement the Special interface and some don't
I am trying to figure out what happened in 1.5.9.RELEASE, but in the meantime, just as a fyi - 1.5.6.RELEASE works ok.
I am having the same issue when trying to update from 1.5.6.RELEASE to 1.5.9.RELEASE
I am extending my model class to WCMUse class to write my business logic. I have osgi configuration which has couple of properties. I want to read one of the property in my model class. I am not sure how to get the handle of osgi configuration in WCMUse class. Any pointers will be highly appreciated.
Adding the answer for future references.
You can use the #getSlingScriptHelper() method of the WCMUse class to get an handle of the SlingScriptHelper. This is the same sling object that is available through inclusion of global.jsp in traditional JSP scripts.
You can then call #getService() method of the SlingScriptHelper to look up the desired OSGi Service.
The following code snippet can be used in the model to get the service configuration
getSlingScriptHelper().getService(<<Configuration Service>>.class)
Does it makes sense in Spring to use #Autowired to wire directly to a concrete class and not to an interface (and make use of 'by type' autowiring)
If a class doesn't implements an interface wouldn't it be better to instantiate it via constructor or a factory (keeping things simple); rather than make it a Spring bean just for the heck of it.
Does it makes sense in Spring to use #Autowired to wire directly to a concrete class and not to an interface
Sure. The practice of autowiring is independent of what you're autowiring. It'll work with classes just as well as interfaces.
However, whether or not it's a good idea is debatable, although this is a more general question of whether you should always introduce an interface for a given class, rather than talk directly to the class type. The benefits include easier unit-testing and a cleaner design, at the expense of code clutter.
There's another good reason to autowire interface types rather than class types, which is that if Spring needs to generate a proxy object around the bean before injecting it, then if the bean's class defines any interfaces, then the proxy will implement those interfaces, and will not be type-compatible with the bean class itself. If you then try and autowire that bean by class type, it will fail. The easiest way to avoid this annoying scenario is to always autowire by interface type, that way it will lways work as you expect.
and make use of 'by type' autowiring
If you mean container-level byType autowiring, then you don't want to do that. It's the old Spring 1.x style of autowiring, and it's highly inflexibile (see limitations of autowiring).
Stick with #Autowired, it's much more flexible and easier to control.
If a class doesn't implements an interface wouldn't it be better to instantiate it via constructor or a factory (keeping things simple); rather than make it a Spring bean just for the heck of it.
The two questions are completely separate. An object should be made a Spring bean if you need Spring to control its dependencies and lifecycle, regardless of whether or not it implements interfaces. If you find that the object has no dependencies, and no meaningful interface, then perhaps there is no reason to make it a bean.
You will have to decide if hardwiring this dependency into other classes is ok. For instance, how many different classes are likely to require this dependency? If the answer is many then you will be creating many instances of this class where only one is required.
Also, what dependancies does this concrete class have? You will have to configure those inside the class that depends on it.
The object of dependency injection is to reduce the dependencies between classes and make your code loosely coupled.