JSP custom tag operating different when adoptOpenJDK is used vs Oracle (cross post from tomcat-taglibs-user)

2019-10-25 Thread LoBello,Jeff
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…

<%@ 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);
%>



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  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




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.


What's the purpose of this code, that logs a seemingly meaningless and possibly misleading exception?

2019-10-25 Thread Behrang Saeedzadeh
>From Tomcat Embedded Core 9.0.26:

@Override
protected void doClose() {
if (log.isDebugEnabled()) {
log.debug("Calling [" + getEndpoint() + "].closeSocket([" +
this + "])", new Exception());
}

Which will log something like:

DEBUG [http-nio-8080-exec-2]
org.apache.tomcat.util.net.NioEndpoint
Calling [org.apache.tomcat.util.net.NioEndpoint@654c1a54
].closeSocket([org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@39e9d240
:org.apache.tomcat.util.net.NioChannel@78019ed5:java.nio.channels.SocketChannel[connected
local=/127.0.0.1:8080 remote=/127.0.0.1:39988]])

java.lang.Exception: null
at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doClose(NioEndpoint.java:1165)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at
org.apache.tomcat.util.net.SocketWrapperBase.close(SocketWrapperBase.java:394)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at
org.apache.tomcat.util.net.NioEndpoint$Poller.cancelledKey(NioEndpoint.java:667)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[na:1.8.0_212]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_212]
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[tomcat-embed-core-9.0.26.jar:9.0.26]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_212]

To print the stack trace next to the message? Every time I turn on debug
logging this exception catches me by surprise. Why not only print the stack
trace next using
org.apache.commons.lang3.exception.ExceptionUtils.getStackTrace for example?

Best regards,
Behrang Saeedzadeh
blog.behrang.org