I would like to add extra attribute to the internal representation of beans in Spring. Is it possible? What mechanism should be applied if any?
My goal is to define my own beans for my framework. I can do it from scratch or reuse Spring mechanisms.
You could have a look at the documentation Container Extension Points.
To achieve customization you can create a:
BeanPostProcessor bean which operates on a bean instance. For example this allows to create a custom bean registry, to proxify...
BeanFactoryPostProcessor which can operate on bean metadata. This allows for overriding or adding properties even to eager-initializing beans, modifying the class...
BeanDefinitionRegistryPostProcessor which can operate right after the registry initialization. This allows to create, remove or update beans definitions.
For example you can create a new BeanDefinitionRegistryPostProcessor which will register (or modify) beans using a custom implementation of BeanDefinition which will contain custom attribute based on for example your owns annotation.
Could you elaborate a bit what are you trying to achieve with your framework?
Merci beaucoup, Nicolas :)
I will study both your answer and the documentation you provided. I have already found the *Postprocessors you mentioned but I was not sure if this is the right place and what is the nature of their customizations (subclassing or something different) and what are the consequences. My problem is not as simple as I told (not just adding an attribute) - the extended Spring bean should be used also in cooperation to Spring+AspectJ (not SpringAOP), especially with declare-parents construct. I would like to be able to create proxies for the redefined beans as well. I will let you know what are the results of my investigation and may be I will ask some questions.
And the answer to all of you:
My framework is dedicated to defining graph modeling languages (meta-models) at run-time (being far extension of OMG standards) and I am looking for solutions of limits introduced by current object representation in JVM, which promotes behaviour over structure. This is one of several approaches, but the most prospective for me due to the relatively small effort.
Related
I'am seriously figuring out this for the last one week and continuously keep on reading articles and blogs so that I can understand the difference in the very leman language and terms so that I can understand easily!!!!!
Dependency injection is simply about depending on an abstract interface and passing a concrete implementation of that interface to your class through the constructor or a setter method. This allows you to use a different concrete implementation without changing your class. This is useful, for instance for testing.
IoC is also known as the Hollywood principle: don't call us, we call you. In this case a framework defines an interface and the application provides the concrete implementation. This helps to limit dependencies between classes. IoC is often implemented using dependency injection, but it's not a hard requirement.
I would like to know, whether this is a valid practice to use "new" in spring to create a Object?
You can either use xml->bean to create a object using xml file or use annotations to create a object.
This question arises when I am working on a project and where I want to create a object of a property class(which contains properties and setter/getter method of those properties).
I am able to create a object using new and its working fine but if spring has capability to create and manage object lifecycle then which way I need to go create a object and why?
I think the confusion may arise because of the (over)usage of spring as DI mechanism. Spring is a framework providing many services. Bean or dependency injection is just on of those.
I would say that for POJOs which have just setter and getters without much logic in them you can safely create objects using new keyword. For example, in case of value objects and data classes which do not have much configuration or life cycle events to worry about, go ahead and crate those using new keyword. If you repetitively create these objects and have fields which are not changing often, then I would use spring because it will lessen some of the repetitive code and object creation can be considered externalized or separated from your object usage.
Classes instantiated using spring bean definition xml/annotations are basically 'Spring-Managed' beans which mostly means that their life cycle, scope, etc are managed by spring. Spring manages objects which are beans, which may have some life cycle methods and APIs. These beans are dependencies for the classes in which the are set. The parent objects call some API of these dependencies to fulfil some business cases.
Hope this helps.
The Dependency Injection concept in spring is more useful when we need to construct an object that depends upon many objects, because it saves you time and effort for constructing as well as instantiating dependent objects.
In your case , Since it's a POJO class with only setters and getters , I think it is absolutely safe to instantiate it using a new keyword.
So far, in our project, we have got our beans having the references set through setter injections; recently, couple of people have started to use #Autowired annotation to set the references on their beans; is it a good to mix annotations and xml configurations for context?
There is no problem using the two together but better to choose one for consistency sake. It would be easier for all the developers to understand and maintain the code.
My preference is annotations as I like things defined at one place.
Mixing annotations and XML definitions works pretty well to reduce amount of code in XML file.
Certainly you can have both coexisting; XML definitions will always override any annotations in Java code without causing a trouble.
Is it good or bad?? I think it's just a way to balance size of an XML file. I find very useful to define my beans in a simple way in XML and then just use #Autowire annotation including #Required to ensure bean has been properly injected before been used.
Why do people default to DI vs a global factory with a hashmap that maps interfaces/abstracts to classes? It would seem this is a higher performance solution to the problem no?
All the things mentioned so far in this thread can be provided by a global factory with a method like:
TestGlobalFactory implements GlobalFactoryI
ProductionGlobalFactory implements GlobalFactoryI //configures classes to interfaces
protected GlobalFactoryI gf=GlobalFactoryFactory.getInstance(); //only singleton used in app, specifies which GlobalFactory to use
protected SportsCarI mySportsCar=gf.new("sportsCarI",constructorVar1,constructorVar2);
The above would be much faster than recursive reflection to detect DI instances.
However I admittedly prefer the convention of DI as it ends up being fewer characters and greater flexibility with the option of third party containers.
artima.com/forums/flat.jsp?forum=106&thread=238700
Regardless DI, is the superior approach as it has the containers written to specify which implementation belongs in which class. With Service Locator one would actually have to do gf.new("thisClass","sportsCarI",constructor1)
The main advantage of dependency injection over a factory-based approach is not performance. Its main advantage is testability. The whole point of DI is to be able to inject mock dependencies to implement the unit tests of a component. Doing it with a factory is much more painful.
Because you get a lot more with Spring. Spring manages the lifecycle of its beans, in addition to caching instances in line with the user specified scope for the beans (e.g. prototype, singleton, etc). Also note that Spring's DI is related to its "Inversion of Control", so things are not hard coded directly into the app (unless you consider configuration code).
Our app has a requirement to support multi-tenancy. Each of the boarded customer might potentially override 1 or more beans or some properties of a bean defined at the core platform level (common code/definitions). I am wondering what is the best way to handle this.
Spring allows you to redefine the same bean name multiple times, and takes the last bean definition processed for a given name to be the one that wins. So for example, your could have an XML file defining your core beans, and import that in a client-specific XML file, which also redefines some of those beans. It's a bit fragile, though, since there's no mechanism to specifically say "this bean definition is an override".
I've found that the cleanest way to handle this is using the new #Bean-syntax introduced in Spring 3. Rather than defining beans as XML, you define them in Java. So your core beans would be defined in one #Bean-annotated class, and your client configs would subclass that, and override the appropriate beans. This allows you to use standard java #Override annotations, explicitly indicating that a given bean definition is being overridden.