Wicket has this device called a lazy proxy factory. Given:
<property name="foo" ref="beanx"/>
the idea is to auto-generate a proxy in place of 'beanx', and then only initialize beanx if and when something actually calls a method on it.
It seems as if this might be a core Spring capability. Is it there somewhere?
See LazyInitTargetSource; that might do what you want. It requires use of lazy-init="true" on the target bean as well, though.
Spring singleton beans, the closest thing to what you want, are created when the spring context is initialized: http://static.springsource.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes. So I believe the short answer is "no." You can implement your own scope to do this by extending the Spring classes quite easily, though.
Spring session/request scope is implemented using the technique you describe, but it is only intended to handle transitions between scope cardinalities, not instance creation. So spring uses the same concepts, but you'd probably have to create your own implementation.
Related
I am developing Spring MVC app, i need to implement singleton pattern for some kind of utilities, ex: imageuploader and others.
My question is: in what way to implement singleton for this utilities, to initialize beans for these classes and inject where i need like Controllers, Services, DAO?, or to use static field implementation of singleton to keep instance of this class?
First, try to avoid singleton as it's considered to be a bad practice. Also their interactions with other instances are difficult to test and validate, compared to non-singleton instances.
If you absolutely need it, I'd suggest you use a Spring bean so you can exploit the autowiring mechanism and Spring's bean lifecycle.
See the Beans section of the Spring reference doc for more info.
Using a Spring bean as will allow you to easily inject a mock in unit tests. However, you will only be able to access it from other Spring beans (or objects created by Spring beans that pass in a reference to it).
Also see this discussion in this question: Difference between static class and singleton pattern?
Traditionally, you'd use PropertyPlaceholderConfigurer to inject config from properties files into a Spring web-app. This blog discusses a variety of newer ways to do this with Spring.
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.
I've been looking into using EasyMock 3's IMockBuilder as a means of generating partial mocks (I know partial mocking may suggest a design flaw, but I'm writing tests for old code). Presumably I can use the deprecated static EasyMock.createMock() methods to create beans in my Spring config, like this:
<bean id="myBean" class="org.easymock.EasyMock" factory-method="createMock">
<constructor-arg value="org.mypackage.MyClass.class" />
</bean>
When creating a partial mock using an IMockBuilder, I need to make several calls to addMockedMethod() in order to define the methods I want mocked. Is there a way I can do this in a Spring XML configuration file? Ideally I'd like all the dependencies of all my beans set by Spring, and don't want to have to override them in my test cases in order to pass in mock objects created in this way.
Thanks
No, XML config isn't capable of that sort of flexibility.
You have two options:
Write an implementation of FactoryBean which creates the mock, configures it, and returns the mock to Spring. See Customizing instantiation logic with the FactoryBean Interface.
Use #Configuration-style configuration in Java, instead of XML style configuration. This is the most flexible approach, and is generally better than XML config. See Java-based container configuration
I want to convert some of our internal API into a spring bean spring interceptor that we can use in other projects. This API needs some instantiation and other logic which I want to encapsulate in this bean so that we can just put the bean into our app context with necessary propoerties alone, and this will then apply the logic.
I remember having read an article on this somewhere in the past - but cant find it now.
Any pointers to something similar will be helpful
EDIT: Sorry, I meant a spring interceptor, not a bean - my bad - please see my edit. I want to apply this interceptor to another bean dealing in XML messages.
EDIT 2: ANSWER FOUND
found it!
I found the answer to this - we were looking to insert the interceptor at the point where we were calling our webservice. So I looked at the interceptor package in spring-ws and found this end point interceptor interface. We will now implement this interceptor and put our processing logic in the appropriate handle*() method.
http://static.springsource.org/spring-ws/sites/1.5/apidocs/org/springframework/ws/server/EndpointInterceptor.html
As with everything in spring, there are a million ways to implement AOP. Check out the spring doco on AOP, the section on declaring aspects in xml may be the most convenient in your situation. You can configure an aspect
<aop:aspect id="myAspect" ref="existingBean">
<aop:before pointcut="execution(* com.package.to.intercept.*(..))" method="existingMethod"/>
</aop:aspect>
Or you could create new classes that use the AspectJ annotations and use those aspects to farm off to your actual work to your existing beans.
Found it!
See this link - http://static.springsource.org/spring-flex/docs/1.0.x/reference/html/ch02s09.html
This gives the interface that you need to implement and the XML definition.
Found a more suitable answer - see the edit in main question.
I have a use case where I need to call a (non-static) method in the bean only-once at the ApplicationContext load up. Is it ok, if I use MethodInvokingFactoryBean for this? Or we have a some better solution?
As a side note, I use ConfigContextLoaderListener to load the Application Context in web application. And want, that if bean 'A' is instantiated just call methodA() once.
How can this be done nicely?
To expand on the #PostConstruct suggestion in other answers, this really is the best solution, in my opinion.
It keeps your code decoupled from the Spring API (#PostConstruct is in javax.*)
It explicitly annotates your init method as something that needs to be called to initialize the bean
You don't need to remember to add the init-method attribute to your spring bean definition, spring will automatically call the method (assuming you register the annotation-config option somewhere else in the context, anyway).
You can use something like:
<beans>
<bean id="myBean" class="..." init-method="init"/>
</beans>
This will call the "init" method when the bean is instantiated.
There are three different approaches to consider, as described in the reference
Use init-method attribute
Pros:
Does not require bean to implement an interface.
Cons:
No immediate indication in source code that this method is required after construction to ensure the bean is correctly configured.
Implement InitializingBean
Pros:
No need to specify init-method, or turn on component scanning / annotation processing.
Appropriate for beans supplied with a library, where we don't want the application using this library to concern itself with bean lifecycle.
Cons:
More invasive than the init-method approach.
Use JSR-250 #PostConstruct lifecyle annotation
Pros:
Useful when using component scanning to autodetect beans.
Makes it clearer that a specific method is to be used for initialisation. Intent is closer to the code.
Cons:
Initialisation no longer centrally specified in configuration.
You must remember to turn on annotation processing (which can sometimes be forgotten)
Have you tried implementing InitializingBean? It sounds like exactly what you're after.
The downside is that your bean becomes Spring-aware, but in most applications that's not so bad.
You could deploy a custom BeanPostProcessor in your application context to do it. Or if you don't mind implementing a Spring interface in your bean, you could use the InitializingBean interface or the "init-method" directive (same link).
To further clear any confusion about the two approach i.e use of
#PostConstruct and
init-method="init"
From personal experience, I realized that using (1) only works in a servlet container, while (2) works in any environment, even in desktop applications. So, if you would be using Spring in a standalone application, you would have to use (2) to carry out that "call this method after initialization.