Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ComponentScanBeanDefinitionParser::parseTypeFilters should not fail on ClassNotFoundException [SPR-16356] #20903

Closed
spring-projects-issues opened this issue Jan 8, 2018 · 2 comments
Assignees
Labels
in: core status: backported type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 8, 2018

Yanming Zhou opened SPR-16356 and commented

For example, parent project have such configuration to filter mvc and websocket component from root ApplicationContext, let them instantiated by child ApplicationContext

<context:component-scan base-package="com.acme">
     <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
     <context:exclude-filter type="annotation" expression="org.springframework.web.bind.annotation.ControllerAdvice"/>
     <context:exclude-filter type="assignable" expression="org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport"/>
     <context:exclude-filter type="assignable" expression="org.springframework.web.socket.config.annotation.WebSocketConfigurer"/>
</context:component-scan>

Some projects reuse such configuration and without spring-websocket dependency, it will throws ClassNotFoundException.

Caused by: java.lang.ClassNotFoundException: org.springframework.web.socket.config.annotation.WebSocketConfigurer
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1333) ~[catalina.jar:8.0.44]
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167) ~[catalina.jar:8.0.44]
	at org.springframework.util.ClassUtils.forName(ClassUtils.java:255) ~[spring-core-5.0.2.jar:5.0.2.RELEASE]
	at org.springframework.context.annotation.ComponentScanBeanDefinitionParser.createTypeFilter(ComponentScanBeanDefinitionParser.java:239) ~[spring-context-5.0.2.jar:5.0.2.RELEASE]
	at org.springframework.context.annotation.ComponentScanBeanDefinitionParser.parseTypeFilters(ComponentScanBeanDefinitionParser.java:215) ~[spring-context-5.0.2.jar:5.0.2.RELEASE]

I think spring should be lenient here, if class not present and the filter rule should ignore, at least "annotation" and "assignable" should do.


Affects: 4.3.13, 5.0.2

Referenced from: commits 092b3d4, 4adc820

Backported to: 4.3.14

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 8, 2018

Juergen Hoeller commented

There is a fine line between configuration typos and 'optional' configuration elements that can safely be ignored. What we can easily do here is to lower the reporting level to "warning" which by default doesn't fail but rather logs a warn-level message; I'll apply this for 5.0.3 and 4.3.14.

You could customize your ProblemReporter configuration to completely ignore such warnings, that is, to log them at an even lower level or not at all. This requires custom configuration at the XmlBeanDefinitionReader level though, so might be rather inconvenient.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 9, 2018

Yanming Zhou commented

Thanks for quick response, warning is fine.

@spring-projects-issues spring-projects-issues added status: backported type: enhancement in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0.3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants