The crux of my problem is how to type a property to expose the methods from two different interfaces, when the property will be injected with a Spring Batch proxy.
My design problem is concerning how to inject a dependency that Spring has proxied for use in Spring Batch. The dependency is proxied by Spring because it has been scoped to the Spring Batch step. This is required because the dependency has values that must be injected from the Spring Batch Job Parameters. Scoping the bean to the Spring Batch step is the best way to make the dependency available in the ExecutionContext so that the Job Parameters can be injected. Any input in how to resolve this would be very much appreciated.
My specific situation is in implementing an AggregateItemReader in Spring Batch as explained in the Spring Batch Samples. You can find a the source for the example AggregateItemReader here and the javadoc.
The difference is my implementation intends to use the JdbcCursorItemReader to aggregate from. This means that my AggregateItemReader must implement the interfaces ItemReader and ItemStream. This allows my AggregateItemReader to be used properly by Spring Batch by exposing the open(ExecutionContext executionContext), update(ExecutionContext executionContext), and close() methods needed by Spring Batch to manage the ItemStream. In addition, the property in my AggregateItemReader that stores a reference to the ItemReader that handles the data loading must provide access to these same methods. So the property is typed to the JdbcCursorItemReader. This introduces a problem as the proxy Spring Batch creates is baed on the dependency's interfaces, ItemReader and ItemStream. A proxy of these types can't be injected into a property typed to JdbcCursorItemReader.
Related
I'm new to Spring and a little confused about how it works. I get that I can use the application context to instantiate beans and have them populated. However, is the idea that I should be able to just write Bean b = new Bean() and then have Spring to somehow automagically populate that Bean?
I'm experimenting with Spring in a web application, and as far as I can see I need to inject the ApplicationContext into, say, the servlets to be able to instantiate other beans (services, daos etc.) from there. It's a bit cumbersome, but probably works.
However, is Spring meant to be able to hook into any object instantiation which happens on classes defined as beans in applicationContext.xml?
Spring is an Inversion of Control container. A bean is an object whose life cycle is managed by Spring. If you want Spring to populate an object, it needs to go through Spring, ie. it needs to be bean.
is Spring meant to be able to hook into any object instantiation
which happens on classes defined as beans in applicationContext.xml?
Spring doesn't hook into anything. You configure your beans and the relationships between them with Spring and Spring handles creating the instances and linking them up.
For domain objects, Spring provides a solution via the #Configurable annotation: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#aop-atconfigurable
It requires compile- or load-time-weaving and, thus, introduces some additional complexity but having the convenience of using the standard new Bean() syntax plus Spring's autowiring is worth it in my opinion.
Alternatively, you could define your domain objects as beans with prototype scope and use some factory to create them using the Spring ApplicationContext.getBean() method. With a scope of prototype a new instance will be returned every time and since you go through the ApplicationContext, Spring will do all the dependency injection magic as usual.
As for services and other beans with singleton scope, you would typically NOT retrieve them by first injecting the ApplicationContext and using it but instead you would inject them via either a constructor, setter or annotation-based strategy. The documentation covers that in detail: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#beans-factory-collaborators
Definitely need some expert help with this! I think this is mainly a Spring Security question, but as I don't know for sure, so I am also tagging with the general Spring tag!
When the Application Context is loaded (mine is all via Java Config, though I don't believe that matters), the "DefaultListableBeanFactory" is processed and eventually (via the ProxyFactory) Spring Security Advisors are added. This is great when I have Spring Beans as I have Permissions that need authorization.
My question is: how do I get the same effect when I no longer require those classes to be Spring Beans? Said differently, if I have an object instance created as a singleton bean via Java Config and the authorization is working correctly, is it possible to maintain that with the object instance being a POJO? Again, for the experts, I want the interception chain returned in the JdkDynamicAopProxy to contain the Spring Security interceptors.
And "no", I am not really expecting an answer to this, maybe just hoping!!!
To add security interceptors to beans not instantiated by spring container
switch global-security tag to mode aspectj and weave the provided AnnotationSecurityAspect in the aspecj module.
For your second question I suppose that you want to do one of the following:
Use a ProxyFactoryBean to secure a bean.
Create security proxies programmatically: Use ProxyFactory.addAdvice() method.
Add the security interceptor to all proxies created by an AutoProxyCreator: This usually don't needed, but you can use the AbstractAutoProxyCreator.interceptorNames property to add common interceptors. The global-security tag parser uses a generated name for the MethodSecurityInterceptor, so you need to configure the interceptor manually and set a consistent SecurityMetadataSource.
In XML file in spring we have two bean with different id but same class. They have the same properties offcourse. Now I have InitializingBean interface and in afterPropertySet() I am just printing the value of properties.
Its printing the values two times for me?
According Spring Documentation:
afterPropertySet()
Invoked by a BeanFactory after it has set all bean properties supplied (and satisfied BeanFactoryAware and ApplicationContextAware).
So the short answer on your question is: yes
Spring doesn't manipulate classes or object. Spring manipulates Bean Entity. It is the simplest object manipulated by Spring IOC. Bean has additional behaivior rules introduced by Spring.
If you create two beans for example with Singleton scope and not Lazy initializated Spring creates two instances of your class.
Probably you are calling this Class also invoking a Test or by launching a Integration test like this . check the breakpoints , if you are using SpringRunner, try to mock the component
I want to clear some moments about integrating spring and struts. I have only one action class per application extended from MappingDispatchAction. So, actually my app when doing something uses not Action objects, but methods from my action. All I want from spring is to initialize this action and all for now. Just simply set DAO object. I looked through documentation, but I don't understand following:
We use action path from struts-config.xml as a name of bean in action-servlet.xml. Okay, but am I supposed to write beans in action-servlet.xml for every path name and set this poor DAO ref or what ?
The Struts 1 config file will use the DelegatingActionProxy class as the type attribute for all action configurations.
The Spring config file will contain the bean definitions of each action implementation. I don't know what DAO you're talking about, but actions that require DAO or service injection need to have them listed, yes--that's what Spring configuration is.
You may also be able to use annotations if you're not interested in using XML configuration, or use bean inheritance if many beans share the same DAO/service/etc. property values.
In the spring configuration file applicationConfig.xml, the root node is beans.
But it doesn't contain only beans. In fact, security configuration requires an http element.
My question is: while http is not (seems to me not to be) a bean, is it "bean like" in the sense that it determines the creation of a service, or refers to a running service (say the http listener for the application)?
PS. In "Spring Security Reference documentation" 3.1.0-DRAFT at 2.1.1:
"Web/HTTP Security (...) Sets up the filters and related service beans used to apply the framework authentication mechanisms ..."
Yes, everything in a Spring config is just setting up beans. You could--and in fact used to be forced to--set up all the beans yourself, but along about Spring 2.0, the framework added a nifty feature that they called "Extensible XML Authoring", which gives other people/projects a way to define their own, custom XML syntax that gets translated into Spring beans at startup via a NamespaceHandler.