Custom Spring property-placeholder implementation - disable editor validation?

Hi Everyone - 2 questions:

  • Anyone know how to disable spring property-placeholder validation?
  • Anyone know how to plugin a custom property-placeholder implementation to the validation? (ideal)


Background:

We have a custom extension of PropertyPlaceholderConfigurer that retrieves files from a remote server, caches them, and does event-based reloading. Unfortunately in the editor it breaks the validation (lots of read). I'm looking to in the short-run get rid of the red (even if it means I lose validation, or disable it somehow - though I didn't see an option) or (ideally) figure out a way to feed my custom placeholders values into the validation.

Thanks!
Jason

3 comments
Comment actions Permalink

Hello Jason,

You have a few options. Unfortunately, none of these will meet your ideal goal since it is not possible to plug-in a custom property-placeholder implementation into IDEA.

As a side note about option 1 & 2. Anytime you have an inspection you want to disable or suppress, put your cursor on the error, hit alt-enter. in the pop-up menu, select one of the lines with the red light bulbs and hit the right arrow to get the secondary pop-up menu. In that list will be options to configure, disable, or suppress the inspection.

Option 1

You can disable the "Spring Model" inspection that is responsible for highlighting this error. (It's the "Spring Model" inspection in the "Spring Model" group. Settings | Project Settings | Inspections) The downside of doing such is that this inspection is responsible for a number of other things such as valid property names, valid bean references, and others. For example, if you disable that inspection, the following declaration would show no errors:

<bean >

    <property name="invalidProperty" ref="nonExistentBean" />

</bean>

despite it's having an invalid property name, and an invalid bean reference.

Option 2

You can suppress the inspection on a per tag basis, or for the entire file. The downside here is that other errors in that tag are also suppressed. For example, the following declaration would not show an error for the erroneous property:


<bean >


    <!--suppress SpringModelInspection -->
    <property name="propertyWithTypoInName" value="${my.placeholder} />
</bean>


As a variation of this option, place any bean declarations that use placeholders into a separate spring context file and import it into the main file This will allow you to suppress the inspection for that file only, and still get the benefits of the inspection in the main context file. Not the best solution since you are configuring your application in order to solve an IDEA issue rather than configuring your application in the way that's the cleanest for it.


Option 3
Change the highlighting level of the "Spring Model" inspection from Error to a lower level such as Warning, Info, or a custom level you create. This at least eliminates the red, but still allows you to see other errors in the file. Of course you still have to deal with the noise of the warning or info level highlights

Option 4
This is a complete hack, and places code in your application that is there solely to solve an IDE "issue", and as such is a horrible practice. Plus it causes you to have to do some work each time you add a placeholder to your application. Nevertheless, here it is... Write a Dummy custom PropertyPlaceholderConfigurer that extends the setLocation and setLocations method. Make them empty setters that ignore the set value. Place a properties file in your classpath that contains an entry for all placeholders your actual custom PropertyPlaceholderConfigurer would fetch. (The entries can have empty values, but that will cause issues if you you have the IDEA default of it resolving those values and placing the blanks in the context file. So it is best to set them equal to the placeholder name or notation itself.) Create a bean configuration entry for this dummy PropertyPlaceholderConfigurer with the location set to the classpath value of the properties file you created. This will allow IDEA to resolve the property placeholders, but they will not get loaded at runtime. Like I said, a messy Hack.

Option 5
Similar to option 4, but you'll be able to sleep at night by justifying the hack and horrible coding practice you did as Unit Testing. Write a unit test around the code you have that retrieves the placeholders. Have it generate a properties file to put in the classpath. Then basically do Option 4. This way you are getting some value in the IDEA inspection in that it can resolve against the same set of properties that would be there in production. You can always make the unit test an optional test that has to be run manually.

Option 6
Vote for the feature request I made requesting to break the spring property placeholders inspection out from 'Spring Model' inspection into its own inspection: http://youtrack.jetbrains.net/issue/IDEA-55878 This would allow for it to be suppressed without also suppressing other useful inspections.  

I hope that helps. Others may have other ideas and/or better solutions.
0
Comment actions Permalink

Yes, that's very consistent with what my thoughts are.

Option4 - does that work? I could resonably probably extend the current impl, to point at the local "defaults" version - yes it's refactoring for the IDEs sake, but it wouldn't be an unreasonable stretch of usage. Is Intellij smart enough to work with a custom impl, that extends the existing property placeholder configurer?

0
Comment actions Permalink

jayshao wrote:

Option4 - does that work? I could resonably probably extend the current impl, to point at the local "defaults" version - yes it's refactoring for the IDEs sake, but it wouldn't be an unreasonable stretch of usage. Is Intellij smart enough to work with a custom impl, that extends the existing property placeholder configurer?

Yes it does. We are currently using a custom PropertyPlaceholderConfigurer and IDEA can resolve the placeholders set via the locations property.(But they are still properties files on the classpath and not from a service like your custom PropertyPlaceholderConfigurer.)

0

Please sign in to leave a comment.