Fully disable Weld JSF integration in Wildfly 8.2

Question

I'm in the process of migrating a Seam 2.3 web application to EE7. Currently the application runs on Wildfly 8.2 (with Bill of Materials version of all dependencies) and runs fine, except for a performance issue: pages take minutes to load, or never do.

It appears Weld/CDI related. WeldApplication is added somewhere to the faces application chain, which causes constant failed attempts resolving BeanManager, plus occasionally some thread locking issues.

I've tried stripping the weld module out of wildfly, or run with weld module enabled but set to require-bean-descriptor. My project contains no beans.xml.

is it possible to prevent WeldApplication from being added to the faces application chain?. At least until I'm at a stage in the migration to get rid of Seam.

Workaround: My current work around is a bit of a hack but seems to do the trick. I've added my own ApplicationFactory to faces-config.xml, that basically circumvents the WeldApplication.

@Override
public Application getApplication() {
    return new MyApplication( delegate.getWrapped().getApplication() );
}

Edit #1: Stack trace with performance issue hotspot to give some context.


javax.naming.NameNotFoundException: BeanManager -- service jboss.naming.context.java.module.make.make.BeanManager

Exception 'javax.naming.NameNotFoundException' occurred in thread 'DefaultQuartzScheduler_Worker-1' at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
      at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:104)
      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
      at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
      at javax.naming.InitialContext.lookup(InitialContext.java:417)
      at javax.naming.InitialContext.lookup(InitialContext.java:417)
      at org.jboss.as.jsf.injection.weld.WeldApplication.beanManager(WeldApplication.java:105)
      - locked  (a org.jboss.as.jsf.injection.weld.WeldApplication)
      at org.jboss.as.jsf.injection.weld.WeldApplication.init(WeldApplication.java:63)
      at org.jboss.as.jsf.injection.weld.WeldApplication.delegate(WeldApplication.java:75)
      at org.jboss.as.jsf.injection.weld.ForwardingApplication.getResourceHandler(ForwardingApplication.java:262)
      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:640)
      at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
      at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
      at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
      at nl.artefact.profiling.ProfilingFilter.doFilter(ProfilingFilter.java:30)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
      at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at nl.artefact.profiling.TimingFilter.doFilter(TimingFilter.java:35)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
      at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
      at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
      at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
      at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
      at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
      at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
      at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
      at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
      at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
      at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
      at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
      at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
      at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
      at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
      at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
      at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
      at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
      at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
      at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
      at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
      at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
      at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
      at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
      at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
      at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
      at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
      at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at java.lang.Thread.run(Thread.java:745)

It's unfortunate that you didn't show a stack trace, so a detailed answer can't be given. At least, a similar problem was reported before to OmniFaces. Try replacing `WeldApplication` with one shown [here](https://github.com/omnifaces/omnifaces/issues/75#issuecomment-65004140). — BalusC, Jun 13 '15 at 22:31
Thanks BalusC! I can add a stack trace for question clarity, of what specifically? Of it failing to resolve the BeanManager? — Daan van Yperen, Jun 14 '15 at 11:16
Just the first root cause of all. Others may just be consequences which may automagically disappear once the root cause is fixed. — BalusC, Jun 15 '15 at 07:15

score 4 · Answer 1 · answered Jun 14 '15 at 13:09

4

Im not sure if this would work for Wildfly but I am using the following snippet in the <deployment> block in jboss-deployment-structure.xml to disable Weld in JBoss AS 7.2.0

<exclude-subsystems>
    <subsystem name="weld" />
</exclude-subsystems>

answered Jun 14 '15 at 13:09

DaveB

2,953
7
38
60

No luck! Also attempted with most of these: http://stackoverflow.com/questions/21756707/how-to-disable-weld-on-wildfly – Daan van Yperen Jun 15 '15 at 10:38
to clarify, Weld /is/ disabled (application can't start with Weld because of overlap Weld/Seam), but somehow the container (or something on my end) adds WeldApplication anyway. – Daan van Yperen Jun 15 '15 at 10:58
1

Hmm something must have changed since Wildfly then as this works for me under JB7.2 (it stops scanning for beans.xml on startup at least) – DaveB Jun 15 '15 at 14:02
1

TBH I haven't seen many reports of Seam Apps running successfully on Wildfly, I tried myself without success. You may be better off migrating to AS 7.x (tried and tested) then moving to EE7 from there, happy to share notes if you do – DaveB Jun 15 '15 at 14:07
No scanning or log messages here either. Just the WeldApp. Your suggestion about AS 7.x makes sense. If we fail to phase out Seam before production deadline it's certainly a path we'd consider. Thanks Dave! – Daan van Yperen Jun 16 '15 at 08:41
Hi Again @DaanvanYperen, just came across this post on SEAM forum: https://developer.jboss.org/wiki/Seam23OnWildfly89 might be worth a try – DaveB Jul 02 '15 at 22:08

Fully disable Weld JSF integration in Wildfly 8.2

1 Answers1