I have validator class which uses
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basename" value="/WEB-INF/messages" />
</bean>
Besides validator which does more complex validation I also use JSR303 like
#NotNull(message="null value is not allowed")
protected String postCode;
I want for JSR to use same file source messages.
#NotNull(message=<SOMEHOW GO TO MY messages_en_US.properties AND EXTRACT SOMETHING LIKE : user.poscode.null>)
Thanks!
By default JSR303 validator looks for a file called ValidationMessages.properties, which is bundled with the implementation you use.
If you want to add your own constraint validation messages you have to provide your own ValidationMessages.properties, and add to it the message.
You can look at Message interpolation, Hibernate validator docs.
But what I've just describe its Java EE standard behaviour I don't know if Spring behaves in the same way
I resolved the situation with help of another more focused question of mine on simillar topic. Anyone interested : javax.validation how to target different locale?
Please be aware however that there will be a need in two sets of files including resourcebundle and properties.
Related
I extended AbstractByteArraySerializerand now I want to use this serializer like the rest of the available TCP serializers (LF, NULL, L1, ...).
I found the profiles in tcp-encdec.xml and registered my own profile:
...
<beans profile="use-custom">
<bean id="CUSTOM"
class="custom.tcp.serializer.ByteArrayCustomSerializer">
<property name="maxMessageSize" value="${bufferSize}" />
</bean>
</beans>
...
Spring uses EncoderDecoderMixins.Encoding to convert Encoding to a specific profile.
EncoderDecoderMixins.Encoding is an enum in a final class. Spring converts the decoder TCP property to a specific profile based on this enum. My CUSTOM serializer won't work since it isn't in the specified Encodings.
Is there a way to register a new Encoding or do I have to write a new Source module to use my serializer?
Unfortunately, you will need a custom source; we could probably add another enumeration, such as CUSTOM, where you provide the classname of the deserializer but that will need a change to the standard source.
A quick and dirty work-around would be to modify the source locally:
<int-ip:tcp-connection-factory id="connectionFactory"
...
deserializer="myDeserializer"/>
<bean id="myDeserializer" class="foo.Deser" />
i.e. change the ${decoder} placeholder to point to your bean.
Below is part of my Spring Integration config :
<bean id="recursiveScanner" class="org.springframework.integration.file.RecursiveLeafOnlyDirectoryScanner" >
<property name="filter" ref="skipTmpFileFilter" />
</bean>
<bean id="skipTmpFileFilter" class="org.springframework.integration.file.filters.RegexPatternFileListFilter">
<constructor-arg value="^[^~].*"/>
</bean>
<file:inbound-channel-adapter directory="${inbound.folder}"
scanner="recursiveScanner"
id="fileChannel"
filter="fileNameFilter">
<integration:poller id="poller" fixed-delay="10000" />
</file:inbound-channel-adapter>
As you can see, I'd like to define 2 different filters :
one to skip temp files, in the recursiveScanner
one more advanced in which I have defined some other patterns, fileNameFilter (details of which are not relevant, so I'm not providing it)
What I see when I launch this in debug mode is that first, skipTmpFileFilter is set in recursiveScanner, but it is overwritten by fileNameFilter a bit after, making skipTmpFileFilter ineffective.
Is it the intended behavior or a bug ? I think it would make sense to be able to configure 2 different filters, one generic (in scanner) and one more specific (in the inbound adapter). Here, I'm kind of forced to use a composite filter.
Thanks
Vincent
If we take a look to the source code of FileReadingMessageSource, we'll see:
public void setFilter(FileListFilter<File> filter) {
Assert.notNull(filter, "'filter' must not be null");
this.scanner.setFilter(filter);
}
And there is no more stuff around the filter for the FileReadingMessageSource. Everything is delegated to the DirectoryScanner.
So, there is no any choice, unless provide only one filter option: or for the DirectoryScanner bean, or <file:inbound-channel-adapter>.
And yes: to have several filters in place you should use CompositeFileListFilter.
However I think we can protect that point of the override case.
Feel free to raise JIRA issue on the matter.
Can anyone advice me how can I inject multiple dependencies for a same bean in the spring framework?
I will try to explain the scenario very briefly, in case anyone can suggest me a better solution.
I have a data repository and it has to go through certain filters to filter out unwanted data. The criteria for filtering change and are not fixed to one filter. So, I created a filter handler which filters data based on filters. I want to use IoC and inject the filter dependencies. Its straight forward till here, only that there can be multiple filters. How do I inject multiple dependencies. If I can create a List of filters, how do I declare a list in the xml file?
Thanks in advance,
You can do it like this (filter1 and filter2 are ids of beans defined elsewhere):
<property name="propertyName">
<list>
<ref bean="filter1"/>
<ref bean="filter2"/>
</list>
</property>
If your filters all implement the same interface, the most elegant way (in my opinion) is like this:
#Autowired
private List<YourFilterInterface> filters;
This will wire a list containing all registered beans implementing YourFilterInterface. It's available in Spring version 2.5 and up.
The Spring docs tell you how to create a list.
Example taken from above link...
<!-- creates a java.util.List instance with the supplied values -->
<util:list id="emails">
<value>pechorin#hero.org</value>
<value>raskolnikov#slums.org</value>
<value>stavrogin#gov.org</value>
<value>porfiry#gov.org</value>
</util:list>
Spring Annotations - I am getting some documents regarding Annotations but, they are explaining each annotation and how to use it.
but i want, know how can achieve same annotations behavior with bean configuration.
ex:
Annotation Bean config
#Required ?
Can you help.................
I don't really understand your question, but here are some links from the Spring Reference that seem relevant:
3.9. Annotation-based container configuration
3.11. Java-based container configuration
On second thought (and after editing your question's source) I seem to understand. I think you want an XML alternative to the #Required annotation.
Quote from the #Required section:
The container throws an exception if the affected bean property has not been populated; this allows for eager and explicit failure, avoiding NullPointerExceptions or the like later on.
I'm not sure such a thing exists in XML, I think the only way to get that behavior is through explicit wiring.
<bean class"foo.bar.Service.class">
<!-- This will fail if no bean named subService is available -->
<property name="subService" ref="subService" />
</bean>
It should be easy:
<bean id="handlerMapping"
class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="interceptors">
<list>
<ref bean="myInterceptor" />
</list>
</property>
</bean>
but this way the interceptor isn't called.
By default, Spring will register a BeanNameUrlHandlerMapping, and a DefaultAnnotationHandlerMapping, without any explicit config required.
If you define your own HandlerMapping beans, then the default ones will not be registered, and you'll just get the explicitly declared ones.
So far, so good.
The problem comes when you add <mvc:annotation-driven/> to the mix. This also declares its own DefaultAnnotationHandlerMapping, which replaces the defaults. However, if you also declare your own one, then you end up with two. Since they are consulted in order of declaration, this usually means the one registered by <mvc:annotation-driven/> gets called first, and your own one gets ignored.
It would be better if the DefaultAnnotationHandlerMapping registered by <mvc:annotation-driven/> acted like the default one, i.e. if explicitly declared ones took precedence, but that's not the way they wrote it.
My current preference is to not use <mvc:annotation-driven/> at all, it's too confusing, and too unpredictable when mixed with other config options. It doesn't really do anything especially complex, it's not difficult or verbose to explicitly add the stuff that it does for you, and the end result is easier to follow.
Problem I faced: Spring MVC tag doesn't go well with custom definition of DefaultAnnotationHandlerMapping.
Why..? the reason is very well explained in the answers above.
Why i wanted to use DefaultAnnotationHandlerMapping? I want to define an interceptor for my every request. a Spring-Mobile interceptor to determine the USER AGENT..mobile or a browser?
Now Due to this clash of mvc-annotation and DefaultAnnotationHandlerMapping, I cant use DefaultAnnotationHandlerMapping anymore.
The problem comes down to how can i register my interceptors with tag.
The solution was simple...but hard to find. Posting it so it can be helpful to the other solution seekers..
Use tag and register the interceptor bean in your dispathcer-servlet.xml
example :
<mvc:interceptors>
<!-- This runs for all mappings -->
<bean class="main.com.XXX.MobileDeviceResolverHanlderInterceptor"/>
</mvc:interceptors>
The reason for this behaviour is that two beans of type org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping exist in the application context. Spring resolves the two, but asks only the first for interceptors. To fix this, the following init parameter should be set to the DispatcherServlet
<init-param>
<param-name>detectAllHandlerMappings</param-name>
<param-value>false</param-value>
</init-param>
This makes the dispatcher servlet use only the handlerMapping defined in the x-servlet.xml
It is beyond me why this is the default behaviour. I'm expecting an answer from the spring community.
In my case I can NOT get rid of <mvc:annotation-driven/> as I am using jackson for json support using annotation.
What I tried, moved my all interceptors <mvc:interceptors> in separate "xml" file (interceptor-config.xml) and imported it from my x-dispatcher-servlet.xml
<import resource="interceptor-config.xml"/>
It solve my issue and avoid default 'DefaultAnnotationHandlerMapping' beans my application context.
Rather than creating separate 'xml', you can copy/paste interceptor contents directly in 'x-dispatcher-servlet.xml'.
Following is my interceptor:
<mvc:interceptors>
<mvc:interceptor>
<!-- Intercepting specific URL -->
<mvc:mapping path="/abc/**" />
<bean id= "myInterceptor"
class="xx.xxx.xxx.MyInterceptor" />
</mvc:interceptor>
<mvc:interceptors>
In Spring MVC 3.0 you can use <mvc:interceptors> instead of manual defining the handler mapping.