JBoss fails to load class from WAR on service restart
ouugiii Jul 29, 2019 7:05 AMHi,
We have an Icefaces JSF application running on JBoss 7.1 EAP. The application is deployed in an EAR that contains a WAR. Sometimes, when restarting (not redeploying) the service, the service starts without problems. However, when trying to access a page, we get the following exception:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'dtoMapper' available
("dtoMapper" is a class is defined in the file WebContent/WEB-INF/classes/webContext.xml in the WAR)
This seems to happen approximately 5-10% of the time the service is restarted but is very random. Restarting the service again usually solves the problem (sometimes multiple restarts are required). It seems as though the application sometimes ignores the webContext.xml file entirely.
We have also noticed that the order in which JBoss loads modules (even its own) seems to change every time the service is started. Is this normal behaviour and could this be the reason for the random failure?
Our environment:
JBoss 7.1 EAP (installed as a Windows service)
Icefaces 4.2.0
Primefaces 5.3.0 (the application uses a single component from Primefaces)
JSF 2.2.13
Java EE 1.8u131
spring-aop-4.3.20.RELEASE.jar
spring-aspects-4.3.20.RELEASE.jar
spring-beans-4.3.20.RELEASE.jar
spring-context-4.3.20.RELEASE.jar
spring-context-support-4.3.20.RELEASE.jar
spring-core-4.3.20.RELEASE.jar
spring-expression-4.3.20.RELEASE.jar
spring-instrument-4.3.20.RELEASE.jar
spring-instrument-tomcat-4.3.20.RELEASE.jar
spring-jdbc-4.3.20.RELEASE.jar
spring-jms-4.3.20.RELEASE.jar
spring-ldap-core-1.3.1.RELEASE.jar
spring-messaging-4.3.20.RELEASE.jar
spring-orm-4.3.20.RELEASE.jar
spring-oxm-4.3.20.RELEASE.jar
spring-security-config-3.0.2.RELEASE.jar
spring-security-core-3.0.2.RELEASE.jar
spring-security-kerberos-core-1.0.0.M2.jar
spring-security-taglibs-3.0.2.RELEASE.jar
spring-security-web-3.0.2.RELEASE.jar
spring-test-4.2.5.RELEASE.jar
spring-tx-4.2.5.RELEASE.jar
spring-web-4.2.5.RELEASE.jar
spring-webmvc-4.2.5.RELEASE.jar
spring-webmvc-portlet-4.2.5.RELEASE.jar
spring-websocket-4.2.5.RELEASE.jar
spring-ws-core-2.2.4.RELEASE.jar
spring-ws-security-2.2.4.RELEASE.jar
spring-xml-2.2.4.RELEASE.jar
----------------------------------------------------------------------------------------------------------------------------------------
UPDATE 29.7.2019
I'm able to reproduce the error on localhost by simply emptying or deleting the webContext.xml file.
=> Is the webContext file also empty or doesn't exist on the serverside 5-10% of the times the service is started?
I've recognized the context files are loaded trough Springs ContextLoaderListener in the web.xml:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
And the context files are loaded with this part:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath*:context1.xml,
classpath*:context2.xml,
classpath*:context3.xml,
classpath*:webContext.xml
</param-value>
</context-param>
Does the order of the context files matter?
Is there anything wrong with the way I try to load the context files?
TESTING
I've made a test by using different param-values for the parameter "contextConfigLocation" and logging the path to the context files.
These are the options i've used for contextConfigLocation param-value:
(1) classpath:CONTEXT_FILE_NAME
(2) classpath:*CONTEXT_FILE_NAME
(3) classpath*:CONTEXT_FILE_NAME
(4) classpath:**/*CONTEXT_FILE_NAME
(5) classpath*:*CONTEXT_FILE_NAME
(6) classpath*:**/*CONTEXT_FILE_NAME
(7) classpath*:*Context.xml
(8) classpath*:**/*Context.xml
I have used this method from StackOverflow: https://stackoverflow.com/a/9564301/6209399 with some slight modifications to log the paths of the context files.
Results:
- (2) and (4) fails because it doesn't find files on the Virtual File System (VFS) (Where all the context files are)
- (1) and (3) fails with the same error approximately 5-10% of the time the service is restarted but is very random.
- (7) Haven't still been able to reproduce the same error (Have restarted the application 100 times) (Seems to work, but don't understand why).
- (5), (6) and (8) Haven't tested yet but they do find all the context files in my application.
The logging method (resource.getDescription()
) logs different thing based on the options [1-8] I put into the method:
- (1) logs: "class path resource [CONTEXT_FILE_NAME]"
- (3) logs:
- "URL [vfs:/C:/PATH_TO_EAR/lib/MODULE1.jar/context1.xml]"
- "URL [vfs:/C:/PATH_TO_EAR/PATH_TO_WAR/WEB-INF/classes/webContext.xml]"
- (5-8) logs:
- "VFS resource [/C:/PATH_TO_EAR/lib/MODULE1.jar/context1.xml]"
- "VFS resource [/C:/PATH_TO_EAR/PATH_TO_WAR/WEB-INF/classes/webContext.xml]"
- Why does the option (3) log 'URL ...' and the options (5-8) log 'VFS resource ...'? and does this affect how the context files are loaded?
I've also recognized that when using option (7) and (8) to log the path to context files, it logs the context files in a specific order:
- First it logs context files on the file system ("file [C:\PATH_TO_CONTEXT_FILE]")
- Then it logs context files inside the WAR ("VFS resource [/C:/PATH_TO_EAR/PATH_TO_WAR/WEB-INF/classes/webContext.xml]")
- Then it logs context files inside JARS ("VFS resource [/C:/PATH_TO_EAR/lib/MODULE1.jar/context1.xml]")
- Does this order affect in which order the context files are loaded?
----------------------------------------------------------------------------------------------------------------------------------------
UPDATE2 29.7.2019
Option (7) has also produced the error! It was not a solution.