Well, for example:

@Configuration @ImportResource("classpath:META-INF/ann-config.xml") @ComponentScan(basePackageClasses = {MyController.class}) public class Initializer implements WebApplicationInitializer { public void onStartup(ServletContext servletContext) throws ServletException { AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext(); ctx.register(WebConfig.class); ctx.setConfigLocation("classpath:META-INF/ann-config.xml"); servletContext.addListener(new ContextLoaderListener(ctx)); ctx.setServletContext(servletContext); ServletRegistration.Dynamic servlet = servletContext.addServlet("dispather", new DispatcherServlet(ctx)); servlet.addMapping("/"); servlet.setLoadOnStartup(1); } }

Actually the question: What are the weaknesses of this approach compared to the XML configuration? What prompted to raise the topic? In one company, one of the specialists in an authoritative position as an architect, hinted that this is considered bad form. To the question Who is considered? response by the java community. What do you think?

  • everyone will have their own attitude right now. I am personally comfortable with xml - Senior Pomidor
  • one
    Well, the code is the code, and the configuration is the configuration (aka resources). You, for example, do not hardcode logins with passwords inside the code - rjhdby
  • Do you mean that it is better to separate all the same - program code and configuration in xml? - YuriyK

2 answers 2

There is such a term " hard code " (hardcode in our). Few people will argue that this is not bad (there are options when it is needed, but these are quite rare cases).

Here is the combination of configuration and code - this is it.

Let's consider the most obvious - the need to recompile after making changes to the configuration. Pull the thread, rewind the ball:

  1. Suddenly it turned out that for different customers a slightly different configuration is needed.
  2. It took an urgent need to tweak some trifle, and the developer on vacation
  3. Junior, who was asked to make a change from point 2, did not know that somewhere on the side there was another piece of configuration that had to be changed so that everything did not collapse. And there is a warm-up with downtime.
  4. The development branch is far away from production. Straight away. And suddenly it took a bit to change the configuration in a combat environment. "Eeee ... Well, is it not in the gita, but in the old SVN?"

etc.

  • About 1 item: for different customers and the files are different, be it xml or java. Is not it? According to point 2: is the uniform configuration style supported? If everything is set up in Java classes, then Junior will make changes to those same Java classes. In paragraph 4, it is not clear, and here, git, svn I agree with the hardcode and recompilation, but the arguments in points 1-4 are not obvious, to me - YuriyK
  • @YuriyK 1. only in one case, you simply change the xml, and in the second, for each customer you make a separate assembly with the subsequent support of the entire zoo in case of updates. 2. and this is at the mercy of the encoder (“right now I’ll screw the crutch, then change it”) 3. see clause 2. 4. this is an example of the fact that sometimes you need to edit configs in old builds, which is a separate headache. And this is not a complete list of unobvious rakes, on which you can start to jump happily. if in very simple terms, then hardcode resources in the code is such a clever way to drastically increase the connectivity of the code from scratch - rjhdby
  • "Joyful jumps on a rake" smiled) must be remembered But in general, convincingly - YuriyK

The main disadvantage in comparison with xml is the need to recompile when changing the configuration. And the rest is a matter of personal preference. I love the combination of annotations and xml.

  • one
    It's hard to disagree with the lack of re-compilation - YuriyK