Why do we need dependency to subsystems which are not used ?

[nick.sree]

Hi,

     I have a genuine question regarding subsystem, which i haven't got any answer from web so i would like to ask this to the wildfly or jboss expert.

1) We are not using ejb at all, then should we have to keep ejb3 subsystem in standalone.xml ? If i remove it, does it going to affect core server functioning in anyway ?  like does wildfly or jboss web console depends on ejb or jsf ?

2) Similarly, we are not using JSF or Weld, should we need to keep those subsystems ?

3) I have tried removing JSF subsystem, there after i was getting error for jstl, jsp, api. Why jstl, jsp or api module load depends on JSF ?

I was getting serious drag in deployment time when JSF subsystem was on, somewhere it stuck almost 30 to 45 sec in Mojarra for each war. We are deploying an ear system consist of 20+ web and respective jars where no ejb, jsf, weld is in use

Can someone help me how can i customize my standalone.xml and wildfly not to use JSF, ejb3, Weld ?

[jameslivingston]

Being stuck for 30-45 seconds in Mojarra sounds unusual, could you post a thread dump showing the thread(s) that were stuck there?

I'm pretty sure you can remove the EJB, JSF and Weld with no effects elsewhere. The management console does not use them. What JSTL/JSP errors were you seeing afterwards?

[nick.sree]

Thanks James..

I will replicate the Mojarra issue and will post the thread dump here in sometime...

When i remove EJB and Weld there is no issue, and glad to hear it won't break other internal's. Regarding JSTL/JSP the moment i remove JFS from the subsystem its showing NoClassDefFoundError for jstl when ever i try to access any jsp, I will post the thread dump and the Exception stacktrace in sometimes.

After removing

<extension module="org.jboss.as.jsf"/>

and

<subsystem xmlns="urn:jboss:domain:jsf:1.0"/>

Then we gets.

Caused by: java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config

  at org.springframework.web.servlet.support.JstlUtils.exposeLocalizationContext(JstlUtils.java:101)

  at org.springframework.web.servlet.view.tiles3.TilesView.renderMergedOutputModel(TilesView.java:125)

  at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:303)

  at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1244)

  at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1027)

  at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:971)

I have taken the thread dump for JSF Mojarra, Nothing seems to be blocking but the configuration check is taking longer time

2015-08-11 13:01:07,419 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 104) Initializing Mojarra 2.2.11-jbossorg-1 20150505-1501 for context '/portal' at this line it some times spending min 15-20 seconds or more.

We are using Wildfly.9.0.0.Final, we were not facing this delay in CR2.

[ctomc]

well no change between CR2 and Final would suggest the behavior change you are seeing.

see https://github.com/wildfly/wildfly/compare/9.0.0.CR2...9.0.0.Final

the CNFE looks like a bug, but looking a the code it would only be problematic if you are using JSLT api inside EAR/ejb-jar directly and not in war modules.

i created [WFLY-5077] javax.servlet.jstl.api module is not properly added for all appropriate deployments. - JBoss Issue Tracker to address that

[nick.sree]

Hi Tomaz,

                 Sorry, its by mistake not CR2 its CR1 (we were not having issues). We don't have EJB's, wildfly started as usual but when we access the login page (its a jsp) we are getting NCDF not CNFE