I'm currently migrating old web apps from JBoss As 4.2.2 to 6.0.0 (AS6). In AS6 we have a proprietary format for logging applications through a file named jboss-logging.xml.
After read some stuff (http://community.jboss.org/wiki/SeparatingApplicationLogs) reach the conclusion that "(...)starting with JBoss AS 6.0.0.M2 the ability to log to separate log files, per application, will be implemented in a different way" and also that the documentation "(...) will be updated with more details, once the implementation is ready".
However I was able to create the specific application log files in my server/log dir, it was done using the main joboss-logging.xml file in the server/deploy dir. This is not compatible with the modularity my applications demand.
So here the problem when I create a jboss-logging.xml e my WEB-INF dir for my app whit this configuration:
<?xml version="1.0" encoding="UTF-8"?>
<logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0" context="myApp">
<define-context name="myApp" />
<periodic-rotating-file-handler
file-name="${jboss.server.log.dir}/myApp.log"
name="WEBAPP" autoflush="true" append="true" suffix=".yyyy-MM-dd">
<error-manager><only-once/></error-manager>
<formatter>
<pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
</formatter>
</periodic-rotating-file-handler>
<root-logger>
<!-- Set the root logger priority via a system property, with a default value. -->
<level name="${jboss.server.log.threshold:INFO}"/>
<handlers>
<handler-ref name="WEBAPP"/>
</handlers>
</root-logger>
</logging>
I get the following error when my app starts:
8:57:07,765 ERROR [AbstractKernelController] Error installing to Configured: name=Logging:REGISTRATION:myApp:Anonymous-0 state=Instantiated: java.lang.RuntimeException: Error configuring property: selector for Logging:REGISTRATION:myApp:Anonymous-0
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
(...)
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setSelector for target org.jboss.logging.metadata.ClassLoaderRegistrationHelper#1a4eb51 expected=[org.jboss.logmanager.ClassLoaderLogContextSelector] actual=[org.jboss.logmanager.LogContextSelectorService]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.GA]
... 64 more
I will be grateful for any kind of info or direction on this subject, even one that represents using a complete different approach to logging in AS6. Although I feel I'm getting closer to the solution... Thank you in advance.
The post here is also mine
This is a bug, it's reported here:
https://issues.jboss.org/browse/JBLOGGING-56
I tried the workaround that they mention, but couldn't get it to work either. Unfortunately, new logging framework in JBoss AS 6 seems to be very buggy and undocumented at this moment.
You can look here
http://lea-ka.blogspot.com/2011/09/assorted-facts-about-jboss-fact-3-how.html
and here
http://lea-ka.blogspot.com/2011/09/dynamically-changing-app-specific.html.
01.12.2011. Update:
Even better look here to see why you do not want to use it: http://lea-ka.blogspot.com/2011/12/assorted-facts-about-jboss-fact-4-per.html
Related
I am getting following error logs related to io.undertow.request package.
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:153)
at io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:874)
at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:379)
at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:247)
at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:588)
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:120)
at io.undertow.conduits.DeflatingStreamSinkConduit.performFlushIfRequired(DeflatingStreamSinkConduit.java:418)
at io.undertow.conduits.DeflatingStreamSinkConduit.flush(DeflatingStreamSinkConduit.java:348)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:605)
In this case, it is not necessary to see those errors in my wildfly log. I need to exclude this package from the logging.Is there anyway that I can make a configuration for it?
If you dont want any logging from io.undertow.request then add below tag in standalone-*.xml file in logging subsystem:
<logger category="io.undertow.request">
<level name="OFF"/>
</logger>
I am using websphere liberty with java 8 docker image but after trying everything. i am unable to load my own bundled libs instead of liberty built-in as per my assumption and from logs
My jsp and other libs are in WEB-INF/lib directory inside my war file
Here is the config I am using
<?xml version="1.0" encoding="UTF-8"?>
<server description="Default server">
<!-- Enable features -->
<featureManager>
<feature>javaee-8.0</feature>
<feature>microProfile-3.0</feature>
</featureManager>
<basicRegistry id="basic" realm="BasicRealm">
<!-- <user name="yourUserName" password="" /> -->
</basicRegistry>
<logging traceSpecification="com.ibm.ws.webcontainer*=all:com.ibm.wsspi.webcontainer*=all:HTTPChannel=all:GenericBNF=all:HTTPDispatcher=all"
traceFileName="trace.log"
maxFileSize="20"
maxFiles="10"
traceFormat="BASIC" />
<library id="OJDBC5Lib">
<fileset dir="/config/ojdbc5.jar" includes="ojdbc5.jar"/>
</library>
<!-- To allow access to this server from a remote client host="*" has been added to the following element -->
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="9080"
httpsPort="9443" />
<webApplication id="e-app" name="e-app" location="/apps/e-app.war" contextRoot="/e-app">
<classloader delegation="parentLast" />
</webApplication>
When I run. the application I get an exception
[AUDIT ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 14.831 seconds.
[ERROR ] SRVE0271E: Uncaught init() exception created by servlet [Faces Servlet] in application [e-app]: java.lang.IllegalStateException: Could not find ba
ckup for factory javax.faces.context.FacesContextFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1004)
at [internal classes]
[ERROR ] SRVE0276E: Error while initializing Servlet [Faces Servlet]: javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:360)
at [internal classes]
Caused by: java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1004)
... 1 more
Can someone tell me what needs to be done in config to make it work
The problem here is that the javaee-8.0 feature includes the jsf-2.3 feature that includes the JSF APIs and Liberty's JSF implementation. In order to provide your own JSF implementation, you will need to remove the jsf-2.3 feature and use the jsfContainer-2.3 feature instead. This doc has more details: https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_jsf23_implementations.html
The javaee-8.0 feature includes a ton of features - many of which you may not need, but unfortunately you will need to specify all of the features that you do need (in addition to jsfContainer-2.3). So your server.xml's <featureManager> element might end up looking something like this:
<featureManager>
<!-- webprofile-8.0 features but using jsfContainer instead of jsf -->
<feature>appSecurity-3.0</feature>
<feature>beanValidation-2.0</feature>
<feature>cdi-2.0</feature>
<feature>ejbLite-3.2</feature>
<feature>el-3.0</feature>
<feature>jaspic-1.1</feature>
<feature>jaxrs-2.1</feature>
<feature>jdbc-4.2</feature>
<feature>jndi-1.0</feature>
<feature>jpa-2.2</feature>
<feature>jsfContainer-2.3</feature>
<feature>jsonb-1.0</feature>
<feature>jsonp-1.1</feature>
<feature>jsp-2.3</feature>
<feature>managedBeans-1.0</feature>
<feature>servlet-4.0</feature>
<feature>transaction-1.2</feature>
<feature>websocket-1.1</feature>
<!-- full profile 8 features not in web profile -->
<feature>appClientSupport-1.0</feature>
<feature>batch-1.0</feature>
<feature>concurrent-1.0</feature>
<feature>ejb-3.2</feature>
<feature>jacc-1.5</feature>
<feature>javaMail-1.6</feature>
<feature>javax.persistence.base-2.2</feature>
<feature>jaxws-2.2</feature>
<feature>jca-1.7</feature>
<feature>jcaInboundSecurity-1.0</feature>
<feature>jms-2.0</feature>
<feature>j2eeManagement-1.1</feature>
<feature>wasJmsClient-2.0</feature>
<feature>wasJmsSecurity-1.0</feature>
<feature>wasJmsServer-1.0</feature>
</featureManager>
It's a huge list, so you'll likely want to prune it a little (for example, remove all JMS-related feature if you are not using JMS). But once you swap jsf-2.3 for jsfContainer-2.3 then Liberty should find and use the JSF implementation in your app - and you shouldn't need to use parentLast delegation in your app either.
I'm migrating a legacy app to Spring Boot and I've faced with the following problem: when I start the app it fails because of the following exception:
Exception in thread "main" java.lang.IllegalStateException: Logback
configuration error detected: ERROR in
ch.qos.logback.core.joran.spi.Interpreter#10:21 - no applicable action
for [BufferedIO], current ElementPath is
[[configuration][appender][BufferedIO]]
ERROR in ch.qos.logback.core.joran.spi.Interpreter#11:25 - no
applicable action for [ImmediateFlush], current ElementPath is
[[configuration][appender][ImmediateFlush]]
at
org.springframework.boot.logging.logback.LogbackLoggingSystem.loadConfiguration(LogbackLoggingSystem.java:161)
at
org.springframework.boot.logging.logback.LogbackLoggingSystem.reinitialize(LogbackLoggingSystem.java:207)
at
org.springframework.boot.logging.AbstractLoggingSystem.initializeWithConventions(AbstractLoggingSystem.java:65)
at
org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:50)
at
org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:114)
at
org.springframework.boot.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:299)
at
org.springframework.boot.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:272)
at
org.springframework.boot.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:235)
at
org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:208)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:167)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:122)
at
org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:72)
at
org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:54)
at
org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:338)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:309)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:1187)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:1176)
at com.some_company.SomeApp.main(SomeApp.java:28)
So Logback can't resolve BuferredIO and ImmediateFlush properties. I've tried to see their docs but it seems to be out-of-date as it says such properties exist + I've found e.g. for OutputStreamAppender that it doesn't have the immediateFlush property while according to the docs it should.
I can't find any info on if Logback still supports the following properties now. Could you please help and suggest some ideas on how I can achieve the same result as with the properties previously? Maybe they are somewhere else:)
Thank you very much!:)
UPDATE: Adding a Logback configuration snapshot:
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${logdir}/some-app.log</File>
<Append>true</Append>
<BufferedIO>false</BufferedIO>
<ImmediateFlush>true</ImmediateFlush>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<FileNamePattern>${logdir}/archive-some-app.%i.log.zip</FileNamePattern>
<MinIndex>1</MinIndex>
<MaxIndex>10</MaxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<MaxFileSize>20MB</MaxFileSize>
</triggeringPolicy>
<encoder class="net.logstash.logback.encoder.LogstashEncoder">
<fieldNames>
<timestamp>timestamp</timestamp>
</fieldNames>
</encoder>
</appender>
Logback version is 1.1.7 (was previously before the migration)
Although ImmediateFlush is a valid configuration property for OutputStreamAppender (which RollingFileAppender extends) in the latest version of Logback (and hence is referenced in the latest docs) this was only added to OutputStreamAppender here in Feb 2017. So, immediateFlush is not a valid property of OutputStreamAppender (and hence is inaccessible from RollingFileAppender) in v1.1.7
This explains the following error:
no applicable action for [ImmediateFlush], current ElementPath is [[configuration][appender][ImmediateFlush]]
BufferedIO is an old configuration property which is no longer supported by Logback.
This explains the following error:
no applicable action for [BufferedIO], current ElementPath is [[configuration][appender][BufferedIO]]
In summary, you might consider upgrading to the latest Logback and just remove <BufferedIO>false</BufferedIO>. Or, continue to use v1.1.7 and remove both of these: <BufferedIO>false</BufferedIO> and <ImmediateFlush>true</ImmediateFlush>.
I am using spring boot : 1.4.0. With the following configuration in logback,I am trying to send a mail to gmail.
<appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">
<smtpHost>smtp.gmail.com</smtpHost>
<smtpPort>25</smtpPort>
<SSL>true</SSL>
<username>*</username>
<password>*</password>
<to>*</to>
<from>*</from>
<subject>TESTING: %logger{20} - %m</subject>
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>%date %-5level %logger{35} - %message%n</pattern>
</layout>
</appender>
<root level="DEBUG">
<appender-ref ref="EMAIL" />
</root>
But getting the following exception
Exception in thread "main" java.lang.IllegalStateException: Logback configuration error detected:
ERROR in ch.qos.logback.core.joran.action.NestedBasicPropertyIA - Unexpected aggregationType AS_BASIC_PROPERTY_COLLECTION
at org.springframework.boot.logging.logback.LogbackLoggingSystem.loadConfiguration(LogbackLoggingSystem.java:152)
at org.springframework.boot.logging.logback.LogbackLoggingSystem.reinitialize(LogbackLoggingSystem.java:195)
at org.springframework.boot.logging.AbstractLoggingSystem.initializeWithConventions(AbstractLoggingSystem.java:65)
at org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:50)
at org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:106)
at org.springframework.boot.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:289)
at org.springframework.boot.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:262)
at org.springframework.boot.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:231)
at org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:207)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:166)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:138)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:121)
at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:68)
at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:54)
at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:336)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:308)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1182)
Main program Spring Boot
public static void main(String[] args) {
System.setProperty("log.name", "dynamicLogs");
logger.debug("Start running debug");
SpringApplication.run(WebApplication.class, args);
logger.error("Start running error");
}
. While if i try to run a test java program it runs fine. Not sure what the issue is while running with spring boot.Missing any properties to be set?
There are some problems with logback version 1.1.7. Spring Boot 1.3.4 and 1.3.5 depend on this version, so 1.4.0 might also.
You can try forcing an older/newer version of logback.
More information in https://github.com/logstash/logstash-logback-encoder/issues/160
You are encountering issue with the to field. See THIS bug report. You will have to wait for 1.1.8 or downgrade to version 1.1.6.
With Spring Boot you can just do the following
<properties>
<logback.version>1.1.6</logback.version>
</properties>
I have a web service project implemented in java and it also contains jsp pages. I deploy it on jetty 8.1.5 on my machine and it works normally. But when I deploy on a windows server 2003 with jetty 8.1.3 it gives this exception:
org.apache.jasper.el.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
This is the full trace:
java.lang.ClassCastException: org.apache.jasper.el.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
at org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1002)
at org.apache.jsp.home.index_jsp._jspService(org.apache.jsp.home.index_jsp:52)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:542)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:557)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:499)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
at java.lang.Thread.run(Unknown Source)
Any idea what is this exception and how to fix it?
That can happen if your webapp ships with servletcontainer-specific JAR files such as jasper.jar, jetty.jar servlet.jar, etc in the /WEB-INF/lib for some unclear reason. This is in turn conflicting with with a different versioned JAR file on the target servletcontainer.
Remove that servletcontainer-specific JAR file from your webapp's /WEB-INF/lib. It doesn't belong there. It's supposed to be already supplied by the servletcontainer itself.
See also:
How do I import the javax.servlet API in my Eclipse project? (this doesn't exactly answer your concrete problem, but this is at least technically the same core problem which should give you a better understanding of this common starter's mistake)
IF you are using maven (I asked on a comment without response), you can avoid conflictive jars using a "provided" scope. When you deploy it for production, jars are not included.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jsp-api</artifactId>
<version>2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
I'm not sure about jetty's jars but it's probably the same.
IF you are NOT using maven, you should move your conflictive jars (servlets and jetty) to your develompent container lib folder and remove them from your applications WEB-INF/lib folder.
If the folder /WEB-INF/lib of your webapp does not contain a jasper.jar (see BalusC' answer), please check whether another webapp is running in your container. Then check if that webapp contains a jasper.jar in its folder /WEB-INF/lib. This happened to us. Be removing jasper.jar from those webapps (sic!), the problem could be solved. Obviously, the webapps are not that isolated for meach other as they should be. The problem appeared as we switched from Tomcat6 to Tomcat7 and jasper.jar (version 6) was bundled accidently with one of our webapps.
Apart from the answers mentioned watch out for one more thing. I've another war deployed under the same Tomcat 7.0.42 instance which had a jsp-2.1-6.0.2.jar under its WEB-INF/lib. This jar has org.apache.jasper.runtime.ELContextImpl class.
My understanding was that each webapp has its own classloader and the class files loaded by one webapp is not visible to the other webapp. Still as nothing was working I removed the other war which had that jsp.jar and restarted my tomcat and to my surprise the exception was no longer coming. Somehow this class was getting loaded and causing the issue.
The interesting thing is that both of these wars work perfectly fine in Tomcat 6.x.
I faced the same problem and tried all suggestions, none worked for me. I finally found out that the issue was caused after using Spring Boot overriding my tomcat version, as I had
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.1.0.M2</version>
Removing the Spring Boot solves the problem. This answer could provide the solution for using Spring Boot + Maven + Tomcat 8.
For me (Jetty 8.1.14), this exact error message was actually caused by another webapp in the same Jetty container. Are you running more than one webapps?
Add this line in <context>:
<Loader delegate="true" />
This problem is related with a conflicted jars in the applications
tag. This looks like:
<?xml version='1.0' encoding='utf-8'?>
<!-- The contents of this file will be loaded for each web application -->
<Context>
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Loader delegate="true" /> <!--this line-->
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!--
<Manager pathname="" />
-->
<!-- Uncomment this to enable Comet connection tacking (provides events on session expiration as well as webapp lifecycle) -->
<!--
<Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
-->
</Context>