I have this in the web.xml file:
<servlet>
<servlet-name>freemarker</servlet-name>
<servlet-class>freemarker.ext.servlet.FreemarkerServlet</servlet-class>
<init-param><param-name>template_update_delay</param-name>
<!-- ATTENTION, 0 is for development only! Use higher value otherwise. -->
<param-value>0</param-value></init-param>
However, I have positively concluded that stale .ftl files are being delivered to the web browser.
I am not using any sort of 'Spring' or similar.
Using Freemarker 2.3.23.
Is there a more appropriate way to have Freemarker switch off its cache during development?
Related
This is the most bizarre tomcat configuration problem I've ever seen. I have the following entry in web.xml:
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
<hstsEnabled>true</hstsEnabled>
<hstsMaxAgeSeconds>631</hstsMaxAgeSeconds>
<hstsIncludeSubDomains>true</hstsIncludeSubDomains>
<hstsPreload>true</hstsPreload>
</filter>
I intentionally put in a weird value for max-age so that it would be easy to see if the configuration is active or not.
And it's activated:
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
But it doesn't do what it should do. The resulting headers are always:
strict-transport-security: max-age=0
which is almost exactly what I don't want.
Any ideas on this? I can't even understand how this could be happening and it certainly goes against all the documentation. This is all with Tomcat 9.0.29, JDK 13. It seems like it should "just work" and seems like a very simple configuration.
To be clear, this is in the Tomcat web.xml (in $CATALINA/conf/web.xml), not in an application-specific web.xml. HSTS preload is for the entire domain (including subdomains which might be on other servers), not for any set of URIs within the domain, so it only makes sense to set preload in the server-wide web.xml.
EDIT: This is with a Spring Boot application. It seems that Spring Boot might be controlling this header and overriding whatever is being set in web.xml. This is unfortunate because Spring Boot is for a specific application in a specific context, whereas this header really applies to the entire domain, or even to sub-domains, and so is beyond any specific web application in a specific context. I think I need to figure out how to get Spring Boot to do nothing to HSTS headers and let Tomcat handle it all.
I understand Websphere 8.0.0.6 uses the Apache Wink implementation for JAX-RS 1.1.
I'm just wondering what version of Apache Wink does it use?
Also, if I needed to use Apache CXF do I just bundle the CXF jars with my war?
ALso what implementations does Websphere 8.0.0.6 use for CDI (Weld 2.x ??), Bean Validation (??), JPA (??), JAXB (??) etc..
WAS v8.0.0.x uses it's own modified version of Wink v1.1-incubating. If you navigate to {WAS_HOME}/plugins, you'll see a .jar named com.ibm.ws.jaxrs.jar. If you explore the MANIFEST within that artifact, you'll see that IBM modified Wink v1.1-incubating and created their own v1.1.1. You'll want to use this version, because it incorporates wink-jcdi-server. Otherwise, you can't inject your EJB's into your Wink Resources, which creates a number of annoying problems. I generally don't like to shackle myself to a vendor-specific solution, but in this case, you're going to want to use IBM's Wink implementation. I've backported wink-jcdi-server from v1.2-incubating to v1.1-incubating with temporary success (I got the jcdi feature to work, but then, with no determined root cause, lost it a few deployments later). So, save yourself tons of frustration and use IMB's Wink implementation. IBM's Wink implementation will be exposed to your app, via an OSGi-related artifact, whether you set the classloader policy to PARENT_FIRST or PARENT_LAST. I suspect that is a bug. You'll also need to include the com.ibm.ws.prereq.jaxrs.jar artifact in your project as well.
In web.xml, use the following config:
<!-- Wink Servlet -->
<servlet>
<description>JAX-RS Tools Generated - Do not modify</description>
<servlet-name>JAX-RS Servlet</servlet-name>
<servlet-class>com.ibm.websphere.jaxrs.server.IBMRestServlet</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.company.webservices.config.WinkApplication</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
<enabled>true</enabled>
<async-supported>false</async-supported>
</servlet>
<!-- Wink Servlet Mapping -->
<servlet-mapping>
<servlet-name>JAX-RS Servlet</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>
According to IBM's own WAS v8.0 video on JAX-RS, your Application subclass will get automatically recognized by extending the Application class and the ApplicationPath annotation. This is not the case. You need to specify your Application subclass in web.xml. However, you'll notice that the console will tell you that the default Wink Application was used. This is false. Your class will get picked up, and you'll need to override the getClasses method and register your Providers, Resources, etc. This behavior has been observed and thoroughly tested as of WAS v8.0.0.8.
You could try CXF in WAS 8 as an alternative.
Like Geronimo and TomEE, WAS is built on Apache products. I could be wrong, but, last I remember, WAS v8.0 uses Apache OpenWebBeans v1.0, Apache BVal v1.0, Apache OpenJPA v2.1.2-SNAPSHOT. I'm not sure about JAXB, but I think they use their own json4j framework. I use MOXy with surprisingly much success.
You can get detailed report about component versions by running versionInfo script located in WAS_HOME/bin directory. For example, for Linux:
./versionInfo.sh -file versionReport.txt -maintenancePackages -componentDetail
Specification versions are listed at Specifications and API documentation
I am using IBM WebSphere (WAS) 7.0.0.19 to host a java-based web-app, and I needed to map the extension *.html to a particular servlet so that I could do some server-side scrubbing of user-supplied HTML files. (The server reads the file, augments it with some extra information, and serves up the modified content transparently to the person viewing the page.)
Unfortunately, when I did this, welcome-files stopped working. Previously, if I typed in the URL for a directory, the server would look for index.html and serve up that. Now, I'm just getting a 403 forbidden rule ("Forbidden - by rule."). The access logs don't show anything more--they simply state that directory indexing is forbidden by rule for the server, which is correct. I don't want the webserver to build a table of contents for directories with no index.html, but when there is an index.html, I want it to serve up that file.
My first thought was that it was trying to serve the index.html through my servlet, the servlet was failing to find the file (because the url lacked "index.html"), and therefore it thought there was no index.html. However, I put in some debug code and am quite confident that the servlet code is never getting run when I go simply to the directory itself.
I don't really care whether index.html is served through the servlet or not--in the case of this particular file, the servlet would just spit back the original file anyway. I just want index.html to be served by something.
Here is the relevant section of my web.xml
<servlet-mapping>
<servlet-name>PageScrubber</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
For what it's worth, index.htm and index.jsp were not working before the addition of the servlet mapping. Only index.html worked before. However, now none of them work.
I have used the same web.xml with two Oracle products: WebLogic (WLS) and Oracle Application Server (OAS) with no issues.
I am quite confident that it is just the addition of this scrubber servlet that has caused the problem, because removing that directive caused directory indexing to start working again.
I did find some notes about welcome-file-list not working when using an extended document root, and I tried setting com.ibm.ws.webcontainer.EnablePartialURLtoExtendedDocumentRoot to be true, but that did not seem to change anything.
I'm pretty much out of ideas. Does anyone out there have any thoughts as to why it's not finding my index.html? Thanks in advance!
Caveat: I am working out of memory here.
The Welcome files used to be served by File Serving Servlet (or something that sounds similar to that).
This information would be in the WebSphere extensions file.
I would take a step back and remove your pageScrubber and get the file serving Servlet to serve the welcome files and see that things are working before getting back to using the PageScrubber.
These are my initial thoughts.
HTH
In Spring I have slf4j with log4j to resolve logging.
I put relative path in log4j.xml configuration, but when i execute app in Netbeans Tomcat and independent Apache Tomcat, relative path is different, and I must change manually.
My idea is obtain context realpath from Spring Controller and set it in log4j configuration in execution time. But I dont know...
How can I change file path param of log4j from Spring Controller?
Two suggestions for you to try:
Add a WebAppRootListener to your web.xml - this will configure a system property pointing (default to webapp.root, but you can customize using a context-param - see the Javadocs link) to the root of your web application, which you can then use in the log4j.properties/xml file:
<listener>
<listener-class>org.springframework.web.util.WebAppRootListener<listener-class>
<listener>
<!-- log4.appender.File=${webapp.root}/logs/web-app.log -->
Or use the Log4jConfigListener in your web.xml (which ultimately delegates to a Log4jConfigurer) - this is similar to the above, but allows you to define a custom log4j configu file and also allows for your web application to monitor the log4j config file for changes made at runtime and automatically update your loggers:
<context-param>
<!-- Configure Log4J from the following config file location -->
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/log4j.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener<listener-class>
<listener>
I would also recommend you read the Javadocs for the above in detail - there are some gotchas with regards to deploying multiple webapps in Tomcat and sharing of system properties, but this can all be worked around (providing a custom key for each webapp, rather than the default ${webapp.root}
How can I integrate URL rewriting in my Glassfish v3 server?
The reason why I want to know this is that I am deploying a PHP application into my Glassfish server using Quercus.
But Quercus relies on mod_rewrite in the Apache Server to provide URL rewriting and this is not available in Glassfish.
Well, you have two options:
either front your GlassFish instance with Apache and use mod_rewrite
or use Tuckey's Url Rewrite Filter
I guess the former is not an option (or you wouldn't post this question). Regarding the later, you could adapt the solution given in Drupal on Glassfish with clean urls using Url Rewrite Filter. Basically, you'll have to:
Get Quercus's war and unpack it
Download the filter and unpack it inside Quercus (this will put the filter jar inside WEB-INF/lib and the urlrewrite.xml under WEB-INF)
Declare the filter in the web.xml (see the instruction)
"Port" your rewrite rules to the urlrewrite.xml file
repackage and deploy the war (or deploy it as an exploded archive)
I've been looking for the answer to this for a couple weeks.
Follow these instructions for JBoss:
http://tapomay.blogspot.com/2011/11/clean-urls-with-drupal-urlrewritefilter.html
He links to an article where one had done this for Tomcat: http://www.brianshowalter.com/blog/running_drupal_on_quercus
In a nutshell, you want to rewrite the URL only IF the requested file or directory do not exist on the system. This is why just UrlRewriteFilter is not enough. You have to add a class-filter to UrlRewriteFilter to check for this.
The instructions I linked to uses an older version of UrlRewriteFilter (3.2.0), it probably works just as well with the newer version (I did it with 3.2.0).
You will use that in conjunction with a class filter (there is a google project repository for this, thanks to the author of the linked article, at https://code.google.com/p/drupalrewritefilter/ )
The instructions say to add the files to Eclipse, but I used Netbeans (just start a new project with existing sources).
You'll need to add the servlet.api.jar (some where on your system, if you have J2EE installed) and the UrleRewriteFilter.jar file you are using to the classpath for the build.
Place the resulting drupalrewritefilter.jar file and the UrlRewriteFilter.jar file you are using in WEB-INF/lib
Your WEB-INF/web.xml should have this filter directive:
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>TRACE</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Use this instead of the one the website for UrlRewriteFilter says to use.
NOTE: The Quercus install contains a DOCTYPE tag in the beginning for the Servlet API 2.2 or 2.3. But the <filter> tag is in the Servlet API 2.4 or higher. Your app will error-out unless you either link to a new Server API DTD or (and this is what I did) just delete the DOCTYPE tag all together.
Then you should have a WEB-INF/urlwrite.xml with:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
"http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite>
<class-rule class="com.brianshowalter.drupalrewrite.DrupalRule" />
</urlrewrite>
Reload your drupal app, and then go enable clean URLS's