Class Design : Parsers for different file type and ParserFactory
The method Parser.fileFormatSupported looks great. Letting each parser declare which file types it can process allows for information hiding. Android uses the same style for deciding the "Which app can handle which file types?" question.
The method Parser.supports uses an inferior style. If you can, you should also switch to a declarative style by replacing this method with Set&lt;Class&lt;?&gt;&gt; getSupportedClasses(). Maybe you only need Class&lt;?&gt; getSupportedClass().
In the supports methods, you currently use isAssignableFrom. This looks wrong to me, since each of these parsers probably only supports exactly this one class. Therefore these methods should return clazz == Device.class.
The CSVToDeviceportServer class is missing the Parser in its name.
In the afterPropertiesSet method, you don't need to check for this.parsers == null. The code will fail in the for loop below. The chances of your custom exception being thrown are close to zero. And even if this.parsers were null, it would be very easy to see in the stack trace.
In the afterPropertiesSet method, you should use a Multimap (from Guava) instead of a HashMap of lists. This makes the code shorter and easier to understand.
Instead of the @PostConstruct method, you may think about having an @Autowired void setParsers(List&lt;Parser&gt; parsers) method that initializes everything. This method is easier to use in unit tests. This method should be package-private since it is not intended to be used by any other code.