Re: Any tutorials or hints about JSP using javax.script engines instead of Java?
I'm a little confused. What would one hope to gain by doing this? On 10/8/2019 9:11 AM, Rony G. Flatscher (Apache) wrote: Does anyone know of any tutorials that would demonstrate how to use any javax.script language in JSPs instead of Java (e.g. using Jython or JavaScript instead)? If not, any advice/hint how to realize/create such a functionality (for then creating such a tutorial instead) would be highly appreciated! ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George S. *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Any tutorials or hints about JSP using javax.script engines instead of Java?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rony,
On 10/10/19 08:16, Rony G. Flatscher (Apache) wrote:
> Hi Chris,
>
>> On 10/9/19 07:08, Rony G. Flatscher (Apache) wrote:
>>> On 08.10.2019 21:16, André Warnier (tomcat) wrote:
On 08.10.2019 17:11, Rony G. Flatscher (Apache) wrote:
> Does anyone know of any tutorials that would demonstrate
> how to use any javax.script language in JSPs instead of
> Java (e.g. using Jython or JavaScript instead)?
>
> ... cut ...
>
>> My own (particularly uninformed) opinion is that most scripting
>> languages that have wanted to get into JVMs/app servers have
>> simply built their own technologies to handle everything, so it
>> doesn't run through JSP itself.
>>
>> For example, Lucee[1] is a CFML implementation in Java, but it
>> doesn't (always) use JSP. They have a separate "interpreter" for
>> it instead of building huge tag libraries to fit it into JSP. (I
>> say "interpreted" because I don't know if they actually interpret
>> the files each time on demand, or if there is a compilation step
>> at some point. It doesn't really matter either way.)
>>
>> I haven't looked at it in depth, but I believe this is also what
>> Apache JGroovy[2] does.
>>
>> -chris
>>
>> [1] https://lucee.org/ [2] https://groovy-lang.org/
>
> Maybe if some standard "script" taglib library for javax.script
> languages existed like the proof-of-concept one in [1] then that
> could be exploited/(re)used rather than coming up with non-standard
> implementations of their own.
I hesitate to say this due to your previous experience with tag
libraries, but ... a tag library is basically a JSP thing which
obviates the need to use any actual Java in the JSP file.
(My statements here are basically already covered in the publication;
I'm re-itterating them, here for emphasis and clarification.)
There isn't anything inherently Java-esque about any of the existing
tag libraries (e.g. JSTL), and once you have converted a page filled
with spaghetti Java code in scriptlets (e.g. <% java goes here %>)
into one that exclusively uses tag libraries, the implications of
using <%@page language="java" instead of e.g. language="jython" or
whatever kind of evaporate.
That is, if you write a tag library, then:
1. Using the taglib in the JSP file isn't using Java
2. Using the taglib in the JSP isn't using the other language,
either... instead, it's using ... taglib-lang or whatever you want to
call that
So if you want to do this:
<%@page
language="c"
import=""
%>
<%
println("Hello, world!\n");
%>
Then you'd need to get a "language" binding in JSP.
But instead, if you want to to this:
<%@page language="doesntmatter"%>
Hello, world!
Then you can implement the tag library using any programming language
you want, as long as you are able to register it properly with the JSP
servlet and have it respond to the calls targeted at the tag library
interface(s) you have implemented.
IMHO, the BSF taglib is a project that deserved to die. It took all of
the horrible possibilities of Java scriptlets in JSPs and made the
language pluggable so that you could have garbage spaghetti code in
your language of choice packaged inside of a JSP. Good riddance.
Resurrecting the capabilities of the BSF taglib is, again IMHO, a
waste of effort. That effort would be better spent creating better (or
more diverse) tag libraries that don't expose the concept of
"scriptlets" to the programmer /at all/.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2g7NEACgkQHPApP6U8
pFgNGA/8CFNKcfIOzf52FC2Nu0/LfC0TQ36+mSazkLloMkqXCBhI85yKXw55Mz94
fdLXFqN1mX0ZXnUgAXmer3MPBBdNceENjv8AjkhHKqXFUOTboXbg2/2XpYguddne
itM5XKHqhq4k8uG9wXnrgAOhrNTAOtaRKOaq4Lg9USinhdfVUrn+3OCyn8+eydzs
k096HMao/Li221y9vAoc+1iJPM3qWthgQA6GTrvdWIsqBiP0WOTT0XO6ifzDf5SX
0UmfYr7E6m5vAFBG0vieqjgA9U6OgOX59Dzc3a0XSF7ifWdmQbMntU6Rbaw7yIPb
gBdChMZeVIE89IlM3WY8jBcEjlK0FZVGjcEnPbCIQ8xdJscFpeK4Pn5vlCiXtWwM
2RcioHKSRu9OKpWN+uz7WqvNIwkbMyd1S+AKbqJxd2k2UN5yn2bKNc6SKIW4hJ9w
Srz1UE2yR/rAXlvNgtZy6gJSOE7mh+YtsrrawIUGXUOazOKkwTip6dve7xVLhLEm
RVgMlu4YOK6rMzDL8kydaNNKSw8csCuNyEpFjhwW+aKvUY3qhziRcGEF25rtkRaw
6WcnAl2sMPqcZJKLxzOQezgkzfPfJsUWMIYihtec65lV7XtKQJvCSOLLXBU272aa
yCp158Mqlkukt7Yi3kxHgCuCFaeYdi9JZrsdguAhyyOV8OISy+w=
=6QJV
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory Leakage Problem in Tomcat 7.0.94
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/11/19 00:52, ankitr.de...@spec-india.com wrote: >> 1. Allow Tomcat to clear these references, and otherwise ignore >> the error messages> > Can you please let us know how to Allow Tomcat to clear these> > references? Have another look at the log message: >> SEVERE: The web application [/TLSAdmin] created a ThreadLocal >> with key of type [java.lang.ThreadLocal] (value >> [java.lang.ThreadLocal@794fa987]) and a value of type >> [flex.messaging.config.SystemSettings] (value >> [flex.messaging.config.SystemSettings@7dca495e]) but failed to >> remove it when the web application was stopped. Threads are going >> to be renewed over time to try and avoid a probable memory leak. Tomcat is already protecting the heap by clearing these ThreadLocal references for you. It may take some time, and your application won't cleanly undeploy until all the threads have been "renewed". - -chris > -Original Message- From: Christopher Schultz > Sent: 10 October 2019 11:08 PM To: > users@tomcat.apache.org Subject: Re: Memory Leakage Problem in > Tomcat 7.0.94 > > Ankit, > > On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: >> We are using Tomcat 7.0.94 version and we have facing memory >> leakage issue when tomcat server is going to shutdown. > >> Please help in this case, how to solve these kind of logs? > >> Please find below sample logs from catalina.log file and code. > > > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> clearReferencesThreads > >> SEVERE: The web application [/TLSAdmin] appears to have started a >> thread named [Timer-0] but has failed to stop it. This is very >> likely to create a memory leak. > > Your application started this thread and hasn't stopped it. (See > below) > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> clearReferencesThreads > >> SEVERE: The web application [/TLSAdmin] appears to have started a >> thread named [schedulerFactory_Worker-1] but has failed to stop >> it. This is very likely to create a memory leak. > > Same here, except it's likely to be a thread pool with a number of > threads with similar names. > > To fix the thread issues, you need to find the place in your code > where the threads are started (or the threadpool is created) and > make sure that you have access to that thread (or pool) during > application shutdown. Storing stuff like this in the application > (context) scope is one way to do it. > > I would recommend another ServletContextListener that locates those > threads (pools) and stops them. Remember that Thread.stop() doesn't > really work. Instead, you have to let the thread know that it's > time to stop itself. > > Threads called "Timer-X" are usually simple threads created by > java.util.TimerTask and friends, and you should be able to store a > reference to the task and stop it on app shutdown. > >> [snip] > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> checkThreadLocalMapForLeaks > >> SEVERE: The web application [/TLSAdmin] created a ThreadLocal >> with key of type [java.lang.ThreadLocal] (value >> [java.lang.ThreadLocal@794fa987]) and a value of type >> [flex.messaging.config.SystemSettings] (value >> [flex.messaging.config.SystemSettings@7dca495e]) but failed to >> remove it when the web application was stopped. Threads are going >> to be renewed over time to try and avoid a probable memory leak. > > Something in "flex" has put an object in ThreadLocal storage and > never removed it. This is harder to fix than the threading stuff > because you each thread needs to purge the ThreadLocal objects in > order to "clean" the system. > > You have two options, really: > > 1. Allow Tomcat to clear these references, and otherwise ignore the > error messages. > > 2. Change your application so that at the end of each request you > remove these ThreadLocal values from the request-processing > thread. > > Hope that helps, -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2gj7EACgkQHPApP6U8 pFhDmQ/9GAOJC1DyXiJQ8vMYi6l9s+DfuMFyCDJniuF+AqcHJ9e0k+2aDtETqR/z xGyAoia3nFrLwRXdQAPRqfZDyLAJijWb4WxlWl3P0QxPV/l1nNJgco6j1no8vzNL 14azDixoWANDHd4wx6eu0y0+/pTr+PgEl/CSa3RBvEMvu3zDPfU5mV5ebaYuXDMH e5n+f3/7VQAvxpIPnGQNC6AUtBv+65pUpL4M4e/QRrey1p2tTJPl2vBq3ViIBs4l mufkv9FW4YhgovFXMCZmpAWl1VrOTnTBcQ5xL5LTk3Nynh1uiREdf0HxusJLD4Xa 3VRpDlP6CeOCZm4lkwWQQmTd2eBaKDKx0pQe9M3Hn9WLHnHaMM0UgzXAvNJptzUk vudzUPM4sBh6BncKyBMO9G+Yae6zQZ7XQEfyX+ITkPiX0bk2xeHGHiBO7J0VGHsP dE9JnGWyAoRR132ZyevzPmxarEQeiwway0uLT1v/J5zee+ViPWSM/mutSFSJ6qqB OmJnEeepBVqRxFc8IoYE6FCUQ5BdkDi+EkFQ1zSyLALDDdXkVeaKp4snH3lftX8H aLMpOETXk293vidg0LDscQ
efficient redirect map with embedded Tomcat
This is a question for Tomcat experts before I get started implementing a new feature. Let's say I'm embedding Tomcat to serve static files. At the time of creation I know that certain paths, such as `foo/bar.txt`, should redirect to other paths, such as `some/other.txt`. What's the best way to configure Tomcat to do those redirects? I'm comfortable with extending the source code. Here are a couple of ideas that come to mind: * I could create a redirect servlet and map different instances of it to different targets in the context when I configure everything. But in Tomcat's routing engine, is the most efficient way to do things? (I assume that the servlet mappings can be placed "over" the default servlet's path space, that is, cherry-pick paths for redirection, falling back to the default file-serving servlet for non-redirect paths.) * I thought of patching into the default file servlet, overriding `org.apache.catalina.WebResource`, and creating virtual `RedirectResource` resources that don't correspond to any physical file. However it's not obvious to me where I would create a redirect. Maybe throw some redirect exception inside `WebResource.getInputStream()`? (This is probably not correct. I'm just brainstorming. The idea is sound if I knew where to put it.) * Should I install a configured rewrite valve when I'm setting up embedded Tomcat? * Is there some other routing logic in Tomcat I could tap into most efficiently, providing a known set of redirects? Thanks for any guidance. I'm want to figure out the best way to attack this before getting very deep in an implementation. Garret
RE: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib
We continue to profile our application and have found instances of using TransformerFactory.newInstance(). The more concerning problem is third party dependencies that do this or something similar we could not fix. Jar modified times are not changing - I did not mean to state or otherwise imply that. -Original Message- From: john.e.gr...@wellsfargo.com.INVALID Sent: Thursday, October 10, 2019 6:54 PM To: users@tomcat.apache.org Subject: RE: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib Tony, > -Original Message- > From: Rhuberg,Anthony > Sent: Thursday, October 10, 2019 5:22 PM > To: Tomcat Users List > Subject: RE: Performance test with Tomcat 9 shows increased cpu/disk > usage because of repeated opening/closing of jars in WEB-INF/lib > > We are still investigating what specific classloader reads that would > trigger the repeated reload of the web-inf/lib/*.jars. > > One example we found is the use of > javax.xml.transform.TransformerFactory.newInstance(). One of its > features is to determine the implementation by searching for the > configuration specified by > META-INF/services/javax.xml.transform.TransformerFactory in jars available to > the runtime. > Yep. I was wondering about that. I have no idea why this behavior would be different in Tomcat 9, though. Did you change Java versions also? Is the classpath longer? I also have no idea about the jar modification date changes that you're seeing. I do have first-hand experience with the performance of TransformerFactory.newInstance(). In general, anything that uses the service locator under the covers, such as TransformerFactory, DocumentBuilderFactory, etc, should be reused if possible. Those XML factories are thread safe, though the things created by the factories are typically not thread safe. You should create it once, configure it once, and use it as many times as necessary. For example, you would create one TransformerFactory, then call newTransformer() as many times as necessary. John B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B 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 For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting samesite attribute on JSESSIONID
On Thu, Oct 10, 2019 at 2:08 PM David Cleary wrote: > Have a customer asking about this. I see Tomcat supports it here. > https://tomcat.apache.org/tomcat-9.0-doc/config/cookie-processor.html > > We currently use defaults, so I'm looking for an XML fragment and the file > it goes in to add the samesite attribute to the JSESSIONID. I'm assuming > they want it globally for all webapps. > After Christopher Schultz pointed me in the right direction, I added the following line to $CATALINA_BASE/conf/context.xml This allowed my JAMstack app to set a JSESSIONID from a REST app running under Tomcat on a different server. -- "Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, *Doctor Faustus* (v. 111-13)
Re: tomcat with SiteMinder
On 11.10.2019 05:11, Bauer, Margaret M (Peggy) wrote: Has anyone used tomcat with SiteMinder without having a webserver in front of it? If so, where can I find the how to? In the SiteMinder documentation ? (No kidding. As I recall, they do provide examples with multiple webservers.) thank you, *Peggy * - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
