Spring Configuration Check

When IDEA gives a popup about a Spring Configuration Check, what does it actually want me to do?
I guess it found some files of which it suspects they are Spring configuration files, and I guess Idea is right.
When I click the link in the window, I see some dialog boxes, but still: I don't have a clue on what it wants me to do here???

21 comments
Comment actions Permalink

Hello Wouter,

you'll need to setup filesets in Spring facet, so IntelliJ IDEA understands the structure of your Spring setup.

Please see https://www.jetbrains.com/idea/help/managing-file-sets.html for more detailed description.

- Yann

0
Comment actions Permalink

You can configure application context groupings that match what your application loads. For example, IDEA can't extract that your REST service loads rest-contex.xml, data-access.xml and business-beans.xml while your messaging service needs jms-context.xml and business-beans,xml. (Notice both use the business-beans.xml) So yo create two Application Context definitions in IDEA. One for the REST service with the three context file, and the other for the Messaging servie with the two context files. This allow IDEA to provide error checking and code completion when you work with the context files. For example, when editing the rest-contect.xml file, and you go to add the userCredentialsDao bean reference, defined in the data-access.xml context, for the setter of a bean, IDE will give auto suggestions and code completion. Or it will highlight it in red as an undefined bean if you make a typo in the bean name. Them, if later you want to rename the bean, if you use the rename refactoring, IDEA will know to update its references in the other context files.

Even if you have just a single context file, you will want to add that to an Application Context definition.

0
Comment actions Permalink

I have a continuation question for this - When does this happen?
We have a very large project with ~500 modules. Most if not all of them have several spring configuration files.
Some of the files are automatically detected, and some not.
Even in a single module - Some of its files automatically detected and some not.
When are files automatically detected and when do I manually add them to a file set? Is it related to new config files arriving with SVN UPDATE?
Thanks,
Guy

0
Comment actions Permalink

Hello Guy,

The configuration check happens on startup immediately after the project has been loaded.

Please specify what configuration files are not found (XML/Java, where are they located exactly within module).

Please note the detection only informs you about non-configured files, you'll still have to setup corresponding fileset(s) in your Spring facet(s) as described above.

0
Comment actions Permalink

I just did an SVN UP, and then closed and reopened the project. I got the following results

  1. One of my modules shows unconfigured files (It's a new module)
  2. All of the files were NOT changed since the last update
  3. One of them is under <module>/src/main/resources, and the rest under <module>/src/main/webapp/WEB-INF/spring
  4. All of them are XMLs (But I've seen this warning with JAVA files as well)


So far what I've been doing in such cases is edit the spring facet of the relevant module (Or creating it if none exists) and add those files

Thanks,
Guy

0
Comment actions Permalink

The configuration check does not distinguish between changed/unchanged files.
Of course, new/moved files will be detected (unless they're configured explicitly/implicitly in Spring facet already). This is exactly the usecase for this check: notify user about not-yet-performed (IntelliJ IDEA specific) configuration.

0
Comment actions Permalink

But that's my point, these files were not changed and also existed before I reopened IntelliJ just now. Why weren't these files detected in the first place?
Also, you did not answer - why aren't these files automatically added to an existing fileset, or have a new facet+fileset created for them?

0
Comment actions Permalink

Most probably you didn't reopen the project before, which is the only time this check runs for the whole project.
You can always open Spring facet of each module to run checks for this module.

Mark Vedder explained the rationale for the configuration process above, there is a RFE to provide "auto-configuration" which you can watch/vote: https://youtrack.jetbrains.com/issue/IDEA-131136 and https://youtrack.jetbrains.com/issue/IDEA-111247

0
Comment actions Permalink

I tried starting idea with "-Didea.spring.autoconfig=true" but I still get the same warning about the unconfigured files.

0
Comment actions Permalink

This switch is not supported yet officially, so the configuration check does not know about it (yet). You can disable the check completely via the link given in the notification.

0
Comment actions Permalink

But then the classes defined as beans in those contexts will not be identified as beans borrect?

0
Comment actions Permalink

It will completely ignore are configured contexts when you enable this switch, but put all configurations in one "global" context instead. So the beans should be resolved (again, this mode is not supported officially so there might be bugs).

0
Comment actions Permalink

Now I'm confused, do you mean disabling the check will put everything in one global context? Or adding the switch (Which doesn't work like I said) will do it?
And to clarify - Disaling the check will cause the beans not be unresolved right?

0
Comment actions Permalink

The switch = turning on auto-configuration via the JVM property

The check is not related to the actual resolving of beans in any way.

0
Comment actions Permalink

In that case, what is this configuration used for? Only for cross-context bean name refactoring?

0
Comment actions Permalink

Please specify what you mean with "this configuration". What do you mean with bean name refactoring?

0
Comment actions Permalink

By "this configuration" I mean the spring facet and the filesets that include different spring configuration files.

This is quoted from the 3rd post in this thread:

This allow IDEA to provide error checking and code completion when you work with the context files. For example, when editing the rest-contect.xml file, and you go to add the userCredentialsDao bean reference, defined in the data-access.xml context, for the setter of a bean, IDE will give auto suggestions and code completion. Or it will highlight it in red as an undefined bean if you make a typo in the bean name. Them, if later you want to rename the bean, if you use the rename refactoring, IDEA will know to update its references in the other context files


So if I understand correctly:
  1. The bean resolving is unrelated to the factes-filesets thing. Classes that are defined as beans will still have the little grean leaf icon next to their defintion and I will still be able to navigate from the class to the context, and back.
  2. If I disable the facets-filesets configuration check, I'll only be missing on what's mentioned in the quote (Renaming, autocompletion of bean names etc.)


Correct?

0
Comment actions Permalink

1) No, the bean resolving is related to the facets/filesets, that's the whole point of setting this up according to your application's structure so the IDE understands the relationships your configuration files have at runtime.
2) Disabling the check does nothing more than disabling the check. All other functionality is not touched by this at all.

0
Comment actions Permalink

So if I disable the checks, I'll have unconfigured Spring contexts which I won't be notified about.
Any bean defined in this context will not be resolved, right?

0
Comment actions Permalink

Exactly. Unless you use auto configuration mode, in which case it will use those global contexts instead.

0
Comment actions Permalink

Took me a while but I got it :)
Thanks

0

Please sign in to leave a comment.