You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Emmanuel Touzery <em...@lit-transit.com> on 2018/07/16 11:54:57 UTC
No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Hello,
we have a TOMEE 7.0.3 application, which uses also JMS, which works
without issues. We've recently made a new version of the application
(one of the notable changes is a migration from using the JMS1.1 to the
JMS2 API).
With the new version, we have an issue, but only on our PROD
environment, where we get no errors in the catalina.out log file (but
the application doesn't work), but an error in the localhost log file,
the error being as in the title of the email, I put the info from the
localhost log file at the end of this email.
I can't put the source on github or something like that,
unfortunately. What is strange is that this error does not occur on our
staging or UAT environments, but it does occur every time (well, we
tried multiple times to restart the application and it failed
consistently) on the PROD environment. We copied the entire PROD tomee
folder on another machine and failed to reproduce the issue. We also
tried to simulate incoming traffic when restarting the application, and
run it against a backup of the PROD database... Somehow we can't
reproduce the error. We are guessing that maybe the PROD traffic is
higher than what we can simulate and some incoming message comes at just
the wrong time? But we don't know for sure.
Now, studying the issue, we realized that we used to have this in
our src/main/webapp/WEB-INF/faces-config.xml:
<?xml version="1.0" encoding="UTF-8"?><faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_1.xsd"
version="2.1"><managed-bean><managed-bean-name>login</managed-bean-name><managed-bean-class>com.lecip.tms.tms_core.application.Login</managed-bean-class><managed-bean-scope>view</managed-bean-scope></managed-bean></faces-config>
We believe the JSF version is not correct for JEE7 anymore, in
addition the managed-bean annotation is not necessary, so we changed the
file to now contain:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
</faces-config>
Could this be the cause for that error that we saw in our PROD
environment? Or you would think the root cause would be something else?
The problem is that it's pretty difficult for us to experiment with
changes since any deployment on PROD must be first validated on staging
and UAT... Any hints? Is there maybe some logging configuration flag we
could activate to get more information about the error? Or any other
place to look to get more information about the issue?
The irony is that we use JSF only for the login screen and nowhere
else...
Regards,
Emmanuel
12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
For security constraints with URL pattern [/*] only the HTTP methods
[TRACE HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods
are uncovered.
12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
java.lang.IllegalStateException: No Factories configured for this
Application. This happens if the faces-initialization does not work at
all - make sure that you properly include all configuration settings
necessary for a basic faces application and that all the necessary libs
are included. Also check the logging output of your web application and
your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact
that you use some special web-containers which do not support
registering context-listeners via TLD files and a context listener is
not setup in your web.xml.
A typical config looks like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1183)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1099)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:989)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4913)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5223)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:596)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1805)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
and later:
12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
org.apache.catalina.core.StandardHostValve.invoke Exception Processing
/tomee_tmsp/rest/transmitter/heartbeat
java.lang.NullPointerException
at
org.apache.openejb.util.classloader.URLClassLoaderFirst.shouldSkipJsf(URLClassLoaderFirst.java:530)
at
org.apache.openejb.util.classloader.URLClassLoaderFirst.shouldDelegateToTheContainer(URLClassLoaderFirst.java:146)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:163)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at
org.apache.catalina.core.StandardWrapper.servletSecurityAnnotationScan(StandardWrapper.java:1128)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:458)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at
org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Emmanuel Touzery <em...@lit-transit.com>.
Hello,
thank you for the advice. Yes it's by checking the web.xml that we
stumbled upon the prettyfaces dependency which we now removed. I'm
attaching the web.xml in case you maybe spot another oddity.
Compared to the lib/ folder from the tomee 7.0.3 distribution, we
have added in our lib folder only the postgresql driver.
In terms of the classpath, and apart from the prettyfaces
dependency which was present when we hit the issue, but that we've
removed now, all the dependencies which would be suspicious are listed
as 'provided' or 'test' in the pom, so shouldn't affect anything.
Regards,
Emmanuel
On 17/07/18 06:36, Romain Manni-Bucau wrote:
> Hi
>
> Maybe check your web.xml declaration of faces servlet, you classpath and
> webapp lib folder (some jsf api or impl leaking?) and finally ensure when
> you redeployed that you cleaned work/, conf/<instance> and other temporary
> folders in your catalina.base folder.
>
> Le mar. 17 juil. 2018 00:22, Jean-Louis Monteiro <jl...@tomitribe.com>
> a écrit :
>
>> Hi,
>>
>> Thanks for the detailed email with context and useful information.
>>
>> Is it random, or can you reproduce easily?
>> Are you using JDK 8?
>>
>> Regards
>> Jean-Louis
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
>> emmanuel.touzery@lit-transit.com> wrote:
>>
>>> Hello,
>>>
>>> we have a TOMEE 7.0.3 application, which uses also JMS, which works
>>> without issues. We've recently made a new version of the application (one
>>> of the notable changes is a migration from using the JMS1.1 to the JMS2
>>> API).
>>>
>>> With the new version, we have an issue, but only on our PROD
>>> environment, where we get no errors in the catalina.out log file (but the
>>> application doesn't work), but an error in the localhost log file, the
>>> error being as in the title of the email, I put the info from the
>> localhost
>>> log file at the end of this email.
>>>
>>> I can't put the source on github or something like that,
>>> unfortunately. What is strange is that this error does not occur on our
>>> staging or UAT environments, but it does occur every time (well, we tried
>>> multiple times to restart the application and it failed consistently) on
>>> the PROD environment. We copied the entire PROD tomee folder on another
>>> machine and failed to reproduce the issue. We also tried to simulate
>>> incoming traffic when restarting the application, and run it against a
>>> backup of the PROD database... Somehow we can't reproduce the error. We
>> are
>>> guessing that maybe the PROD traffic is higher than what we can simulate
>>> and some incoming message comes at just the wrong time? But we don't know
>>> for sure.
>>>
>>> Now, studying the issue, we realized that we used to have this in our
>>> src/main/webapp/WEB-INF/faces-config.xml:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
>>> http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
>>> 001/XMLSchema-instance" xsi:schemaLocation="http://jav
>>> a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
>>> aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
>>> anaged-bean-name>login</managed-bean-name><managed-bean-
>>> class>com.lecip.tms.tms_core.application.Login</managed-
>>> bean-class><managed-bean-scope>view</managed-bean-scope
>>>> </managed-bean></faces-config>
>>> We believe the JSF version is not correct for JEE7 anymore, in
>>> addition the managed-bean annotation is not necessary, so we changed the
>>> file to now contain:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>>> http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
>>> version="2.2">
>>> </faces-config>
>>>
>>> Could this be the cause for that error that we saw in our PROD
>>> environment? Or you would think the root cause would be something else?
>> The
>>> problem is that it's pretty difficult for us to experiment with changes
>>> since any deployment on PROD must be first validated on staging and
>> UAT...
>>> Any hints? Is there maybe some logging configuration flag we could
>> activate
>>> to get more information about the error? Or any other place to look to
>> get
>>> more information about the issue?
>>>
>>> The irony is that we use JSF only for the login screen and nowhere
>>> else...
>>>
>>> Regards,
>>>
>>> Emmanuel
>>>
>>> 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
>>>
>> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
>>> For security constraints with URL pattern [/*] only the HTTP methods
>> [TRACE
>>> HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
>>> uncovered.
>>> 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
>>> org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
>>> java.lang.IllegalStateException: No Factories configured for this
>>> Application. This happens if the faces-initialization does not work at
>> all
>>> - make sure that you properly include all configuration settings
>> necessary
>>> for a basic faces application and that all the necessary libs are
>> included.
>>> Also check the logging output of your web application and your container
>>> for any exceptions!
>>> If you did that and find nothing, the mistake might be due to the fact
>>> that you use some special web-containers which do not support registering
>>> context-listeners via TLD files and a context listener is not setup in
>> your
>>> web.xml.
>>> A typical config looks like this;
>>> <listener>
>>> <listener-class>org.apache.myfaces.webapp.StartupServletCont
>>> extListener</listener-class>
>>> </listener>
>>>
>>> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
>>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
>>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
>>> at org.apache.catalina.core.StandardWrapper.initServlet(Standar
>>> dWrapper.java:1183)
>>> at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
>>> dWrapper.java:1099)
>>> at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
>>> r.java:989)
>>> at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
>>> ardContext.java:4913)
>>> at org.apache.catalina.core.StandardContext.startInternal(Stand
>>> ardContext.java:5223)
>>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
>>> java:150)
>>> at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
>>> ainerBase.java:752)
>>> at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
>>> e.java:728)
>>> at org.apache.catalina.core.StandardHost.addChild(StandardHost.
>>> java:734)
>>> at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
>>> Config.java:596)
>>> at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
>>> HostConfig.java:1805)
>>> at java.util.concurrent.Executors$RunnableAdapter.call(
>>> Executors.java:511)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1149)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:624)
>>> at java.lang.Thread.run(Thread.java:748)
>>>
>>> and later:
>>>
>>> 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
>>> org.apache.catalina.core.StandardHostValve.invoke Exception Processing
>>> /tomee_tmsp/rest/transmitter/heartbeat
>>> java.lang.NullPointerException
>>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>>> ldSkipJsf(URLClassLoaderFirst.java:530)
>>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>>> ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
>>> at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
>>> omEEWebappClassLoader.java:163)
>>> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
>>> ebappClassLoaderBase.java:1119)
>>> at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
>>> tationScan(StandardWrapper.java:1128)
>>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
>>> uthenticatorBase.java:458)
>>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
>>> stValve.java:140)
>>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
>>> rtValve.java:79)
>>> at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
>>> turer.invoke(OpenEJBSecurityListener.java:97)
>>> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
>>> tractAccessLogValve.java:624)
>>> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
>>> EngineValve.java:87)
>>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
>>> apter.java:349)
>>> at org.apache.coyote.http11.Http11Processor.service(Http11Proce
>>> ssor.java:783)
>>> at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
>>> cessorLight.java:66)
>>> at org.apache.coyote.AbstractProtocol$ConnectionHandler.
>>> process(AbstractProtocol.java:798)
>>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>>> (NioEndpoint.java:1434)
>>> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
>>> cessorBase.java:49)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1149)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:624)
>>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
>>> run(TaskThread.java:61)
>>> at java.lang.Thread.run(Thread.java:748)
>>>
>>>
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Maybe check your web.xml declaration of faces servlet, you classpath and
webapp lib folder (some jsf api or impl leaking?) and finally ensure when
you redeployed that you cleaned work/, conf/<instance> and other temporary
folders in your catalina.base folder.
Le mar. 17 juil. 2018 00:22, Jean-Louis Monteiro <jl...@tomitribe.com>
a écrit :
> Hi,
>
> Thanks for the detailed email with context and useful information.
>
> Is it random, or can you reproduce easily?
> Are you using JDK 8?
>
> Regards
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
> emmanuel.touzery@lit-transit.com> wrote:
>
> > Hello,
> >
> > we have a TOMEE 7.0.3 application, which uses also JMS, which works
> > without issues. We've recently made a new version of the application (one
> > of the notable changes is a migration from using the JMS1.1 to the JMS2
> > API).
> >
> > With the new version, we have an issue, but only on our PROD
> > environment, where we get no errors in the catalina.out log file (but the
> > application doesn't work), but an error in the localhost log file, the
> > error being as in the title of the email, I put the info from the
> localhost
> > log file at the end of this email.
> >
> > I can't put the source on github or something like that,
> > unfortunately. What is strange is that this error does not occur on our
> > staging or UAT environments, but it does occur every time (well, we tried
> > multiple times to restart the application and it failed consistently) on
> > the PROD environment. We copied the entire PROD tomee folder on another
> > machine and failed to reproduce the issue. We also tried to simulate
> > incoming traffic when restarting the application, and run it against a
> > backup of the PROD database... Somehow we can't reproduce the error. We
> are
> > guessing that maybe the PROD traffic is higher than what we can simulate
> > and some incoming message comes at just the wrong time? But we don't know
> > for sure.
> >
> > Now, studying the issue, we realized that we used to have this in our
> > src/main/webapp/WEB-INF/faces-config.xml:
> >
> > <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
> > http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
> > 001/XMLSchema-instance" xsi:schemaLocation="http://jav
> > a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
> > aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
> > anaged-bean-name>login</managed-bean-name><managed-bean-
> > class>com.lecip.tms.tms_core.application.Login</managed-
> > bean-class><managed-bean-scope>view</managed-bean-scope
> > ></managed-bean></faces-config>
> >
> > We believe the JSF version is not correct for JEE7 anymore, in
> > addition the managed-bean annotation is not necessary, so we changed the
> > file to now contain:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> > http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
> > version="2.2">
> > </faces-config>
> >
> > Could this be the cause for that error that we saw in our PROD
> > environment? Or you would think the root cause would be something else?
> The
> > problem is that it's pretty difficult for us to experiment with changes
> > since any deployment on PROD must be first validated on staging and
> UAT...
> > Any hints? Is there maybe some logging configuration flag we could
> activate
> > to get more information about the error? Or any other place to look to
> get
> > more information about the issue?
> >
> > The irony is that we use JSF only for the login screen and nowhere
> > else...
> >
> > Regards,
> >
> > Emmanuel
> >
> > 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
> >
> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
> > For security constraints with URL pattern [/*] only the HTTP methods
> [TRACE
> > HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
> > uncovered.
> > 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
> > org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
> > java.lang.IllegalStateException: No Factories configured for this
> > Application. This happens if the faces-initialization does not work at
> all
> > - make sure that you properly include all configuration settings
> necessary
> > for a basic faces application and that all the necessary libs are
> included.
> > Also check the logging output of your web application and your container
> > for any exceptions!
> > If you did that and find nothing, the mistake might be due to the fact
> > that you use some special web-containers which do not support registering
> > context-listeners via TLD files and a context listener is not setup in
> your
> > web.xml.
> > A typical config looks like this;
> > <listener>
> > <listener-class>org.apache.myfaces.webapp.StartupServletCont
> > extListener</listener-class>
> > </listener>
> >
> > at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
> > at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
> > at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
> > at org.apache.catalina.core.StandardWrapper.initServlet(Standar
> > dWrapper.java:1183)
> > at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
> > dWrapper.java:1099)
> > at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
> > r.java:989)
> > at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
> > ardContext.java:4913)
> > at org.apache.catalina.core.StandardContext.startInternal(Stand
> > ardContext.java:5223)
> > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
> > java:150)
> > at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
> > ainerBase.java:752)
> > at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
> > e.java:728)
> > at org.apache.catalina.core.StandardHost.addChild(StandardHost.
> > java:734)
> > at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
> > Config.java:596)
> > at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
> > HostConfig.java:1805)
> > at java.util.concurrent.Executors$RunnableAdapter.call(
> > Executors.java:511)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > Executor.java:1149)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > lExecutor.java:624)
> > at java.lang.Thread.run(Thread.java:748)
> >
> > and later:
> >
> > 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
> > org.apache.catalina.core.StandardHostValve.invoke Exception Processing
> > /tomee_tmsp/rest/transmitter/heartbeat
> > java.lang.NullPointerException
> > at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> > ldSkipJsf(URLClassLoaderFirst.java:530)
> > at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> > ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
> > at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
> > omEEWebappClassLoader.java:163)
> > at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
> > ebappClassLoaderBase.java:1119)
> > at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
> > tationScan(StandardWrapper.java:1128)
> > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
> > uthenticatorBase.java:458)
> > at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
> > stValve.java:140)
> > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
> > rtValve.java:79)
> > at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
> > turer.invoke(OpenEJBSecurityListener.java:97)
> > at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
> > tractAccessLogValve.java:624)
> > at org.apache.catalina.core.StandardEngineValve.invoke(Standard
> > EngineValve.java:87)
> > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
> > apter.java:349)
> > at org.apache.coyote.http11.Http11Processor.service(Http11Proce
> > ssor.java:783)
> > at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
> > cessorLight.java:66)
> > at org.apache.coyote.AbstractProtocol$ConnectionHandler.
> > process(AbstractProtocol.java:798)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > (NioEndpoint.java:1434)
> > at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
> > cessorBase.java:49)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > Executor.java:1149)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > lExecutor.java:624)
> > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
> > run(TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:748)
> >
> >
>
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Emmanuel Touzery <em...@lit-transit.com>.
Hello,
we have two products using the same core library. On one product
we've seen this error once and a restart fixed it. On the other product
we've had to abort an upgrade, tried to restart the app more than 5
times and it would fail every time. But we can't "experiment" on that
environment because it's PROD.
We are using JDK8 yes.
Since I wrote that we also realized that we were using prettyfaces
http://www.ocpsoft.org/prettyfaces/ 3.3.3 although it was not needed
anymore (affected pom.xml, web.xml, and we had a pretty-config.xml).
That version
https://mvnrepository.com/artifact/com.ocpsoft/prettyfaces-jsf2/3.3.3 is
from 2012 so I'm hoping that may also have been related to our issues
(being too old for JEE7), but we need to follow the procedure to deploy
to PROD so I can't be 100% sure yet.
I'll also send the web.xml in a reply to another mail on this list.
Thank you for your answer!
Emmanuel
On 17/07/18 00:21, Jean-Louis Monteiro wrote:
> Hi,
>
> Thanks for the detailed email with context and useful information.
>
> Is it random, or can you reproduce easily?
> Are you using JDK 8?
>
> Regards
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
> emmanuel.touzery@lit-transit.com> wrote:
>
>> Hello,
>>
>> we have a TOMEE 7.0.3 application, which uses also JMS, which works
>> without issues. We've recently made a new version of the application (one
>> of the notable changes is a migration from using the JMS1.1 to the JMS2
>> API).
>>
>> With the new version, we have an issue, but only on our PROD
>> environment, where we get no errors in the catalina.out log file (but the
>> application doesn't work), but an error in the localhost log file, the
>> error being as in the title of the email, I put the info from the localhost
>> log file at the end of this email.
>>
>> I can't put the source on github or something like that,
>> unfortunately. What is strange is that this error does not occur on our
>> staging or UAT environments, but it does occur every time (well, we tried
>> multiple times to restart the application and it failed consistently) on
>> the PROD environment. We copied the entire PROD tomee folder on another
>> machine and failed to reproduce the issue. We also tried to simulate
>> incoming traffic when restarting the application, and run it against a
>> backup of the PROD database... Somehow we can't reproduce the error. We are
>> guessing that maybe the PROD traffic is higher than what we can simulate
>> and some incoming message comes at just the wrong time? But we don't know
>> for sure.
>>
>> Now, studying the issue, we realized that we used to have this in our
>> src/main/webapp/WEB-INF/faces-config.xml:
>>
>> <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
>> http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
>> 001/XMLSchema-instance" xsi:schemaLocation="http://jav
>> a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
>> aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
>> anaged-bean-name>login</managed-bean-name><managed-bean-
>> class>com.lecip.tms.tms_core.application.Login</managed-
>> bean-class><managed-bean-scope>view</managed-bean-scope
>>> </managed-bean></faces-config>
>> We believe the JSF version is not correct for JEE7 anymore, in
>> addition the managed-bean annotation is not necessary, so we changed the
>> file to now contain:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>> http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
>> version="2.2">
>> </faces-config>
>>
>> Could this be the cause for that error that we saw in our PROD
>> environment? Or you would think the root cause would be something else? The
>> problem is that it's pretty difficult for us to experiment with changes
>> since any deployment on PROD must be first validated on staging and UAT...
>> Any hints? Is there maybe some logging configuration flag we could activate
>> to get more information about the error? Or any other place to look to get
>> more information about the issue?
>>
>> The irony is that we use JSF only for the login screen and nowhere
>> else...
>>
>> Regards,
>>
>> Emmanuel
>>
>> 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
>> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
>> For security constraints with URL pattern [/*] only the HTTP methods [TRACE
>> HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
>> uncovered.
>> 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
>> org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
>> java.lang.IllegalStateException: No Factories configured for this
>> Application. This happens if the faces-initialization does not work at all
>> - make sure that you properly include all configuration settings necessary
>> for a basic faces application and that all the necessary libs are included.
>> Also check the logging output of your web application and your container
>> for any exceptions!
>> If you did that and find nothing, the mistake might be due to the fact
>> that you use some special web-containers which do not support registering
>> context-listeners via TLD files and a context listener is not setup in your
>> web.xml.
>> A typical config looks like this;
>> <listener>
>> <listener-class>org.apache.myfaces.webapp.StartupServletCont
>> extListener</listener-class>
>> </listener>
>>
>> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
>> at org.apache.catalina.core.StandardWrapper.initServlet(Standar
>> dWrapper.java:1183)
>> at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
>> dWrapper.java:1099)
>> at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
>> r.java:989)
>> at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
>> ardContext.java:4913)
>> at org.apache.catalina.core.StandardContext.startInternal(Stand
>> ardContext.java:5223)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
>> java:150)
>> at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
>> ainerBase.java:752)
>> at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
>> e.java:728)
>> at org.apache.catalina.core.StandardHost.addChild(StandardHost.
>> java:734)
>> at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
>> Config.java:596)
>> at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
>> HostConfig.java:1805)
>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:624)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> and later:
>>
>> 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
>> org.apache.catalina.core.StandardHostValve.invoke Exception Processing
>> /tomee_tmsp/rest/transmitter/heartbeat
>> java.lang.NullPointerException
>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>> ldSkipJsf(URLClassLoaderFirst.java:530)
>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>> ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
>> at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
>> omEEWebappClassLoader.java:163)
>> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
>> ebappClassLoaderBase.java:1119)
>> at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
>> tationScan(StandardWrapper.java:1128)
>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
>> uthenticatorBase.java:458)
>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
>> stValve.java:140)
>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
>> rtValve.java:79)
>> at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
>> turer.invoke(OpenEJBSecurityListener.java:97)
>> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
>> tractAccessLogValve.java:624)
>> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
>> EngineValve.java:87)
>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
>> apter.java:349)
>> at org.apache.coyote.http11.Http11Processor.service(Http11Proce
>> ssor.java:783)
>> at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
>> cessorLight.java:66)
>> at org.apache.coyote.AbstractProtocol$ConnectionHandler.
>> process(AbstractProtocol.java:798)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>> (NioEndpoint.java:1434)
>> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
>> cessorBase.java:49)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:624)
>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
>> run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:748)
>>
>>
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hi,
Thanks for the detailed email with context and useful information.
Is it random, or can you reproduce easily?
Are you using JDK 8?
Regards
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jul 16, 2018 at 1:54 PM, Emmanuel Touzery <
emmanuel.touzery@lit-transit.com> wrote:
> Hello,
>
> we have a TOMEE 7.0.3 application, which uses also JMS, which works
> without issues. We've recently made a new version of the application (one
> of the notable changes is a migration from using the JMS1.1 to the JMS2
> API).
>
> With the new version, we have an issue, but only on our PROD
> environment, where we get no errors in the catalina.out log file (but the
> application doesn't work), but an error in the localhost log file, the
> error being as in the title of the email, I put the info from the localhost
> log file at the end of this email.
>
> I can't put the source on github or something like that,
> unfortunately. What is strange is that this error does not occur on our
> staging or UAT environments, but it does occur every time (well, we tried
> multiple times to restart the application and it failed consistently) on
> the PROD environment. We copied the entire PROD tomee folder on another
> machine and failed to reproduce the issue. We also tried to simulate
> incoming traffic when restarting the application, and run it against a
> backup of the PROD database... Somehow we can't reproduce the error. We are
> guessing that maybe the PROD traffic is higher than what we can simulate
> and some incoming message comes at just the wrong time? But we don't know
> for sure.
>
> Now, studying the issue, we realized that we used to have this in our
> src/main/webapp/WEB-INF/faces-config.xml:
>
> <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
> http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
> 001/XMLSchema-instance" xsi:schemaLocation="http://jav
> a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
> aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
> anaged-bean-name>login</managed-bean-name><managed-bean-
> class>com.lecip.tms.tms_core.application.Login</managed-
> bean-class><managed-bean-scope>view</managed-bean-scope
> ></managed-bean></faces-config>
>
> We believe the JSF version is not correct for JEE7 anymore, in
> addition the managed-bean annotation is not necessary, so we changed the
> file to now contain:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
> version="2.2">
> </faces-config>
>
> Could this be the cause for that error that we saw in our PROD
> environment? Or you would think the root cause would be something else? The
> problem is that it's pretty difficult for us to experiment with changes
> since any deployment on PROD must be first validated on staging and UAT...
> Any hints? Is there maybe some logging configuration flag we could activate
> to get more information about the error? Or any other place to look to get
> more information about the issue?
>
> The irony is that we use JSF only for the login screen and nowhere
> else...
>
> Regards,
>
> Emmanuel
>
> 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
> For security constraints with URL pattern [/*] only the HTTP methods [TRACE
> HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
> uncovered.
> 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
> org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
> java.lang.IllegalStateException: No Factories configured for this
> Application. This happens if the faces-initialization does not work at all
> - make sure that you properly include all configuration settings necessary
> for a basic faces application and that all the necessary libs are included.
> Also check the logging output of your web application and your container
> for any exceptions!
> If you did that and find nothing, the mistake might be due to the fact
> that you use some special web-containers which do not support registering
> context-listeners via TLD files and a context listener is not setup in your
> web.xml.
> A typical config looks like this;
> <listener>
> <listener-class>org.apache.myfaces.webapp.StartupServletCont
> extListener</listener-class>
> </listener>
>
> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
> at org.apache.catalina.core.StandardWrapper.initServlet(Standar
> dWrapper.java:1183)
> at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
> dWrapper.java:1099)
> at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
> r.java:989)
> at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
> ardContext.java:4913)
> at org.apache.catalina.core.StandardContext.startInternal(Stand
> ardContext.java:5223)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
> java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
> ainerBase.java:752)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
> e.java:728)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.
> java:734)
> at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
> Config.java:596)
> at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
> HostConfig.java:1805)
> at java.util.concurrent.Executors$RunnableAdapter.call(
> Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>
> and later:
>
> 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
> org.apache.catalina.core.StandardHostValve.invoke Exception Processing
> /tomee_tmsp/rest/transmitter/heartbeat
> java.lang.NullPointerException
> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> ldSkipJsf(URLClassLoaderFirst.java:530)
> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
> at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
> omEEWebappClassLoader.java:163)
> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
> ebappClassLoaderBase.java:1119)
> at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
> tationScan(StandardWrapper.java:1128)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
> uthenticatorBase.java:458)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
> stValve.java:140)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
> rtValve.java:79)
> at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
> turer.invoke(OpenEJBSecurityListener.java:97)
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
> tractAccessLogValve.java:624)
> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
> EngineValve.java:87)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
> apter.java:349)
> at org.apache.coyote.http11.Http11Processor.service(Http11Proce
> ssor.java:783)
> at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
> cessorLight.java:66)
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.
> process(AbstractProtocol.java:798)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> (NioEndpoint.java:1434)
> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
> cessorBase.java:49)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:624)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
> run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
>
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Emmanuel Touzery <em...@lit-transit.com>.
Hello,
thank you for the answer! To be clear, by duplicate jars, you mean
in the tomee lib/ folder, or the pom.xml, correct?
If that's what you mean, I think both are OK, as I wrote in another
email to this list, in the lib/ folder we've only added the postgresql
driver, and in the pom.xml the only non-test or provided dependency
which seemed related was the prettyfaces library, which could have
possibly caused the issue, and that we removed now.
Regards,
Emmanuel
On 17/07/18 06:32, Gurkan Erdogdu wrote:
> Hello Emmanuel
> This exception sometimes (generally) occurred because of duplicate JSF jars
> in your application and some classloader issues. Could you please check
> your application that has any duplicate JSF (myfaces for example) JARS?
> Regards.
> Gurkan
>
> On Mon, Jul 16, 2018 at 2:54 PM, Emmanuel Touzery <
> emmanuel.touzery@lit-transit.com> wrote:
>
>> Hello,
>>
>> we have a TOMEE 7.0.3 application, which uses also JMS, which works
>> without issues. We've recently made a new version of the application (one
>> of the notable changes is a migration from using the JMS1.1 to the JMS2
>> API).
>>
>> With the new version, we have an issue, but only on our PROD
>> environment, where we get no errors in the catalina.out log file (but the
>> application doesn't work), but an error in the localhost log file, the
>> error being as in the title of the email, I put the info from the localhost
>> log file at the end of this email.
>>
>> I can't put the source on github or something like that,
>> unfortunately. What is strange is that this error does not occur on our
>> staging or UAT environments, but it does occur every time (well, we tried
>> multiple times to restart the application and it failed consistently) on
>> the PROD environment. We copied the entire PROD tomee folder on another
>> machine and failed to reproduce the issue. We also tried to simulate
>> incoming traffic when restarting the application, and run it against a
>> backup of the PROD database... Somehow we can't reproduce the error. We are
>> guessing that maybe the PROD traffic is higher than what we can simulate
>> and some incoming message comes at just the wrong time? But we don't know
>> for sure.
>>
>> Now, studying the issue, we realized that we used to have this in our
>> src/main/webapp/WEB-INF/faces-config.xml:
>>
>> <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
>> http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
>> 001/XMLSchema-instance" xsi:schemaLocation="http://jav
>> a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
>> aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
>> anaged-bean-name>login</managed-bean-name><managed-bean-
>> class>com.lecip.tms.tms_core.application.Login</managed-
>> bean-class><managed-bean-scope>view</managed-bean-scope
>>> </managed-bean></faces-config>
>> We believe the JSF version is not correct for JEE7 anymore, in
>> addition the managed-bean annotation is not necessary, so we changed the
>> file to now contain:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>> http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
>> version="2.2">
>> </faces-config>
>>
>> Could this be the cause for that error that we saw in our PROD
>> environment? Or you would think the root cause would be something else? The
>> problem is that it's pretty difficult for us to experiment with changes
>> since any deployment on PROD must be first validated on staging and UAT...
>> Any hints? Is there maybe some logging configuration flag we could activate
>> to get more information about the error? Or any other place to look to get
>> more information about the issue?
>>
>> The irony is that we use JSF only for the login screen and nowhere
>> else...
>>
>> Regards,
>>
>> Emmanuel
>>
>> 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
>> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
>> For security constraints with URL pattern [/*] only the HTTP methods [TRACE
>> HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
>> uncovered.
>> 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
>> org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
>> java.lang.IllegalStateException: No Factories configured for this
>> Application. This happens if the faces-initialization does not work at all
>> - make sure that you properly include all configuration settings necessary
>> for a basic faces application and that all the necessary libs are included.
>> Also check the logging output of your web application and your container
>> for any exceptions!
>> If you did that and find nothing, the mistake might be due to the fact
>> that you use some special web-containers which do not support registering
>> context-listeners via TLD files and a context listener is not setup in your
>> web.xml.
>> A typical config looks like this;
>> <listener>
>> <listener-class>org.apache.myfaces.webapp.StartupServletCont
>> extListener</listener-class>
>> </listener>
>>
>> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
>> at org.apache.catalina.core.StandardWrapper.initServlet(Standar
>> dWrapper.java:1183)
>> at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
>> dWrapper.java:1099)
>> at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
>> r.java:989)
>> at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
>> ardContext.java:4913)
>> at org.apache.catalina.core.StandardContext.startInternal(Stand
>> ardContext.java:5223)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
>> java:150)
>> at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
>> ainerBase.java:752)
>> at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
>> e.java:728)
>> at org.apache.catalina.core.StandardHost.addChild(StandardHost.
>> java:734)
>> at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
>> Config.java:596)
>> at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
>> HostConfig.java:1805)
>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:624)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> and later:
>>
>> 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
>> org.apache.catalina.core.StandardHostValve.invoke Exception Processing
>> /tomee_tmsp/rest/transmitter/heartbeat
>> java.lang.NullPointerException
>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>> ldSkipJsf(URLClassLoaderFirst.java:530)
>> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
>> ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
>> at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
>> omEEWebappClassLoader.java:163)
>> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
>> ebappClassLoaderBase.java:1119)
>> at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
>> tationScan(StandardWrapper.java:1128)
>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
>> uthenticatorBase.java:458)
>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
>> stValve.java:140)
>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
>> rtValve.java:79)
>> at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
>> turer.invoke(OpenEJBSecurityListener.java:97)
>> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
>> tractAccessLogValve.java:624)
>> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
>> EngineValve.java:87)
>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
>> apter.java:349)
>> at org.apache.coyote.http11.Http11Processor.service(Http11Proce
>> ssor.java:783)
>> at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
>> cessorLight.java:66)
>> at org.apache.coyote.AbstractProtocol$ConnectionHandler.
>> process(AbstractProtocol.java:798)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>> (NioEndpoint.java:1434)
>> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
>> cessorBase.java:49)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1149)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:624)
>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
>> run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:748)
>>
>>
Re: No Factories configured for this Application. This happens if the
faces-initialization does not work at all
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hello Emmanuel
This exception sometimes (generally) occurred because of duplicate JSF jars
in your application and some classloader issues. Could you please check
your application that has any duplicate JSF (myfaces for example) JARS?
Regards.
Gurkan
On Mon, Jul 16, 2018 at 2:54 PM, Emmanuel Touzery <
emmanuel.touzery@lit-transit.com> wrote:
> Hello,
>
> we have a TOMEE 7.0.3 application, which uses also JMS, which works
> without issues. We've recently made a new version of the application (one
> of the notable changes is a migration from using the JMS1.1 to the JMS2
> API).
>
> With the new version, we have an issue, but only on our PROD
> environment, where we get no errors in the catalina.out log file (but the
> application doesn't work), but an error in the localhost log file, the
> error being as in the title of the email, I put the info from the localhost
> log file at the end of this email.
>
> I can't put the source on github or something like that,
> unfortunately. What is strange is that this error does not occur on our
> staging or UAT environments, but it does occur every time (well, we tried
> multiple times to restart the application and it failed consistently) on
> the PROD environment. We copied the entire PROD tomee folder on another
> machine and failed to reproduce the issue. We also tried to simulate
> incoming traffic when restarting the application, and run it against a
> backup of the PROD database... Somehow we can't reproduce the error. We are
> guessing that maybe the PROD traffic is higher than what we can simulate
> and some incoming message comes at just the wrong time? But we don't know
> for sure.
>
> Now, studying the issue, we realized that we used to have this in our
> src/main/webapp/WEB-INF/faces-config.xml:
>
> <?xml version="1.0" encoding="UTF-8"?><faces-config xmlns="
> http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2
> 001/XMLSchema-instance" xsi:schemaLocation="http://jav
> a.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/jav
> aee/web-facesconfig_2_1.xsd" version="2.1"><managed-bean><m
> anaged-bean-name>login</managed-bean-name><managed-bean-
> class>com.lecip.tms.tms_core.application.Login</managed-
> bean-class><managed-bean-scope>view</managed-bean-scope
> ></managed-bean></faces-config>
>
> We believe the JSF version is not correct for JEE7 anymore, in
> addition the managed-bean annotation is not necessary, so we changed the
> file to now contain:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
> version="2.2">
> </faces-config>
>
> Could this be the cause for that error that we saw in our PROD
> environment? Or you would think the root cause would be something else? The
> problem is that it's pretty difficult for us to experiment with changes
> since any deployment on PROD must be first validated on staging and UAT...
> Any hints? Is there maybe some logging configuration flag we could activate
> to get more information about the error? Or any other place to look to get
> more information about the issue?
>
> The irony is that we use JSF only for the login screen and nowhere
> else...
>
> Regards,
>
> Emmanuel
>
> 12-Jul-2018 17:44:04.335 SEVERE [localhost-startStop-1]
> org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
> For security constraints with URL pattern [/*] only the HTTP methods [TRACE
> HEAD DELETE POST GET OPTIONS PUT] are covered. All other methods are
> uncovered.
> 12-Jul-2018 17:44:22.078 SEVERE [localhost-startStop-1]
> org.apache.catalina.core.ApplicationContext.log StandardWrapper.Throwable
> java.lang.IllegalStateException: No Factories configured for this
> Application. This happens if the faces-initialization does not work at all
> - make sure that you properly include all configuration settings necessary
> for a basic faces application and that all the necessary libs are included.
> Also check the logging output of your web application and your container
> for any exceptions!
> If you did that and find nothing, the mistake might be due to the fact
> that you use some special web-containers which do not support registering
> context-listeners via TLD files and a context listener is not setup in your
> web.xml.
> A typical config looks like this;
> <listener>
> <listener-class>org.apache.myfaces.webapp.StartupServletCont
> extListener</listener-class>
> </listener>
>
> at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
> at org.apache.catalina.core.StandardWrapper.initServlet(Standar
> dWrapper.java:1183)
> at org.apache.catalina.core.StandardWrapper.loadServlet(Standar
> dWrapper.java:1099)
> at org.apache.catalina.core.StandardWrapper.load(StandardWrappe
> r.java:989)
> at org.apache.catalina.core.StandardContext.loadOnStartup(Stand
> ardContext.java:4913)
> at org.apache.catalina.core.StandardContext.startInternal(Stand
> ardContext.java:5223)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.
> java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(Cont
> ainerBase.java:752)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBas
> e.java:728)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.
> java:734)
> at org.apache.catalina.startup.HostConfig.deployDescriptor(Host
> Config.java:596)
> at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(
> HostConfig.java:1805)
> at java.util.concurrent.Executors$RunnableAdapter.call(
> Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>
> and later:
>
> 12-Jul-2018 17:44:23.083 SEVERE [http-nio-8080-exec-3]
> org.apache.catalina.core.StandardHostValve.invoke Exception Processing
> /tomee_tmsp/rest/transmitter/heartbeat
> java.lang.NullPointerException
> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> ldSkipJsf(URLClassLoaderFirst.java:530)
> at org.apache.openejb.util.classloader.URLClassLoaderFirst.shou
> ldDelegateToTheContainer(URLClassLoaderFirst.java:146)
> at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(T
> omEEWebappClassLoader.java:163)
> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(W
> ebappClassLoaderBase.java:1119)
> at org.apache.catalina.core.StandardWrapper.servletSecurityAnno
> tationScan(StandardWrapper.java:1128)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
> uthenticatorBase.java:458)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
> stValve.java:140)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
> rtValve.java:79)
> at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCap
> turer.invoke(OpenEJBSecurityListener.java:97)
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
> tractAccessLogValve.java:624)
> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
> EngineValve.java:87)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
> apter.java:349)
> at org.apache.coyote.http11.Http11Processor.service(Http11Proce
> ssor.java:783)
> at org.apache.coyote.AbstractProcessorLight.process(AbstractPro
> cessorLight.java:66)
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.
> process(AbstractProtocol.java:798)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> (NioEndpoint.java:1434)
> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro
> cessorBase.java:49)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:624)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
> run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
>