In Spring 3.0 and higher it is possible to refer a property of another bean as below.
<bean id="a" class="A">
<property name="list"
value="#{b.list}"/>
</bean>
Is there a way I can refer property of another bean in Spring 2.5.1.
Note that Spring Expression integrated after Spring 3.0
Spring is a framework for dependency injection and not for value injection. If your bean a has dependency on bean b for its creation, then why not inject the bean b in bean a.
Spring do give limited feature for injecting values but that is only for configuring the components i.e. beans.
Related
I am trying to configure Spring : LocalValidatorFactoryBean to set my custom TraversableResolver
I do the following in my applicationContext.xml :
<bean id="customTraversableResolver" class="com.package.core.resolver.SimpleTraversableResolver" />
<bean id="validator"
class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean">
<property name="traversableResolver" ref="customTraversableResolver" />
</bean>
But at runtime, #Valid bean in controller are validated with default traversable resolver (from hibernate validator).
So, how to configure default bean validation configuration in spring ?
Have you tried adding validation.xml and adding the traversable resolver configuration in there? Btw, what do you want to achieve with your custom resolver?
While you’re using Spring MVC, you must register your validator in this way:
<mvc:annotation-driven validator="validator" />
If you want method-level validation, then define bean:
<!-- Enable method-level validation on annotated methods via JSR-303 -->
<bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor"
p:validatorFactory-ref="validator" />
Then you don’t need validator.xml anymore.
Note: This works with Spring 3.2.x and Hibernate Validator 4.x.
Why is autowiring required? What is the explanation for the concept of autowiring?
#autowired annotation in Spring Framework.
Autowiring is not required, just convenient.
It means that if you have a property that requires an InterfaceA and a single bean has been declared in Spring that is of type InterfaceA, instead of using XML to manually "wire up" the relationship (setting a bean reference as a property of another), you can let Spring do the wiring for you.
This is a common question for the beginners. As the beans are injected using DI (setter injections, constructor injections), why do we need auto-wiring? Auto-wiring also doing the same thing, right?
The answer is, it saves you from writing more code.
If using an XML file, using autowire attribute saves you from writing the wiring code in the bean definition.
Please look at code below.
Configuration code without Auto-wiring:
<bean id="employee" class="com.Employee">
<property name="name" value="Dexter"></property>
</bean>
<bean id="employeeService" class="com.EmployeeService">
<property name="employee" ref="employee"></property>
</bean>
Configuration code with Auto-wiring:
<bean id="employee" class="com.Employee">
<property name="name" value="Dexter"></property>
</bean>
<bean id="employeeService" class="com.EmployeeService" autowire="byName" />
Note that we did not have to write anything to refer property of EmployeeService, i.e., Employee. But still it was injected. Autowiring makes the container to search the bean configurations and do the collaboration among beans, without the developer specifically mentioning these.
If we use annotation, even we don’t have to write anything in XML files, including this autoware="byName", etc. Simply #Autowired on bean's setter/field/constructor is sufficient.
I have a noob spring question.
if i have a bean that is dependent on google's gdata api jars. How I represent this in a beans.xml file?
<bean class="com.google.foo.bar.ExternalClass" id="yourExternalBeanName" />
Then you can inject this 3rd party bean in your classes. With XML:
<property name="yourProperty" ref="yourExternalBeanName" />
or annotations:
#Inject
private ExternalClass yourProperty;
I am migrating from Spring 2.5 to Spring 3.
They have introduced <mvc:annotation-driven /> which does some black magic. This is expected to be declared in servlet configuration file only.
In Spring 2.5 I have just used <context:annotation-config /> and <context:component-scan base='...'/> tags declared both in application-context.xml and dispatcher servlet configuration XML with appropriate base packages to scan.
So I wonder what is the difference between mvc:annotation-driven and context:annotation-config tags in servlet config and what can I eliminate in Spring 3 config files?
<context:annotation-config> declares support for general annotations such as #Required, #Autowired, #PostConstruct, and so on.
<mvc:annotation-driven /> declares explicit support for annotation-driven MVC controllers (i.e. #RequestMapping, #Controller, although support for those is the default behaviour), as well as adding support for declarative validation via #Valid and message body marshalling with #RequestBody/ResponseBody.
There is also some more detail on the use of <mvc:annotation-driven /> in the Spring docs. In a nutshell, <mvc:annotation-driven /> gives you greater control over the inner workings of Spring MVC. You don't need to use it unless you need one or more of the features outlined in the aforementioned section of the docs.
Also, there are other "annotation-driven" tags available to provide additional functionality in other Spring modules. For example, <transaction:annotation-driven /> enables the use of the #Transaction annotation, <task:annotation-driven /> is required for #Scheduled et al...
mvc:annotation-driven is a tag added in Spring 3.0 which does the following:
Configures the Spring 3 Type ConversionService (alternative to PropertyEditors)
Adds support for formatting Number fields with #NumberFormat
Adds support for formatting Date, Calendar, and Joda Time fields with #DateTimeFormat, if Joda Time is on the classpath
Adds support for validating #Controller inputs with #Valid, if a JSR-303 Provider is on the classpath
Adds support for support for reading and writing XML, if JAXB is on the classpath (HTTP message conversion with #RequestBody/#ResponseBody)
Adds support for reading and writing JSON, if Jackson is o n the classpath (along the same lines as #5)
context:annotation-config
Looks for annotations on beans in the same application context it is defined and declares support for all the general annotations like #Autowired, #Resource, #Required, #PostConstruct etc etc.
It is possible to use the Spring Framework's #Transactional support outside of a Spring container. In reference documentation is chapter about AspectJ aspect. I'm trying to use it in my wicket application, but with no positive result.
application-context.xml:
<tx:annotation-driven transaction-manager="transactionManager" mode="aspectj" />
<context:annotation-config />
<context:component-scan base-package="com.wicket.app"/>
<context:spring-configured />
<bean id="annotationTransactionAspect" factory-method="aspectOf"
class="org.springframework.transaction.aspectj.AnnotationTransactionAspect">
<property name="transactionManager" ref="transactionManager"></property>
</bean>
In my form class annotated by #Configurable, I have:
#Transactional
public void process(IFormSubmittingComponent submittingComponent) {
super.process(submittingComponent);
getDao().getEntityManager().flush();
}
Stack trace:
org.apache.openjpa.persistence.TransactionRequiredException: Can only perform operation while a transaction is active.
You might be able to get this working using AspectJ load-time-weaving, but that's a very complex solution for a simple problem.
If you need declarative transactions, then I suggest you move the transactional logic from the wicket component down into a Spring bean, and invoke the Spring bean from the wicket object. The Spring bean would have the transactional annotations, and would be proxied correctly by the Spring container.
I have no experience with Wicket. But is your 'form class' (the one that contains method annotated with #Transactional) Spring managed code? i.e. Who creates the instances of the class?
If it's not, that Spring will not provide #Transactional support (neither will #Autowired work, etc).