[
https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin....
]
David Edwards edited comment on WFLY-4205 at 11/9/15 5:02 AM:
--------------------------------------------------------------
Does the fix for this still require a
META-INF/services/javax.servlet.ServletContainerIntializer file in the WAR's
WEB-INF/lib? This certainly seems to be the case in 9.0.2.Final. I have an example project
showing the work arounds I have had to add to get Spring Boot WARs to work in an EAR on
Wildfly:
https://github.com/purple52/spring-boot-ear-skinny-war.
It appears that once there is an SCI in META-INF/services of each WAR, Wildfly loads the
SpringServletContainerInitializer from the EAR's lib folder. However, when it scans
for WebApplicationInitializer implementations, it only looks in the EAR's lib folder,
so does not find Spring Boot applications in the WAR files.
was (Author: purple52):
Does the fix for this still require a
META-INF/services/javax.servlet.ServletContainerIntializer file in the WAR's
WEB-INF/lib? This certainly seems to be the case in 9.0.2.Final. I have an example project
showing the work arounds I have had to add to get Spring Boot WARs to work in an EAR on
Wildfly:
https://github.com/purple52/spring-boot-ear-skinny-war.
Undertow not detecting @HandlesTypes If the implentation class is
inside EAR/lib
--------------------------------------------------------------------------------
Key: WFLY-4205
URL:
https://issues.jboss.org/browse/WFLY-4205
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
Reporter: Nick .
Assignee: Stuart Douglas
Labels: EAR, servlet3.0, spring-mvc
Fix For: 9.0.0.Beta1
Hi,
I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All
my spring mvc related jar's are in my EAR/lib, i'm using
SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as
follows
{code}
@HandlesTypes(WebApplicationInitializer.class)
public class SpringServletContainerInitializer implements ServletContainerInitializer {
@Override
public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext
servletContext)
throws ServletException {
List<WebApplicationInitializer> initializers = new
LinkedList<WebApplicationInitializer>();
if (webAppInitializerClasses != null) {
for (Class<?> waiClass : webAppInitializerClasses) {
// Be defensive: Some servlet containers provide us with invalid classes,
// no matter what @HandlesTypes says...
if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers())
&&
WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
try {
initializers.add((WebApplicationInitializer) waiClass.newInstance());
}
catch (Throwable ex) {
throw new ServletException("Failed to instantiate WebApplicationInitializer
class", ex);
}
}
}
}
if (initializers.isEmpty()) {
servletContext.log("No Spring WebApplicationInitializer types detected on
classpath");
return;
}
AnnotationAwareOrderComparator.sort(initializers);
servletContext.log("Spring WebApplicationInitializers detected on classpath:
" + initializers);
for (WebApplicationInitializer initializer : initializers) {
initializer.onStartup(servletContext);
}
}
}
{code}
But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the
EAR/lib
Even i have tried adding the extracted the SPI from spring-web jar and added inside my
war's WEB-INF/lib as a jar
WEB-INF/lib/web-init-spi.jar which contains
META-INF/services/javax.servlet.ServletContainerIntializer file with
org.springframework.web.SpringServletContainerInitializer as an entry. This time its
detecting SpringServletContainerInitializer but not detecting what defined in
@HandlesTypes
Its only working If i package all those spring mvc jars inside WEB-INF/lib then
everything started working.
I have no idea this is how the servlet specification works or its a wildfly issue but i
see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR
deployment structure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)