9.0.73 change log

[Adam Rauch]

Thanks, Tomcat team, for cranking out another release!

I noticed a minor discrepancy on the main website home page 
(https://tomcat.apache.org/). In the "Tomcat 9.0.73 Released" section, 
"Tomcat 9 changelog" links to the 9.0.71 bookmark 
("#Tomcat_9.0.71_(remm)") instead of the 9.0.73 bookmark.


Thanks,
Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Jasper's use of deprecated boxed primitive constructors

[Adam Rauch]

On 6/14/2021 12:38 PM, Mark Thomas wrote:

On 14/06/2021 20:31, Adam Rauch wrote:
As you're probably aware, all Boolean, Byte, Character, Double, 
Float, Integer, Long, and Short constructors were deprecated in JDK 
9, 
https://www.oracle.com/java/technologies/javase/9-deprecated-features.html#JDK-8065614. 
They were then marked forRemoval=true in JDK 16.


Jasper generates code that uses these deprecated constructors, when 
binding tag attributes to setters. This results in fairly adamant 
warnings when compiling on javac (not sure how JDT reacts). For now, 
the generated code compiles and the warnings could be disabled, but 
they're clearly telling us the JDK will remove support at some point. 
Is there any plan to adjust the code gen to use auto-boxing or 
valueOf() instead of the deprecated constructors?


Not yet.

I can file a bug and/or work up a patch. JspUtil.java appears to 
contain the relevant code.


That would be great. Tx.

Mark

Thanks, Mark. Bug created: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=65377


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Jasper's use of deprecated boxed primitive constructors

[Adam Rauch]

As you're probably aware, all Boolean, Byte, Character, Double, Float, 
Integer, Long, and Short constructors were deprecated in JDK 9, 
https://www.oracle.com/java/technologies/javase/9-deprecated-features.html#JDK-8065614. 
They were then marked forRemoval=true in JDK 16.


Jasper generates code that uses these deprecated constructors, when 
binding tag attributes to setters. This results in fairly adamant 
warnings when compiling on javac (not sure how JDT reacts). For now, the 
generated code compiles and the warnings could be disabled, but they're 
clearly telling us the JDK will remove support at some point. Is there 
any plan to adjust the code gen to use auto-boxing or valueOf() instead 
of the deprecated constructors?


I can file a bug and/or work up a patch. JspUtil.java appears to contain 
the relevant code.


Thanks,
Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Re: [OT] Replacing the standard JspWriter

[Adam Rauch]

On 9/14/2020 6:19 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 9/11/20 19:30, Adam Rauch wrote:

I have implemented a custom JspWriter and registered it for use by
our JSPs using the approach described here:
https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-

out-jspwriter-with-jsp-includes-to-change-the-beh



I created a custom JspFactory that returns a custom JspContext
that returns my custom JspWriter. I then replaced the standard
JspFactory by calling JspFactory.setDefaultFactory(). This works,
though it results in some undesired behavior. I also note that the
setDefaultFactory() JavaDoc seems to claim that my approach is
"illegal".

So, is there a preferred way for my web application to provide a
custom JspWriter for my JSPs to use?

(If you're curious, our JspWriter HTML encodes all strings that
aren't designated as safe-to-render, like React and other modern
JavaScript frameworks do. The usual JSP approach is too susceptible
to XSS vulnerabilities, IMO.)

Really?

Seems like  should work just fine. You prefer
this?

<%= myVar %>

How do you mark variables as being "HTML-safe"?

If you don't trust your JSP programmers to do this correctly, maybe
JSP isn't the right technology for your team. (I happen to think that
JSP needs to go away, but that's just me).

- -chris

Thanks, Chris. I don't particularly love JSPs either, and we target 
React for most UI work these days, but we maintain a large system that 
includes ~1,000 existing JSPs. We also have many third party developers 
building their own code on our platform and we like the system to 
enforce best practices as much as possible. Our JSP base class makes it 
trivial to encode Strings (<%=h(myString)%>); the challenge is 
distinguishing Strings that contain well-formed HTML (produced by helper 
methods or commonly used builders) from those that don't. We have 
introduced a SafeToRender interface to mark Objects that are allowed to 
render themselves without encoding (i.e., their toString() must render 
well-formed HTML or JavaScript). HtmlString and JavaScriptFragment are 
String wrappers that implement SafeToRender, and are used to safely 
build ad hoc content. Likewise, builders for common HTML elements and 
JSON. While I trust my developers, this approach allows for 
straightforward verification and security auditing.


Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Re: Replacing the standard JspWriter

[Adam Rauch]

On 9/12/2020 2:15 AM, Mark Thomas wrote:

On 12/09/2020 00:30, Adam Rauch wrote:

I have implemented a custom JspWriter and registered it for use by our
JSPs using the approach described here:
https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-out-jspwriter-with-jsp-includes-to-change-the-beh


I created a custom JspFactory that returns a custom JspContext that
returns my custom JspWriter. I then replaced the standard JspFactory by
calling JspFactory.setDefaultFactory(). This works, though it results in
some undesired behavior. I also note that the setDefaultFactory()
JavaDoc seems to claim that my approach is "illegal".

So, is there a preferred way for my web application to provide a custom
JspWriter for my JSPs to use?

How about using an include-prelude mapped to all JSPs to wrap the
default JspWriter with the custom writer?

Mark

This works great... much cleaner than my previous approach. Thanks for 
the suggestion, Mark!


Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Replacing the standard JspWriter

[Adam Rauch]

I have implemented a custom JspWriter and registered it for use by our 
JSPs using the approach described here: 
https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-out-jspwriter-with-jsp-includes-to-change-the-beh


I created a custom JspFactory that returns a custom JspContext that 
returns my custom JspWriter. I then replaced the standard JspFactory by 
calling JspFactory.setDefaultFactory(). This works, though it results in 
some undesired behavior. I also note that the setDefaultFactory() 
JavaDoc seems to claim that my approach is "illegal".


So, is there a preferred way for my web application to provide a custom 
JspWriter for my JSPs to use?


(If you're curious, our JspWriter HTML encodes all strings that aren't 
designated as safe-to-render, like React and other modern JavaScript 
frameworks do. The usual JSP approach is too susceptible to XSS 
vulnerabilities, IMO.)


Thanks,
Adam




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Re: Tomcat 8.5.48: NullPointerException in ApplicationMapping.getHttpServletMapping()

[Adam Rauch]

On 11/17/2019 9:01 AM, Mark Thomas wrote:

On 16/11/2019 22:08, Adam Rauch wrote:

While testing 8.5.48, we now see NullPointerExceptions when our
ImageServlet code attempts to forward a request to a new location. In
8.5.47, the code works fine.

Thanks for reporting this. I can see what the problem is.

I updated the servlet4preview API in 8.5.x to align it with what was
released in Servlet 4 (some names changed). As part of that I aligned
the 8.5.x implementation code with 9.0.x. That removed a null check that
8.5.x needs. I'll cancel the 8.5.48 vote, get that fixed and roll an
8.5.49 release.

Mark


FYI: I've tested on 8.5.49 and everything looks good to me. Thanks, once 
again, for the quick turnaround, Mark!


Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8.5.48: NullPointerException in ApplicationMapping.getHttpServletMapping()

[Adam Rauch]

While testing 8.5.48, we now see NullPointerExceptions when our 
ImageServlet code attempts to forward a request to a new location. In 
8.5.47, the code works fine.


A simplified version of our code:

    public void sendResource(HttpServletRequest request, 
HttpServletResponse response) throws IOException, ServletException

    {
request.getRequestDispatcher(getForwardLocation(request)).forward(request, 
response);

    }

The NPE stack trace we see:

    java.lang.NullPointerException
 at 
org.apache.catalina.core.ApplicationMapping.getHttpServletMapping(ApplicationMapping.java:36)
 at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:380)
 at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:316)
 at 
org.labkey.api.settings.TemplateResourceHandler.sendResource(TemplateResourceHandler.java:202)
 at 
org.labkey.api.attachments.ImageServlet.service(ImageServlet.java:72)

 at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
 at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)


Let me know if you'd like me to open a Bugzilla and/or provide more context.

Thanks,
Adam

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

NPE in DBCP when attempting to connect to a database that doesn't exist

[Adam Rauch]

When attempting to connect to a DataSource that specifies a database 
that doesn't exist, Tomcat 8.5.46 throws an informative SQLException; 
for example: java.sql.SQLException: Cannot create 
PoolableConnectionFactory (FATAL: database "labkey19.3" does not exist)


In the same situation, Tomcat 7.0.96 throws a NullPointerException with 
no useful information.


I expect an exception, but the 8.5.46/DBCP2 behavior is obviously 
preferable, since it gives administrators a better understanding of 
what's gone wrong. Seems like a DBCP 1.x bug (not a Tomcat bug) and I 
wouldn't consider it a high priority to fix (our product recovers just 
fine in either case and we recommend Tomcat 9.0.x these days), but the 
discrepancy seemed worth mentioning here.


Full stack traces below. Our code is simply:

    try (Connection conn = dataSource.getConnection())
    {
    ...
    }

Thanks,
Adam


Tomcat 7.0.96

java.lang.NullPointerException
    at 
org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.destroyObject(PoolableConnectionFactory.java:643)
    at 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory(BasicDataSource.java:1738)
    at 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:1721)
    at 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1486)
    at 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1103)

    at org.labkey.api.data.DbScope.(DbScope.java:337)
    at org.labkey.api.data.DbScope.addScope(DbScope.java:1275)
    at org.labkey.api.data.DbScope.initializeScopes(DbScope.java:1243)
    at 
org.labkey.api.module.ModuleLoader.initializeDataSources(ModuleLoader.java:1004)

    at org.labkey.api.module.ModuleLoader.doInit(ModuleLoader.java:352)
    at org.labkey.api.module.ModuleLoader.init(ModuleLoader.java:249)
    at 
org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:285)
    at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:266)
    at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
    at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5037)
    at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5739)

    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
    at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1018)
    at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:994)
    at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:662)
    at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:712)
    at 
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:2002)
    at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at 
java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)

    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

    at java.base/java.lang.Thread.run(Thread.java:830)

Tomcat 8.5.46

java.sql.SQLException: Cannot create PoolableConnectionFactory (FATAL: 
database "labkey19.3" does not exist)
    at 
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:669)
    at 
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:544)
    at 
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:753)

    at org.labkey.api.data.DbScope.(DbScope.java:337)
    at org.labkey.api.data.DbScope.addScope(DbScope.java:1275)
    at org.labkey.api.data.DbScope.initializeScopes(DbScope.java:1243)
    at 
org.labkey.api.module.ModuleLoader.initializeDataSources(ModuleLoader.java:1004)

    at org.labkey.api.module.ModuleLoader.doInit(ModuleLoader.java:352)
    at org.labkey.api.module.ModuleLoader.init(ModuleLoader.java:249)
    at 
org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:283)
    at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
    at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
    at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4546)
    at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5191)

    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
    at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
    at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714)
    

Re: Re: JspC ignores uriroot property as of Tomcat 9.0.14 / 8.5.37

[Adam Rauch]

On 1/3/2019 11:53 AM, Mark Thomas wrote:

On 02/01/2019 19:50, Adam Rauch wrote:

Our build pre-compiles JSPs by invoking JspC following a pattern similar
to the JspC JavaDoc example configuration:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/jasper/JspC.html

Starting with 9.0.14 and 8.5.37, our build stopped pre-compiling JSPs;
JspC no longer converts a tree of *.jsp files into a tree of *_jsp.java
files. Reviewing the change list, it looks like "53737: Extend JspC, the
precompilation tool, to include support for resource JARs. (markt)" is
related. Commit 1846928 no longer respects the "uriroot" property (in
the pages.size() == 0 case):

svn diff -r 1846928
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/java/org/apache/jasper/JspC.java


Please let me know if I should open bugzilla issue or if this is an
intentional change in behavior.

That sounds like a bug. If you open a BZ issue and provide the simplest
possible example (i.e. zipped up build dir with a single JSP and the
appropriate Ant file or command line to call JspC) then I'll take a look.

Mark


Bugzilla opened: https://bz.apache.org/bugzilla/show_bug.cgi?id=63056

Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JspC ignores uriroot property as of Tomcat 9.0.14 / 8.5.37

[Adam Rauch]

Our build pre-compiles JSPs by invoking JspC following a pattern similar 
to the JspC JavaDoc example configuration: 
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/jasper/JspC.html


Starting with 9.0.14 and 8.5.37, our build stopped pre-compiling JSPs; 
JspC no longer converts a tree of *.jsp files into a tree of *_jsp.java 
files. Reviewing the change list, it looks like "53737: Extend JspC, the 
precompilation tool, to include support for resource JARs. (markt)" is 
related. Commit 1846928 no longer respects the "uriroot" property (in 
the pages.size() == 0 case):


svn diff -r 1846928 
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/java/org/apache/jasper/JspC.java


Please let me know if I should open bugzilla issue or if this is an 
intentional change in behavior.


Thanks,
Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory starting in 7.0.86

[Adam Rauch]

Our code retrieves DataSources using JNDI, with code similar to this:

    new InitialContext().lookup("java:comp/env/jdbc/labkeyDataSource");

With a simple DataSource definition that doesn't specify a "factory" 
attribute, this code now throws in Tomcat 7.0.86. (It works in 7.0.85, 
8.0.50, 8.5.30, and 9.0.7.)


According to the tomcat70 GitHub mirror, a recent change to 
Constants.java switched DBCP_DATASOURCE_FACTORY to 
"org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory", which seems 
suspicious. See 
https://github.com/apache/tomcat70/commit/08b7ca0fae77063202d82e719eb35e4eda881bbf


Root cause stack trace is:

Caused by: java.lang.ClassNotFoundException: 
org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory

   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:264)
   at 
org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:115)

   ... 26 more

Thanks,
Adam

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Re: Response change between 8.5.x and 8.0.x (and earlier versions) W.R.T. Line separator CRLF vs. LF

[Adam Rauch]

On 10/16/2017 1:27 PM, Net Dawg wrote:

  Profuse apologies.  We are unable reproduce this.  However out tests were 
failing for another reason.
8.5.23 returns 400 error with header "HTTP/1.1 400" where as version 8.0.47 returns the same as 
"HTTP/1.1 400 Bad Request".  When the tests check for the legacy header they were failing.  As soon as we 
stopped checking for "Bad Request" our tests work.  On Monday, October 16, 2017, 8:19:33 AM GMT-10, 
Mark Thomas  wrote:
  
  On 16/10/17 18:48, Net Dawg wrote:

We are finding line separator has changed on Mac OS X in tomcat 8.5.23 response 
relative to all previous versions of tomcat we tested (8.0.47, 7.0.72 and 
7.0.82).  We see nothing in change log to understand this change.
Specifically, 8.5.23 is generating CRLF in response (showing up as ^M in vim), 
while previous versions of tomcat are just producing LF.  As a result all of 
our tests based on earlier versions of tomcat are failing.
Is this a bug, in which case we will wait for fix (and lets tests fail due to 
known issue in tomcat) or is this how tomcat will always generate response 
going forward - in which case we will make our tests more lenient to be 
backward compatible somehow.

Context please. Line separator where exactly?

Mark




As for the removal of response messages in 8.5.x, this appears to be an 
intentional change. From the 8.5.0 section of the change log, 
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.0_(markt)


"RFC 7230 states that clients should ignore reason phrases in HTTP/1.1 
response messages. Since the reason phrase is optional, Tomcat no longer 
sends it. As a result the system property 
org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER is no longer used and 
has been removed. (markt)"


Adam

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

"End of life for Apache Tomcat 8.0.x" page title

[Adam Rauch]

I noticed that the current  element for the new EOL page is: 
"Apache Tomcat® - End of life for Apache Tomcat 6.0.x". You may want to 
adjust the version to "8.0.x."


Thanks,
Adam

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8.5.15 Released?

[Adam Rauch]

Is Tomcat 8.5.15 officially released? The home page
(http://tomcat.apache.org/index.html) seems to indicate that it was released
2017-05-10. however, the text of the section references the "release of
version 8.5.14" and "notable changes compared to 8.5.13." And the changelog
link hits the 8.5.14 anchor. Also, the archives show no 8.5.15 post to the
tomcat-announce list.

 

Perhaps the release is still in progress, but the page has been in this
state for a few days.

 

Thanks,

Adam