My inclination is that this is a tomcat bug in all versions when newer versions
of Java 1.8 are used & there are overloaded setters. In our case, we have the
following in our TLD…
<attribute>
<name>value</name>
<required>true</required>
<rtexprvalue>true</rtexprvalue>
<type>java.lang.Object</type>
</attribute>
Yet tomcat generates EL expression evaluation to java.lang.String when there’s
an overloaded setter. I’m not aware of any official position on overloaded
setters & JSTL tag classes.
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com<http://www.cerner.com/>
From: "LoBello,Jeff" <jeff.lobe...@cerner.com.INVALID>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
Date: Thursday, October 31, 2019 at 5:19 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: JSP custom tag operating different when adoptOpenJDK is used vs
Oracle (cross post from tomcat-taglibs-user)
We have found this issue manifests in Oracle & adopt open JDK if using the
current versions of 1.8.
Adopt jdk standard (1.8.0.222) issue
Oracle jdk shiny new (1.8.0.231) issue
Oracle jdk 4.3.100 style (1.8.0.201) no issue
Adopt jdk older (1.8.0.202) NO ISSUE.
We’re changing our code to remove overloaded setter with JSTL. Our concern is
we obviously can’t fix 3rd party code that may be affected by this JVM bug.
Should we look into filing a bug report with Oracle or Tomcat?
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com<http://www.cerner.com/>
From: "LoBello,Jeff" <jeff.lobe...@cerner.com<mailto:jeff.lobe...@cerner.com>>
Date: Monday, October 28, 2019 at 9:31 AM
To: Tomcat Users List <users@tomcat.apache.org<mailto:users@tomcat.apache.org>>
Subject: Re: JSP custom tag operating different when adoptOpenJDK is used vs
Oracle (cross post from tomcat-taglibs-user)
That’s good to hear, you’re example works. In our tag class, which extends
org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport, we have
setValue() overloaded, as follows…
public void setValue(final String value) {
public void setValue(final Object value) {
Is this a bad practice? How does tomcat decide which one to use. Why would
changing to adoptOpenJdk break this?
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com<http://www.cerner.com/>
From: Felix Schumacher
<felix.schumac...@internetallee.de<mailto:felix.schumac...@internetallee.de>>
Reply-To: Tomcat Users List
<users@tomcat.apache.org<mailto:users@tomcat.apache.org>>
Date: Sunday, October 27, 2019 at 2:52 PM
To: "users@tomcat.apache.org<mailto:users@tomcat.apache.org>"
<users@tomcat.apache.org<mailto:users@tomcat.apache.org>>
Subject: Re: JSP custom tag operating different when adoptOpenJDK is used vs
Oracle (cross post from tomcat-taglibs-user)
I tried to reproduce the bug with the following simple jsp:
<%@ taglib prefix = "fmt" uri =
"https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjava.sun.com%2Fjsp%2Fjstl%2Ffmt&data=02%7C01%7CJeff.Lobello%40cerner.com%7C0072abd9995a46eea13908d75e48092a%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C637081535837070958&sdata=ov9ysbkVhDEqlv0JBYfRIS4HqSeSE1u2t4qBPzwLyTw%3D&reserved=0";
%>
<html>
<head>
<title>String/Object bug</title>
</head>
<body>
<%
request.setAttribute("now", new java.util.Date());
%>
<fmt:formatDate pattern="yyyy-MM-dd" value="${now}" />
</body>
</html>
but both Java versions (oracle 1.8.0_201 and openjdk 1.8.0_222) produce
the following java parts with tomcat 9.0.27:
...
// /index.jsp(12,6) name = value type = null reqTime = true required =
true fragment = false deferredValue = false expectedTypeName = null
deferredMethod = false methodSignature = null
_jspx_th_fmt_005fformatDate_005f0.setValue((java.util.Date)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${now}",
java.util.Date.class, (javax.servlet.jsp.PageContext)_jspx_page_context,
null));
...
Can you share your tag implementation or even better give us a minimal
webapp that shows the error?
Is the Tomcat version the same for the different Java implementations?
Felix
Am 27.10.19 um 18:14 schrieb LoBello,Jeff:
Sorry for not mentioning that before, Felix. I’ve seen this bug under Mac &
Windows Java versions. We only support Java 1.8, at the moment.
Mac:
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.222-b10, mixed mode)
Windows:
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_192-b12)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.192-b12, mixed mode)
We’ve also reproduced this issue with multiple Tomcat versions, including 7, 8
& 9. If we use Oracle Java, the issue is fixed & doesn’t happen. The bug is
very subtle since the JSP does compile, but the data passed to our tag is a
String instead of a Date object.
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com<http://www.cerner.com/>
From: Felix Schumacher
<felix.schumac...@internetallee.de<mailto:felix.schumac...@internetallee.de><mailto:felix.schumac...@internetallee.de><mailto:felix.schumac...@internetallee.de%3e>>
Reply-To: Tomcat Users List
<users@tomcat.apache.org<mailto:users@tomcat.apache.org><mailto:users@tomcat.apache.org><mailto:users@tomcat.apache.org%3e>>
Date: Saturday, October 26, 2019 at 4:18 PM
To: Tomcat Users List
<users@tomcat.apache.org<mailto:users@tomcat.apache.org><mailto:users@tomcat.apache.org><mailto:users@tomcat.apache.org%3e>>
Subject: Re: JSP custom tag operating different when adoptOpenJDK is used vs
Oracle (cross post from tomcat-taglibs-user)
Am 25. Oktober 2019 19:33:19 MESZ schrieb "LoBello,Jeff"
<jeff.lobe...@cerner.com.INVALID<mailto:jeff.lobe...@cerner.com.INVALID><mailto:jeff.lobe...@cerner.com.INVALID><mailto:jeff.lobe...@cerner.com.INVALID><mailto:jeff.lobe...@cerner.com.INVALID%3e><mailto:jeff.lobe...@cerner.com.INVALID%3e%3cmailto:jeff.lobe...@cerner.com.INVALID%3e%3cmailto:jeff.lobe...@cerner.com.INVALID%3e%3e>>:
We have a custom tag, FormatDateTag extends
org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport. It’s
been working ok for a number of years under tomcat & Oracle JVM. Now,
we are moving to adoptOpenJDK & we are seeing some differences in how
tomcat generation of JSP to Java classes happens when tomcat is doing
the EL evaluation. Here is an example JSP which shows the issue…
Which Java versions have you used exactly? What os was this? Which tomcat
version have you used?
Are there any other differences in the setup?
Felix
<%@ page language="java" contentType="text/html" isELIgnored="false" %>
<%@ page import="java.util.Date" %>
<%@ taglib uri="/WEB-INF/tld/suitags.tld" prefix="sui" %>
<%
Date chdt = new Date();
request.setAttribute("chdt", chdt);
%>
<sui:formatDate value="${chdt}" type="date" dateStyle="shortfull" />
Looking at the compiled JSP source code under Oracle JVM, we see this…
// /tagUnitTests/sui/formatDate/testCaliHDateTime1.jsp(20,0) name =
value type = java.lang.Object reqTime = true required = true fragment =
false deferredValue = false expectedTypeName = null deferredMethod =
false methodSignature = null
_jspx_th_sui_005fformatDate_005f0.setValue((java.lang.Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${chdt}",
java.lang.Object.class,
(javax.servlet.jsp.PageContext)_jspx_page_context, null));
The same source compiled using AdoptOpenJDK, we see this…
// /tagUnitTests/sui/formatDate/ testCaliHDateTime1.jsp(20,0) name =
value type = java.lang.Object reqTime = true required = true fragment =
false deferredValue = false expectedTypeName = null deferredMethod =
false methodSignature = null
_jspx_th_sui_005fformatDate_005f0.setValue((java.lang.String)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${chdt}",
java.lang.String.class,
(javax.servlet.jsp.PageContext)_jspx_page_context, null));
As a workaround, we’re adding calls to <fmt:parseDate> to convert the
String back to a Date. Has anyone run into this? Any ideas we can try
to find the root cause?
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com<http://www.cerner.com/>
CONFIDENTIALITY NOTICE This message and any included attachments are
from Cerner Corporation and are intended only for the addressee. The
information contained in this message is confidential and may
constitute inside or non-public information under international,
federal, or state securities laws. Unauthorized forwarding, printing,
copying, distribution, or use of such information is strictly
prohibited and may be unlawful. If you are not the addressee, please
promptly delete this message and notify the sender of the delivery
error by e-mail or you may call Cerner's corporate offices in Kansas
City, Missouri, U.S.A at (+1) (816)221-1024.
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org><mailto:users-unsubscr...@tomcat.apache.org><mailto:users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org%3e%3cmailto:users-unsubscr...@tomcat.apache.org>>
For additional commands, e-mail:
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org><mailto:users-h...@tomcat.apache.org><mailto:users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org%3e%3cmailto:users-h...@tomcat.apache.org>>
CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities laws.
Unauthorized forwarding, printing, copying, distribution, or use of such
information is strictly prohibited and may be unlawful. If you are not the
addressee, please promptly delete this message and notify the sender of the
delivery error by e-mail or you may call Cerner's corporate offices in Kansas
City, Missouri, U.S.A at (+1) (816)221-1024.
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org><mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail:
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org><mailto:users-h...@tomcat.apache.org>
