I get an exception whenever I try getting context parameter from we.XML into a ServletContextListener class, I am really having hard times understanding why It is not working,
here's the exception in Apache Tomcat 7.0.11 log :
Oct 21, 2011 1:24:23 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Error configuring application listener of class alaa.ServletContextListener
java.lang.ClassNotFoundException: alaa.ServletContextListener
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:415)
at
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:118)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4618)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5184)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5179)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Here's a part of my web.xml :
<context-param>
<param-name>catName</param-name>
<param-value>meshmesh</param-value>
</context-param>
<context-param>
<param-name>catBreed</param-name>
<param-value>egyptian</param-value>
</context-param>
<listener>
<listener-class>alaa.CatLisenter</listener-class>
</listener>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
Here's my ServletContextListener.java:
package alaa;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class CatLisenter implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
String name = sc.getInitParameter("catName");
String breed = sc.getInitParameter("catBreed");
Cat maCat = new Cat();
maCat.setName(name);
maCat.setBreed(breed);
sc.setAttribute("cat", maCat);
}
#Override
public void contextDestroyed(ServletContextEvent sce) {
throw new UnsupportedOperationException("Not supported yet.");
}
}
Here's Cat.java :
package alaa;
public class Cat {
private String name;
private String breed;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getBreed() {
return breed;
}
public void setBreed(String breed) {
this.breed = breed;
}
}
many thanks
Try to clear the tomcat work directory and clean. After that, publish your project and run again.
My guess is that you have packaged the servlet-api jar in your webapp (in the WEB-INF/lib) folder and this is causing conflicts since the servlet-api will already be present in the container. Make sure you don't include any servlet-api or jsp-api (or Java EE api) jars in your webapp when you deploy it.
I had the same problem running JUnit in a Tomcat 7 environment and I solved it adding a dependency in maven (pom.xml) like this:
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-servlet-api</artifactId>
<version>7.0.54</version>
<scope>provided</scope>
</dependency>
If you are working in Eclipse, Then just clean your project.
Follow this simple step,
Go to Project >
clean...> clean all projects > Ok
I had the same issue when I tried with eclipse LUNA version and tomcat 7. The same code without any extra changes worked in eclipse JUNO with tomcat 7.
Verify the space in disk. When eclipse copy the folder libs if not space in disk this error may occur
I had a similar problem. It Maybe not be related to what you had but it might save someone some time. I had my listener-class wrong in the web descriptor file:)
Related
Recently I tried Tomcat 10.0.10 and when trying to inject the connection pool as a JNDI resource find out that the #Resource annotation doesn't work.
Then I tried obtain it programmatically by creating a InitialContext and it worked. Initially I thought it was only for the java:comp/env/jdbc so I tried with a simple bean like below and tried to inject it with the #Resource annotation it didn't work again. When I try to obtain it programmatically by creating a InitialContext and it works. Then I check whether the #PostConstruct or #PreDestroy annotation works and found out that they also don't work.
package lk.ijse.test.tomcatdbcp;
public class Something {
}
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Resource name="bean/Something" auth="Container"
type="lk.ijse.test.tomcatdbcp.Something"
factory="org.apache.naming.factory.BeanFactory"
/>
</Context>
<?xml version="1.0" encoding="UTF-8"?>
<web-app metadata-complete="false" xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<resource-env-ref>
<resource-env-ref-name>bean/Something</resource-env-ref-name>
<resource-env-ref-type>lk.ijse.test.tomcatdbcp.Something</resource-env-ref-type>
</resource-env-ref>
</web-app>
package lk.ijse.test.tomcatdbcp;
import java.io.*;
import jakarta.annotation.PostConstruct;
import jakarta.annotation.Resource;
import jakarta.servlet.http.*;
import jakarta.servlet.annotation.*;
import javax.naming.InitialContext;
import javax.naming.NamingException;
#WebServlet(name = "helloServlet", value = "/hello", loadOnStartup = 1)
public class HelloServlet extends HttpServlet {
private String message;
#Resource(name= "java:comp/env/bean/Something")
private Something something;
#PostConstruct
public void doSomething(){
System.out.println("Does it work?");
}
public void init() {
message = "Hello World!";
try {
InitialContext ctx = new InitialContext();
Something lookup = (Something) ctx.lookup("java:comp/env/bean/Something");
System.out.println(lookup);
System.out.println(something); // null
} catch (NamingException e) {
e.printStackTrace();
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
response.setContentType("text/html");
// Hello
PrintWriter out = response.getWriter();
out.println("<html><body>");
out.println("<h1>" + message + "</h1>");
out.println("</body></html>");
}
public void destroy() {
}
}
To reproduce the same issue, I created a sample repo here: https://github.com/sura-boy-playground/play-with-tomcat10
(Complete code can be found there)
At first, I had used javax.annotation.Resource annotation, so I thought that was the reason because of the javax.* to jakarta.* namespace change. Then I tried it with jakarta.annotation.Resource but the result was same.
I tried the same application with Tomcat 9.0.41 plus javax.* namespace, it works perfectly.
Is there any extra stuff that I need to do on Tomcat 10.0.10 to enable these annotations? I dug the Tomcat 10 documentation but I wasn't able to find out any thing related to my issue.
I found out that there was a similar case in Tomcat 7 previously, but I don't like that kind of workaround now.
Tomcat #Resource annotations API annotation stops working in Tomcat 7
You should declare the scope of your jakarta.annotation dependency as provided:
<dependency>
<groupId>jakarta.annotation</groupId>
<artifactId>jakarta.annotation-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>
If you have two copies of jakarta.annotation.Resource (one in the common classloader and one in your application's classloader), the two classes are different. The InstanceManager will look for fields annotated with the common classloader's copy of #Resource, while the something field is annotated with your webapp's copy of #Resource.
Edit: this problem was fixed in Tomcat 10.0.17 (cf. changelog), 9.0.59 and 10.1.0-M11.
Remark: You will have the same problem in Tomcat 9.0 if you use Java 11 or later. Before Java 11 the javax.annotation.* classes where included in the JRE. Servlet containers are required to look in the bootstrap/JRE classloader before looking in the webapp classloader (overriding javax.* classes is a breach of Java's licence), therefore Tomcat would never find the additional copy of the classes.
Trying a simple REST implementation on OSGi Equinox + Jetty - simple REST deploy using web.xml
Below are the details of my implementation:
Resource file:
#Path("jsonstatus")
public class JsonResource {
private static Logger logger = LoggerFactory.getLogger(JsonResource.class);
#GET
#Produces("application/json")
public String listConferences() {
logger.info("Returning the status");
return "{\"status\": \"success\"}";
}
}
Application Implementation:
public class JerseyApplication extends Application {
private static Logger logger = LoggerFactory.getLogger(JerseyApplication.class.getName());
#Override
public Set<Class<?>> getClasses() {
logger.info("--Returning all the claess-");
Set<Class<?>> result = new HashSet<Class<?>>();
result.add(JsonResource.class);
result.add(StatusResource.class);
return result;
}
}
web.xml:
<servlet>
<servlet-name>SimpleREST</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>my.learnings.osgi.rest.jetty.activator.JerseyApplication</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>SimpleREST</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
All the OSGi core, console and jetty jars are added: When I start the Equinox, i get the below error. I dont have the activator mapped to bundle when i deployed using web.xml
But with activator and web.xml removed, REST API works, No error during equinox startup.
Simple Activator:
#Override
public void start(BundleContext context) throws Exception {
logger.info("Starting the bundle");
ServletContextHandler ch = new ServletContextHandler();
ch.setContextPath("/");
ServletHolder holder = new ServletHolder(new ServletContainer());
holder.setInitParameter("javax.ws.rs.Application", JerseyApplication.class.getName());
ch.addServlet(holder, "/*");
context.registerService(ContextHandler.class.getName(), ch, null);
}
When searched in the internet, i saw, need to configure JNDI, This is very basic simple REST which does not require a database. So got confused why we need JNDI. Some article discussed about initialization of the java.naming.factory.initial. But those are given for jboss. Not sure how to configure the initial context for jetty.All the combinations i tried are in the github code.
If you could help to get the initial context configured in the OSGi-jetty would really a great help. I am looking for a deployment with web.xml way of servlet creation on OSGi with jetty
Below repository contains the code which I tried:
https://github.com/pkolanda/my-learning-osgi-simple-rest-with-jetty
to run the code, mvn clean install and run the run.sh shell script under the target/my-learning-osgi-simple-rest-with-jetty-0.1 folder.
Meanwhile i am looking into this post
Log:
11:14:33.951 [Start Level: Equinox Container: 6ee1939d-123f-4def-860f-dfc2e21bdfc4] WARN o.eclipse.jetty.webapp.WebAppContext - Failed startup of context o.e.j.w.WebAppContext#7c19344a{/my-learning-osgi-simple-rest-with-jetty-1.0-SNAPSHOT,file:///tmp/jetty-0.0.0.0-8081-my-learning-osgi-simple-rest-with-jetty-1.0-SNAPSHOT.jar-_my-learning-osgi-simple-rest-with-jetty-1.0-SNAPSHOT-any-9046322855444487913.dir/webapp/,UNAVAILABLE}{file:/home/prakash/mygit/my-learning-osgi-simple-rest-with-jetty/target/my-learning-osgi-simple-rest-with-jetty-0.1/plugins/my-learning-osgi-simple-rest-with-jetty-1.0-SNAPSHOT.jar}
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.eclipse.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:258)
at org.eclipse.jetty.plus.webapp.EnvConfiguration.preConfigure(EnvConfiguration.java:67)
at org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:506)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:544)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:192)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:505)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:151)
at org.eclipse.jetty.osgi.boot.BundleWebAppProvider.bundleAdded(BundleWebAppProvider.java:214)
at org.eclipse.jetty.osgi.boot.BundleWebAppProvider$WebAppTracker.addingBundle(BundleWebAppProvider.java:80)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:911)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:233)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:140)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:132)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:194)
at org.eclipse.osgi.container.Module.publishEvent(Module.java:483)
at org.eclipse.osgi.container.Module.start(Module.java:474)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1763)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1725)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1656)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:233)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:343)
____________________________
Welcome to Apache Felix Gogo
g!
I'm trying to deploy a dropwizard (dw) application using wizard-in-a-box (wiab) on IBM Liberty Profile 8.5.5.5, but I'm encountering som issues with the io.dropwizard.util.JarLocation class. wiab will try to get the location of the Listener class wrapping the dw application but fails to do so since the CodeSource object in the class' ProtectionDomain is null.
klass.getProtectionDomain().getCodeSource().getLocation()
However, I've tried to deploy on Tomcat 8 and the latest Liberty Profile v9 beta, and they both work fine.
Both server.xml files on the Liberty servers look exaktly the same in terms of features.
<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">
<!-- Enable features -->
<featureManager>
<feature>servlet-3.1</feature>
<feature>jsp-2.3</feature>
<feature>el-3.0</feature>
<feature>websocket-1.1</feature>
<feature>localConnector-1.0</feature>
</featureManager>
<!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" />
<applicationMonitor updateTrigger="mbean" />
<application id="moshpit_war_war_exploded" location="D:\code\moshpit\moshpit-war\target\moshpit" name="moshpit_war_war_exploded" type="war" context-root="/" />
</server>
I've tried deploying both the ordinary war and the exploded war from inside IntelliJ, as well as using the dropin folder with a pre-built war. The v9 beta version will play nice, but not 8.5.5.5.
This is the Listener class wrapping the dw app:
#WebListener
public class MoshpitWebApplication extends WebApplication<MoshpitConfiguration> {
private static final Logger LOGGER = LoggerFactory.getLogger(MoshpitWebApplication.class);
public MoshpitWebApplication() {
super(new MoshpitApplication(), "/configuration/moshpit.yml");
}
}
and this is my dw Application class
public class MoshpitApplication extends Application<MoshpitConfiguration> {
public MoshpitApplication() {
}
public static void main(String[] args) throws Exception {
new MoshpitApplication().run(args);
}
#Override
public String getName() {
return "moshpit";
}
#Override
public void initialize(Bootstrap<MoshpitConfiguration> bootstrap) {
bootstrap.setConfigurationSourceProvider(new FileConfigurationSourceProvider());
// nothing to do yet
}
#Override
public void run(MoshpitConfiguration configuration, Environment environment) throws Exception {
final Template template = configuration.buildTemplate();
environment.healthChecks().register("template", new TemplateHealthCheck(template));
environment.jersey().register(new HelloWorldResource(template));
}
}
Update:
This seems to be a general problem with Liberty 8.5.5.5. Tried deploying a completely different application and I observed the same behaviour. The CodeSource is null for application classes.
The Liberty profile doesn't currently set the CodeSource for application classes. As you note this is addressed in the current beta and will be addressed when 8.5.5.6 is released on June 26th.
I am using apache commons + log4j for my web app.
normally log4j needs a configuration file inside the classpath; but I need to delegate the logging configuration to an external file (I need to deploy a .war in an environment, but the log configurations (max size, position, etc) it's up to a second team.
I have a commons-logging.properties in my classpath
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
# log4j.configuration=/absolute/path/where/external/logs/are/log4j.properties
unfortunately, the commented line doesn't work.
Is there a way to set up log4j with an external configuration file?
You can set it as a system property log4j.configuration property .. for example in J2SE app
java -Dlog4j.configuration=file:/path/to/log4j.properties myApp
Note, that property value must be a URL.
For more read section 'Default Initialization Procedure' in Log4j manual.
It's also possible letting a ServletContextListener set the System properties:
import java.util.Enumeration;
import javax.servlet.*;
public class SystemPropertiesHelper implements
javax.servlet.ServletContextListener {
private ServletContext context = null;
public void contextInitialized(ServletContextEvent event) {
context = event.getServletContext();
Enumeration<String> params = context.getInitParameterNames();
while (params.hasMoreElements()) {
String param = (String) params.nextElement();
String value =
context.getInitParameter(param);
if (param.startsWith("customPrefix.")) {
System.setProperty(param, value);
}
}
}
public void contextDestroyed(ServletContextEvent event) {
}
}
And then put this into your web.xml (should be possible for context.xml too)
<context-param>
<param-name>customPrefix.property</param-name>
<param-value>value</param-value>
<param-type>java.lang.String</param-type>
</context-param>
<listener>
<listener-class>servletUtils.SystemPropertiesHelper</listener-class>
</listener>
I got this from this listener code from answer .
I hope this could help you!
You can use a jvm parameter indicating the configuration file path:
-Dlog4j.configuration=absolute path
example with an absolute path:
java -Dlog4j.configuration="file:/dir1/log4j.properties"
Set the system property log4j.configuration=/abslute/or/relative/path_to_file_name
commons logging only needs to know what logging implementation it's using, the logging implementation it self is configured in whatever way it is always configured in.
This is documented in the log4j manual.
If you are using the Spring Framework, you can use the org.springframework.web.util.Log4jConfigListener.
You only need to specify the parameter log4jConfigLocation with the file location (using the URL for File). e.g.:
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>file:/absolute/path/where/external/logs/are/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>1000</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
You can specify the log4jRefreshInterval, the interval between config file refresh checks, in milliseconds.
See more in the javadoc of org.springframework.web.util.Log4jWebConfigurer.
My webapp cannot find its template file. I have read the material in this article, but it doesn't seem to solve the problem. My velocity.properties file, which is installed into my WEB-INF directory, contains the lines
resource.loader=class
resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
and the Java servlet is
package test;
import java.io.*;
import javax.servlet.http.*;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.context.Context;
import org.apache.velocity.tools.view.VelocityViewServlet;
import org.apache.velocity.app.Velocity;
import org.apache.commons.lang.StringEscapeUtils;
public class Recipes extends VelocityViewServlet {
public Template handleRequest(HttpServletRequest request,
HttpServletResponse response,
Context context) {
Velocity.init();
Template template=null;
try {
context.put("recipeList","r1");
template = Velocity.getTemplate("Recipes.vm");
} catch (Exception e) {
System.err.println("Exception caught: " + e.getMessage());
}
return template;
}
}
When I navigate to that URL, it fails. I've tried placing the vm file in the WEB-INF directory, in the classes subdirectory, in the lib directory, and in a jar in the lib directory. After things fail, catalina.out contains
Jan 12, 2013 6:35:25 PM org.apache.velocity.runtime.log.CommonsLogLogChute log
SEVERE: ResourceManager : unable to find resource 'Recipes.vm' in any resource loader.
Exception caught: Unable to find resource 'Recipes.vm'
and in localhost.log
Jan 12, 2013 6:35:25 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet recipes threw exception
java.lang.NullPointerException
at org.apache.velocity.tools.view.VelocityView.performMerge(VelocityView.java:942)
at org.apache.velocity.tools.view.VelocityView.merge(VelocityView.java:902)
at org.apache.velocity.tools.view.VelocityViewServlet.mergeTemplate(VelocityViewServlet.java:318)
at org.apache.velocity.tools.view.VelocityViewServlet.doRequest(VelocityViewServlet.java:220)
at org.apache.velocity.tools.view.VelocityViewServlet.doGet(VelocityViewServlet.java:182)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Can someone explain to me what is going on? Thanks.
You should be using:
class.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
The resource loader "type" precedes the property name defining the loader class.
See the Velocity Developer Guide to Resource Loaders. Note that the answer you link to points at the correct docs but doesn't (appear) to include the correct config
(All this said, are you sure that's how you're supposed to use the VelocityViewServlet? I thought you'd normally request the *.vm file, do something like a fillContext, and be done with it.)
You're calling Velocity.init() from within a VelocityViewServlet, which is most likely not what you want to do. That aside, from the docs:
initialize the Velocity runtime engine, using the default properties of the Velocity distribution
If you do the following, the configuration I show works:
String propFile = getServletContext().getRealPath("/WEB-INF/velocity.properties");
Velocity.init(propFile);
That said, I'm not convinced you're going about this the right way, but I could be mistaken--I've never used it in a standalone web app before, but this doesn't strike me as being correct.
If nothing else, I'd at least move some stuff into a base class, like:
public abstract class BaseVelocityServlet extends VelocityViewServlet {
#Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
Velocity.init(getServletContext().getRealPath("/WEB-INF/velocity.properties"));
}
#Override
protected Template getTemplate(HttpServletRequest request, HttpServletResponse response) {
return Velocity.getTemplate(getTemplateName());
}
public abstract String getTemplateName();
}
Then each URL's servlet can just fill the context and provide a template name:
public class Recipes extends BaseVelocityServlet {
#Override
protected void fillContext(Context context, HttpServletRequest request) {
context.put("recipeList", "r1");
}
#Override
public String getTemplateName() {
return "Recipes.vm";
}
}
Again, I'm not convinced this is right; I'm still under the impression that it should be finding the config file under WEB-INF by default, but for me, at least, it's not.