As of Selena #7002, is seems that the spring facet configuration is automatically
created from the "web.xml" of the web facet (if present).
That's a nice feature - however because of current limitations it makes #7002
impossible to work with for me.
Let me describe my spring configuration:
1) Services and data access components:
I use "ContextLoaderListener" with "contextConfigLocation" context-param
to initialize a root context from a set of config files. Usually I have one
file for data access, one for security config, one containing higher level
Spring will merge the beans from these config into one big context. So bean
references from service to data access components are resolved. Note that
this context does not include any web-related components: no web controllers,
request interceptors or such. Just the backing components of the application.
2) Multiple web contexts:
In addition, I use multiple DispatcherServlet configurations to create child
For each of these, spring will load "<servlet-name>-servlet.xml", and create
a child application context. These contexts contain MCV controllers, form
validators and other web UI related beans. In addition the spring DispatcherServlet
will route HTTP requests through these contexts.
Note that beans from "public" cannot refer to beans from "admin" - spring
creates a separate context for each DispatcherServlet configuration. However
beans from these child contexts can refer to beans in the root context.
This makes sense, since a MVC controller will likely need to talk to a business
service or DAO.
The crucial aspect is that spring contexts can be arranged in a hierarchical
fashion. Beans from a child context can refer to a bean in a parent context,
but not the other around. In addition, beans from a child context cannot
refer to beans from a "sibling" child context - references are only allowed
"up" in the tree.
Now - what's wrong with the spring facet in #7002?
1) IDEA does not understand that spring configuration is hierarchical in
nature. In past builds I worked around this by just piling all configuration
files into one bit fileset. Sometimes completion for bean references would
give illegal suggestions (because of story above) - but in general things
worked. Link to issue in JIRA:
2) Facet autoconfiguration from web.xml creates separate config sets.
For above declaration, the spring facet autoconfiguration in #7002 creates
three separate configuration sets:
a) One set for the root context
b) One set for the "public" web context
c) One set for the "admin" web context
Since the root context does not refer (and may not refer) to any child context,
editor is mostly green for these files.
However, for web contexts "public" and "admin", right editor gutter is mostly
red, because most beans have a dependency on something from the root context.
Now, autoconfiguration is a nice idea, I thought. After the initial confusion
I decided to just add "public" and "admin" back to the root context and happily
continue working. No such luck - #7002 will not allow me to edit this auto-generated
configuration. I could of course hide or rename my web.xml, but that will
cause other kinds of pain.
So to conclude: please consider implementing IDEADEV-14576 - it will have
other benefits besides solving the problems described in this post. Context
hierarchy has been a core feature of spring - even before the name "spring"
was chosen. Infrastructure stuff like Bean(Factory)PostProcessors is scoped
to a context as well. Again, see IDEADEV-14576 for more details.
In addition, it would be nice if facet autoconfiguration was more flexible.