In places of work before you start something you will have many internal debates, "flexing of architecture muscles" on how something is named. Naming of classes and files is an important aspect of software development but it is very difficult to get done right. I personally struggle with this, pick something and be consistent vs spending days upon days to find the right name. There has been a smaller percentage of the "oh man we named this right" to "crap, why the heck would we name something like that".
In our environment we have applications that consume many modules (jars) and found that moving to springframework java config has increased the overall application load time performance. While moving to java config we wanted to standardize the naming convention for configuration classes or at least have some consistency. While it doesn't matter so much from a spring loading perspective as @Configuration will be picked up, it is nice for developers that look into a module they can find the "applicationContext" class.
We first started down this path:
- Each module will define
ApplicationConfigthat would import and define resources - Each web application would define a
WebConfigthat would have beans specific to web application context
Our first step was to start to convert the lower level jars to java config and during the process we hit the following exception
org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'applicationConfig' for bean class [com.acme.ApplicationConfig] conflicts with existing, non-compatible bean definition of same name and class [com.acme.package2.ApplicationConfig]ConflictingBeanDefinitionException is thrown when there is multiple beans of the same name. A way to solve for this is to name your bean with @Qualifier("beanName") or @Resource(name="beanName"). So what is easier, to add a qualifier to each ApplicationConfig and have developers have to search and guess or to name the classes specific to module.
We went down the road of naming *Config beans specific to module. So for instance if the jar is named com.acme.something.whatever, we would name the config file SomethingWhateverConfig. We have fairly long names which was a concern but not a very deep package structure outside the root package so felt comfortable with this route. Now time will tell to see if this point in time decision is a good one or not.