Re: Question ad 2021 presentation videos

[Rony G. Flatscher (Apache)]

Hi Chris,

On 28.06.2022 15:31, Christopher Schultz wrote:


On 6/28/22 05:44, Rony G. Flatscher (Apache) wrote:

Is there a link for the 2021 Tomcat presentation videos, if any?


Oh, I'm sorry. I was working on getting those onto the Presentations page and I got distracted and 
didn't finish.


I'll try to get back to that, today.


Thank you!

---rony


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

Re: Question ad 2021 presentation videos

[Rony G. Flatscher (Apache)]

Hi Coty,

On 28.06.2022 15:07, Coty Sutherland wrote:

On Tue, Jun 28, 2022 at 5:44 AM Rony G. Flatscher (Apache) 
wrote:


Is there a link for the 2021 Tomcat presentation videos, if any?


Is the playlist at
https://www.youtube.com/playlist?list=PLU2OcwpQkYCyq45LTYr07svnrCGarSWs7
what you're looking for?


thank you very much that helps already a lot! I have been asked a couple of times about the 
presentation "Apache Tomcat: Enabling Scripting Languages in JSPs" as it demonstrates how to use 
Groovy, JavaScript, Jython, ooRexx and PHP in JSPs (and for that matter any Java scripting language, 
i.e. any scripting language that implements javax.script.ScriptEngine). Your link allows one to pick 
that presentation right away!


Thank you very much!

---rony


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

Question ad 2021 presentation videos

[Rony G. Flatscher (Apache)]

Is there a link for the 2021 Tomcat presentation videos, if any?

---rony




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

Re: AW: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

Hi Konstantin,

On 23.03.2022 23:29, Konstantin Kolinko wrote:
> ср, 23 мар. 2022 г. в 14:12, Rony G. Flatscher (Apache) :
>> skip...
>>
>> startup.bat uses start to run catalina.bat in a new cmd window with:
>>
>> call "%EXECUTABLE%" start %CMD_LINE_ARGS%
>>
>> catalina.bat then starts Tomcat as:
>>
>> %_EXECJAVA% %CATALINA_LOGGING_CONFIG% %LOGGING_MANAGER% %JAVA_OPTS% 
>> %CATALINA_OPTS% %DEBUG_OPTS%
>> -D%ENDORSED_PROP%="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"
>> -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"
>> -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% 2>&1 1>
>> D:\orx.debug\work_rii_tomcat\test.log
>>
>> This does not work.
> (It does not matter, but you somehow lost "%ACTION%" at the end of the
> above line.)
>
> If I prefix the above line with "echo" to see what command is being
> executed, like this:
>
> echo %_EXECJAVA% %CATALINA_LOGGING_CONFIG% %LOGGING_MANAGER%
> %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS%
> -D%ENDORSED_PROP%="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"
> -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"
> -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS%
> %ACTION% 1>>mylog.txt 2>&1
>
> then I get the following results:
>
> a) After calling "startup.bat" or "catalina.bat start" I see the
> following in mylog.txt:
>
> start "Tomcat" "C:\pathtojava\java.exe" .
> org.apache.catalina.startup.Bootstrap start
>
> b) After calling "catalina.bat run" I see the following:
>
> "C:\pathtojava\java.exe" . org.apache.catalina.startup.Bootstrap start
>
> Note the difference.
>
> It is the "start" command that creates a new window.  The "call"
> command that you mentioned is just a command to execute a different
> batch file and return to continue executing the original batch file.
>
> BTW, commands "help start" and "help call" print some reference for
> those commands.
>
>
> Looking at the reference for "start", I think your only option is to
> use "catalina.bat run" to start Tomcat. When I do so, the redirection
> works as expected.
>
>
> The following also works, without any modifications to the catalina.bat file:
>
> catalina.bat run 1>>mylog.txt 2>&1
>
> or with remote debugging being enabled:
>
> catalina.bat jpda run 1>>mylog.txt 2>&1

thank you very much for your information and explanations which solves this, 
many thanks!

(Was not aware of "catalina.bat run" and the like, adding to that your 
step-by-step explanations
made it a breeze to get this up and running as a result!)

Kudos!

---rony



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

Re: AW: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 23.03.2022 18:21, EXT-Denton, Sam T wrote:
> I believe that "2>&1 1>D:\orx.debug\work_rii_tomcat\test.log" will first 
> redirect stderr to stdout, and then redirect stdout to the file, leaving 
> stderr pointing to the original stdout, which is presumably the terminal.
>
> Try "1>D:\orx.debug\work_rii_tomcat\test.log 2>&1"

Thank you, this does not change the behaviour.

---rony


>
>
> -Original Message-
> From: Rony G. Flatscher (Apache)  
> Sent: Wednesday, March 23, 2022 6:12 AM
> To: users@tomcat.apache.org
> Subject: Re: AW: Maybe a stupid (Windows related) question
>
> On 23.03.2022 11:45, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> -Ursprüngliche Nachricht-
>>> Von: Rony G. Flatscher (Apache) 
>>> Gesendet: Mittwoch, 23. März 2022 11:34
>>> An: users@tomcat.apache.org
>>> Betreff: Re: Maybe a stupid (Windows related) question
>>>
>>> On 22.03.2022 20:18, Christopher Schultz wrote:
>>>
>>> ... cut ...
>>>
>>>> You still can't really "background" the process the way you can on
>>>> *nix. Sure, you can get your command-prompt back, but if you kill
>>>> cmd.exe, so does your child process die. And if you log out, that process
>>> dies as well.
>>>
>>> The problem is different: redirecting stderr and stdout does not redirect in
>>> this scenario (employing %CATALINA_HOME%\bin\startup.bat), rather
>>> output statements to stderr
>>> (System.err.println(...)) and stdout (System.out.println(...)) gets still
>>> displayed in the Tomcat window.
>>>
>>> This involves (at least in my experiments) editing bin\startup.bat and/or
>>> bin\catalina.bat which should not be necessary if understanding Tomcat's
>>> philsophy correctly. If adjustments are necessary it is advised to supply a
>>> "bin\setup.bat" script to do so.
>>>
>>> So what I would be looking for is either a configuration change or an
>>> environment variable to set which allows redirecting stdout and stderr to
>>> appropriate log files as is done with the service version by default.
>>>
>>>> Using the Windows Service is really the best way to do it on Windows.
>>> The use case is testing Tomcat 10 in various ways, including running it in
>>> debug mode and attaching via IntelliJ for inspection.
>>>
>>> ---rony
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> The bat-file uses the line:
>> call "%EXECUTABLE%" start %CMD_LINE_ARGS%
>>
>> At this place you might be able to redirect the output:
>> call "%EXECUTABLE%" start %CMD_LINE_ARGS%  > out.log
>>
>> You could also try to pass the redirect param to the argument of 
>> startup.bat, don’t know if this works, e.g.
>> startup.bat " > out.log"
> startup.bat uses start to run catalina.bat in a new cmd window with:
>
> call "%EXECUTABLE%" start %CMD_LINE_ARGS%
>
> catalina.bat then starts Tomcat as:
>
> %_EXECJAVA% %CATALINA_LOGGING_CONFIG% %LOGGING_MANAGER% %JAVA_OPTS% 
> %CATALINA_OPTS% %DEBUG_OPTS%
> -D%ENDORSED_PROP%="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"
> -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"
> -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% 2>&1 1>
> D:\orx.debug\work_rii_tomcat\test.log
>
> This does not work.
>
> ---rony
>
>

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

Re: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 23.03.2022 13:22, Mark Thomas wrote:
> On 23/03/2022 10:34, Rony G. Flatscher (Apache) wrote:
>> The use case is testing Tomcat 10 in various ways, including running it in 
>> debug mode and attaching
>> via IntelliJ for inspection.
>
> You can still do this when Tomcat is running as a service. Just set the 
> appropriate properties.

Yes, looks like I will have to do it that way.

(Currently I have a Tomcat 10 service installation that I shutdown and then run 
a different (newer),
separate Tomcat installation for testing purposes for which I need the 
redirection of stdout and
stderr.)

---rony



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

Re: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 23.03.2022 12:11, Rony G. Flatscher (Apache) wrote:
> On 23.03.2022 11:51, Konstantin Kolinko wrote:
>> вт, 22 мар. 2022 г. в 20:21, Rony G. Flatscher (Apache) :
>>> For debugging purposes I downloaded the zip-version of Tomcat 10.0.18 and 
>>> start it up using
>>> %CATALINA_HOME%\bin\startup.bat.
>>>
>>> 
>>>
>>> Probably I have been doing something wrong in the past hours and not seeing 
>>> the forest for the trees
>>> anymore I kindly request help: what is needed to successfully redirect 
>>> stderr and stdout to
>>> %CATALINA_HOME%\logs after unzipping Tomcat 10 and starting it on Windows 
>>> using
>>> %CATALINA_HOME%\bin\startup.bat?
>>>
>>> TIA for any help/pointer!
>> First, I second Chris's answer
>>
>> вт, 22 мар. 2022 г. в 22:19, Christopher Schultz 
>> :
>>> 
>>>
>>> ... Windows CAN redirect both stdout and stderr to
>>> two different places, and also to combine them just like you can on *nix:
>>>
>>> bin\catalina.bat run 2>&1 > stdout_stderr.log
>>>
>>> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490982(v=technet.10)?redirectedfrom=MSDN
>>>
>> Note that
>> "startup.bat" is an equivalent of calling "catalina.bat start".
>> "shutdown.bat" is an equivalent of "catalina.bat stop".
>>
>> The above command (with " run") is a different one:
>> it starts Tomcat in the same console window, as opposed to " start"
>> that opens a new console window.
>>
>> Second,
>> To redirect java.util.logging output to a file, replace ConsoleHandler
>> in conf/logging.properties with a FileHandler that writes all those
>> log lines to a file.
>>
>> Actually, logging.properties already has such a FileHandler
>> configured. See the following line:
>>
>> .handlers = 1catalina.org.apache.juli.AsyncFileHandler,
>> java.util.logging.ConsoleHandler
>>
>> It configures handlers for "." (the root). So all the same information
>> is also being written to a "1catalina" FileHandler. Removing the
>> "ConsoleHandler" from that line will stop duplicating all those log
>> messages to the console.
> The %CATALINA_HOME%\conf\logging.properties got changed according to
> <https://serverfault.com/questions/252934/how-to-redirect-tomcat-console-log-to-files-tomcat-started-via-windows-bat>
> as:
>
> handlers = 1catalina.org.apache.juli.AsyncFileHandler,
> 2localhost.org.apache.juli.AsyncFileHandler, 
> 3manager.org.apache.juli.Async
> FileHandler, 4host-manager.org.apache.juli.AsyncFileHandler, 
> java.util.logging.ConsoleHandler
>
> # .handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
> java.util.logging.ConsoleHandler
>
> .handlers = 1catalina.org.apache.juli.AsyncFileHandler
>
> ... cut ...
>
> Still stdout and stderr goes to the console. The redirection "2>&1 >test.log" 
> creates the empty file
> but no output is there.
>
>> Third,
>> If you app is actually calling System.err.println(), see about
>> "swallowOutput" setting here
>> https://tomcat.apache.org/tomcat-10.0-doc/logging.html#Console
>> https://tomcat.apache.org/tomcat-10.0-doc/config/context.html
> Will try that next thank you!

Tried two ways:

  * %CATALINA_HOME%\conf\context.xml adding attribute, so " only

Did not make a difference.

Having permutated so many different things I will delete everything and start 
over with a pristine
unzipped Tomcat 10 to see if that makes a difference.

---rony

Re: AW: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 23.03.2022 11:45, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>> -Ursprüngliche Nachricht-
>> Von: Rony G. Flatscher (Apache) 
>> Gesendet: Mittwoch, 23. März 2022 11:34
>> An: users@tomcat.apache.org
>> Betreff: Re: Maybe a stupid (Windows related) question
>>
>> On 22.03.2022 20:18, Christopher Schultz wrote:
>>
>> ... cut ...
>>
>>> You still can't really "background" the process the way you can on
>>> *nix. Sure, you can get your command-prompt back, but if you kill
>>> cmd.exe, so does your child process die. And if you log out, that process
>> dies as well.
>>
>> The problem is different: redirecting stderr and stdout does not redirect in
>> this scenario (employing %CATALINA_HOME%\bin\startup.bat), rather
>> output statements to stderr
>> (System.err.println(...)) and stdout (System.out.println(...)) gets still
>> displayed in the Tomcat window.
>>
>> This involves (at least in my experiments) editing bin\startup.bat and/or
>> bin\catalina.bat which should not be necessary if understanding Tomcat's
>> philsophy correctly. If adjustments are necessary it is advised to supply a
>> "bin\setup.bat" script to do so.
>>
>> So what I would be looking for is either a configuration change or an
>> environment variable to set which allows redirecting stdout and stderr to
>> appropriate log files as is done with the service version by default.
>>
>>> Using the Windows Service is really the best way to do it on Windows.
>> The use case is testing Tomcat 10 in various ways, including running it in
>> debug mode and attaching via IntelliJ for inspection.
>>
>> ---rony
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> The bat-file uses the line:
> call "%EXECUTABLE%" start %CMD_LINE_ARGS%
>
> At this place you might be able to redirect the output:
> call "%EXECUTABLE%" start %CMD_LINE_ARGS%  > out.log
>
> You could also try to pass the redirect param to the argument of startup.bat, 
> don’t know if this works, e.g.
> startup.bat " > out.log"

startup.bat uses start to run catalina.bat in a new cmd window with:

call "%EXECUTABLE%" start %CMD_LINE_ARGS%

catalina.bat then starts Tomcat as:

%_EXECJAVA% %CATALINA_LOGGING_CONFIG% %LOGGING_MANAGER% %JAVA_OPTS% 
%CATALINA_OPTS% %DEBUG_OPTS%
-D%ENDORSED_PROP%="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"
-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"
-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% 2>&1 1>
D:\orx.debug\work_rii_tomcat\test.log

This does not work.

---rony

Re: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 23.03.2022 11:51, Konstantin Kolinko wrote:
> вт, 22 мар. 2022 г. в 20:21, Rony G. Flatscher (Apache) :
>> For debugging purposes I downloaded the zip-version of Tomcat 10.0.18 and 
>> start it up using
>> %CATALINA_HOME%\bin\startup.bat.
>>
>> 
>>
>> Probably I have been doing something wrong in the past hours and not seeing 
>> the forest for the trees
>> anymore I kindly request help: what is needed to successfully redirect 
>> stderr and stdout to
>> %CATALINA_HOME%\logs after unzipping Tomcat 10 and starting it on Windows 
>> using
>> %CATALINA_HOME%\bin\startup.bat?
>>
>> TIA for any help/pointer!
> First, I second Chris's answer
>
> вт, 22 мар. 2022 г. в 22:19, Christopher Schultz 
> :
>> 
>>
>> ... Windows CAN redirect both stdout and stderr to
>> two different places, and also to combine them just like you can on *nix:
>>
>> bin\catalina.bat run 2>&1 > stdout_stderr.log
>>
>> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490982(v=technet.10)?redirectedfrom=MSDN
>>
> Note that
> "startup.bat" is an equivalent of calling "catalina.bat start".
> "shutdown.bat" is an equivalent of "catalina.bat stop".
>
> The above command (with " run") is a different one:
> it starts Tomcat in the same console window, as opposed to " start"
> that opens a new console window.
>
> Second,
> To redirect java.util.logging output to a file, replace ConsoleHandler
> in conf/logging.properties with a FileHandler that writes all those
> log lines to a file.
>
> Actually, logging.properties already has such a FileHandler
> configured. See the following line:
>
> .handlers = 1catalina.org.apache.juli.AsyncFileHandler,
> java.util.logging.ConsoleHandler
>
> It configures handlers for "." (the root). So all the same information
> is also being written to a "1catalina" FileHandler. Removing the
> "ConsoleHandler" from that line will stop duplicating all those log
> messages to the console.

The %CATALINA_HOME%\conf\logging.properties got changed according to
<https://serverfault.com/questions/252934/how-to-redirect-tomcat-console-log-to-files-tomcat-started-via-windows-bat>
as:

handlers = 1catalina.org.apache.juli.AsyncFileHandler,
2localhost.org.apache.juli.AsyncFileHandler, 3manager.org.apache.juli.Async
FileHandler, 4host-manager.org.apache.juli.AsyncFileHandler, 
java.util.logging.ConsoleHandler

# .handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.AsyncFileHandler

... cut ...

Still stdout and stderr goes to the console. The redirection "2>&1 >test.log" 
creates the empty file
but no output is there.

> Third,
> If you app is actually calling System.err.println(), see about
> "swallowOutput" setting here
> https://tomcat.apache.org/tomcat-10.0-doc/logging.html#Console
> https://tomcat.apache.org/tomcat-10.0-doc/config/context.html

Will try that next thank you!

---rony

Re: Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

On 22.03.2022 20:18, Christopher Schultz wrote:

... cut ...

> You still can't really "background" the process the way you can on *nix. 
> Sure, you can get your
> command-prompt back, but if you kill cmd.exe, so does your child process die. 
> And if you log out,
> that process dies as well.

The problem is different: redirecting stderr and stdout does not redirect in 
this scenario
(employing %CATALINA_HOME%\bin\startup.bat), rather output statements to stderr
(System.err.println(...)) and stdout (System.out.println(...)) gets still 
displayed in the Tomcat
window.

This involves (at least in my experiments) editing bin\startup.bat and/or 
bin\catalina.bat which
should not be necessary if understanding Tomcat's philsophy correctly. If 
adjustments are necessary
it is advised to supply a "bin\setup.bat" script to do so.

So what I would be looking for is either a configuration change or an 
environment variable to set
which allows redirecting stdout and stderr to appropriate log files as is done 
with the service
version by default.

> Using the Windows Service is really the best way to do it on Windows.

The use case is testing Tomcat 10 in various ways, including running it in 
debug mode and attaching
via IntelliJ for inspection.

---rony

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

Maybe a stupid (Windows related) question

[Rony G. Flatscher (Apache)]

For debugging purposes I downloaded the zip-version of Tomcat 10.0.18 and start 
it up using
%CATALINA_HOME%\bin\startup.bat.

This will create by default a separate process (terminal, commandline window) 
in which Tomcat runs
and dispatches all output including stdout and stderr output into that window.

By contrast the Windows service installation would redirect stdout and stderr 
by default to
%CATALINA_HOME%\logs\ using "tomcat10-stderr.yyy-mm-dd.log" and 
"tomcat10-stdout.-mm-dd.log" as
their name. The same would be desired for the "startup.bat" version of Tomcat 
10.

Searched  and
 to no avail. Searching 
the Internet the best
I could find
was

which indeed redirects the Tomcat startup information to
%CATALINA_HOME%\logs\catalina.-mm-dd.log, but not stdout and stderr which 
do not get redirected.
Using redirections directly in "startup.bat" or "catalina.bat" as suggested 
further down in the
serverfault.com did not yield the desired redirection.

Probably I have been doing something wrong in the past hours and not seeing the 
forest for the trees
anymore I kindly request help: what is needed to successfully redirect stderr 
and stdout to
%CATALINA_HOME%\logs after unzipping Tomcat 10 and starting it on Windows using
%CATALINA_HOME%\bin\startup.bat?

TIA for any help/pointer!

---rony



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

Re: ApacheCon@Home, Tomcat-Track, request for input ...

[Rony G. Flatscher (Apache)]

In the meantime I have prepared a few nutshell examples to demonstrate how to 
use scripting
languages with Tomcat for the talk.

In case anyone is interested you can find them here (a rather old Linux 
machine):

  * Tomcat 9 (Java EE): <http://137.208.114.23:42857/demoASF2021/>, Java 8 LTS
  * Tomcat 10 (Jakarta EE): <http://137.208.114.23:42858/demoASF2021/>, Java 11 
LTS

The scripting languages (not sure whether I keep all of them for the talk) 
currently are:

  * ooRexx (implemented in C++ with a Java bridge)
  * JavaScript (Nashorn, JVM)
  * Groovy (JVM)
  * Jython (JVM)
  * PHP/Resin (JVM)

You will be able to see the sources of the JSPs and the code right via the 
supplied JSP-links.

Any remarks/feedback welcome!

---rony

P.S.: Please note, I will be off for a few days starting tomorrow noon such 
that the test server
will not be serviced.


On 20.08.2021 12:13, Rony G. Flatscher (Apache) wrote:
> Hi there,
>
> in a month ApacheCom@Home 2021 [1] starts and has a Tomcat Track [2] in which 
> I will present a talk
> "Apache Tomcat: Enabling Scripting Languages in JSPs" [3]. About getting 
> ready to prepare the slides
> and samples I was wondering whether anyone in the Tomcat community would have 
> questions, ideas,
> suggestions, curiosities etc. and would kindly request for input if you have 
> any.
>
> ---rony
>
> [1] ApacheCon@Home 2021: <https://www.apachecon.com/acah2021/tracks/>
> [2] Tomcat track: <https://www.apachecon.com/acah2021/tracks/tomcat.html>
> [3] Apache Tomcat: Enabling Scripting Languages in JSPs:
> <https://www.apachecon.com/acah2021/tracks/tomcat.html#T1540>

ApacheCon@Home, Tomcat-Track, request for input ...

[Rony G. Flatscher (Apache)]

Hi there,

in a month ApacheCom@Home 2021 [1] starts and has a Tomcat Track [2] in which I 
will present a talk
"Apache Tomcat: Enabling Scripting Languages in JSPs" [3]. About getting ready 
to prepare the slides
and samples I was wondering whether anyone in the Tomcat community would have 
questions, ideas,
suggestions, curiosities etc. and would kindly request for input if you have 
any.

---rony

[1] ApacheCon@Home 2021: 
[2] Tomcat track: 
[3] Apache Tomcat: Enabling Scripting Languages in JSPs:




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

Re: How to access Tomcat session objects directly via JavaScript?

[Rony G. Flatscher (Apache)]

Leo,

On 16.05.2021 03:16, leo wrote:
> Hi Folks
>
> In a small scale personal project served by Tomcat I record things per 
> logged-in user. The user is
> available as an attribute to Tomcat’s session objects. In the JSP pages I 
> retrieve the session
> object *through Java* like this
>
>     <%
>     HttpSession session = request.getSession();
>     ...
>     user = (String)session.getAttribute("user");
>     ...
>     %>
>
> Then later on these pages *in the JavaScript* part I have:
>
>     
>     var user = "<%=user%>"
>     ...
>     
>
> In the JavaScript part I then do something with the *JavaScript* variable 
> `user`.
>
> I now would like to move away from JSP to normal HTML pages (stills served by 
> Tomcat with the
> session backend)
>
> Question: Can I get the content of the session object in pure JavaScript? Can 
> I somehow configure
> Tomcat to put the session info in some page headers or similar so that 
> JavaScript can read it
> directly?

what taglib are you using or is your example purely hypothetical?

---rony



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

Re: Defining environment variables for a webapp ?

[Rony G. Flatscher (Apache)]

Niranjan:

one correction:

On 27.04.2021 15:05, Rony G. Flatscher (Apache) wrote:
> ("heyhey.bat" is executed in a subprocess with a new environment such that 
> its PATH value is
> unchanged!). 

the above statement is wrong, the current environment is inherited with ooRexx' 
ADDRESS instruction
to run commands, sorry, should have double-checked before posting! :(

---rony


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

Re: Defining environment variables for a webapp ?

[Rony G. Flatscher (Apache)]

On 26.04.2021 20:19, Niranjan Rao wrote:
> On 4/14/21 5:29 AM, Rony G. Flatscher (Apache) wrote:
>> A JVM
>> AFAIK would not honor changes to the environment after it got started
>
> A serious question. Apologies for selective selection from the response.
>
> Are there any operating systems where change in environment is automatically 
> reflected in child
> process? My understanding was, processes always inherit parent environment 
> and have no way of
> knowing what changed.
>
> If you managed to spawn a process with different parent based on your 
> operating system, then you
> might see new values, but most of the spawn/exec calls (regardless of 
> language of implmentation)
> inherit the exact same environment variables. Some calls do allow you to 
> setup the environment
> variables for child process but struggling to figure out where grandparent 
> process informed parent
> about environment change which can be sent to grandchild.

Well, it depends what one does, e.g. spawning a new process is different than 
e.g. changing PATH in
the same process and then relying on the new value for PATH to take effect when 
looking for programs
to run/execute.

An example (Windows, ooRexx):

test.rex ... an ooRexx script that uses Rexx to find "subdir\hey.rex" and 
uses Windows to find
"subdir\heyhey.bat", both depend on PATH (which gets changed in the running 
program and takes
effect as can be seen by the output below); failure is shown with frownies, 
success with smileys :)

subdir\hey.rex ... an ooRexx script displaying the invocation information 
(operating system, how
invoked, fully qualified path to this program) and the current dir

subdir\heyhey.bat ... a batch file displaying some environment variable 
('windir')

Here the output of running "test.rex":

G:\test\orx\env>test.rex
1a) testcall():
:-( | not found!
1b) testcallbat():
'heyhey.bat' is not recognized as an internal or external command,
operable program or batch file.
:-( | not found! | RC=1

... about to add 'G:\test\orx\env\subdir' to PATH ...

2a) testcall():
--> hey.rex: parse source s: [WindowsNT SUBROUTINE 
G:\test\orx\env\subdir\hey.rex]
--> hey.rex: directory()   : [G:\test\orx\env]
:-) | ok!
2b) testcallbat():
*** heyhey.bat: just arrived ***
*** heyhey.bat: windir=C:\WINDOWS ***
*** heyhey.bat: about to return ***
:-) | RC=0

As long as PATH does not contain the "subdir" directory neither "hey.rex" nor 
"heyhey.bat" (this
even causes an error message) are found by Rexx or Windows, cf. 1a) and 1b 
(displays the return code
next to the frownie) above. Once the "subdir" directory gets added in the 
running program (in the
same process) and both programs are found by Rexx and Windows as can be seen by 
the output 2a) and
2b) ("heyhey.bat" is executed in a subprocess with a new environment such that 
its PATH value is
unchanged!).

HTH,

---rony

P.S.: For the record the three files:

subdir\hey.rex:

#!/usr/bin/env rexx
parse source s -- get invocation information
say "--> hey.rex:" "parse source s: ["s"]"   -- show invocation 
information
say "--> hey.rex:" "directory()   : ["directory()"]" -- show current 
directory

subdir\heyhey.bat:

@echo off
echo *** heyhey.bat: just arrived ***
echo *** heyhey.bat: windir=%windir% ***
echo *** heyhey.bat: about to return ***

test.rex:

#!/usr/bin/env rexx
say "1a) testcall():"   -- call a Rexx program
say testCall()
say "1b) testcallbat():"
res=testcallbat()   -- invoke a command
say res
say

newDir=directory()"\subdir"
say "... about to add '"newDir"' to PATH ..."
   -- define new value for PATH
newValue=value('PATH', ,"environment")";"newDir
oldValue=value('PATH', newValue, "environment")   -- change PATH value
say

say "2a) testcall():"   -- call a Rexx program
say testCall()
say "2b) testcallbat():"   -- invoke a command
res=testcallbat()   -- invoke a command
say res

::routine testcall   -- call another Rexx program
  signal on syntax   -- if syntax exception then jump to label "syntax:"
  call hey.rex   -- call the Rexx program, PATH gets searched
  return ":-) | ok!"-- everything went fine, return a smiley
syntax:  -- label
  return ":-( | not found!"   -- return frownie

::routine testcallbat -- call a Windows batch file
  address system "heyhey.bat" -- let Window search and execute the command
  if rc=0 then return ":-) | RC="rc -- if return code is 0 return smiley
  return ":-( | not found! | RC="rc   -- return code indicates 
problem, return frownie

Re: ApacheCon @Home 2021 Call for Presentations is open!

[Rony G. Flatscher (Apache)]

Hi Chris,

On 25.04.2021 15:57, Christopher Schultz wrote:
> On 4/24/21 13:23, Rony G. Flatscher (Apache) wrote:
>> Hi there,
>>
>> how about something like:
>>
>>  Apache Tomcat: Enabling Scripting Languages in JSPs
>>
>>  The Java Server Page (JSP) technology allows Java programmers to write 
>> webserver
>> applications by
>>  injecting Java code into HTML or XML pages which then get translated 
>> into Java programs,
>>  compiled and executed each time a client request refers to that JSP. 
>> This presentation
>>  introduces a new taglib which makes it possible to use any Java 
>> scripting language (exploiting
>>  either the Java scripting framework or the Apache Bean Scripting 
>> framework) in JSPs in addition
>>  to or instead of Java thereby serving client requests in the client's 
>> request thread. The
>> taglib
>>  allows among other things to fetch the script code from files and 
>> invoke such programs with the
>>  Servlet's service method arguments (request and response).
>>
>> Would such a presentation be of interest to the audience?
>
> I would definitely submit that to the ApacheCon @Home Call-for-Presentations. 
> Proposals are
> evaluated by a bunch of different people. most presentations I've seen come 
> across in the past
> have been accepted.

thank you for your thumbs up, just filed the proposal.

---rony



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

Re: ApacheCon @Home 2021 Call for Presentations is open!

[Rony G. Flatscher (Apache)]

Hi there,

how about something like:

Apache Tomcat: Enabling Scripting Languages in JSPs

The Java Server Page (JSP) technology allows Java programmers to write 
webserver applications by
injecting Java code into HTML or XML pages which then get translated into 
Java programs,
compiled and executed each time a client request refers to that JSP. This 
presentation
introduces a new taglib which makes it possible to use any Java scripting 
language (exploiting
either the Java scripting framework or the Apache Bean Scripting framework) 
in JSPs in addition
to or instead of Java thereby serving client requests in the client's 
request thread. The taglib
allows among other things to fetch the script code from files and invoke 
such programs with the
Servlet's service method arguments (request and response).

Would such a presentation be of interest to the audience?

---rony


On 01.04.2021 21:13, Christopher Schultz wrote:
> All,
>
> ApacheCon @Home is coming to your city/town/village/hamlet/countryside this 
> September 21 - 23.
>
> Like last year's event, this one will be virtual, so there is no need to book
> travel/accommodations or potentially arrange for time-off from work. You 
> don't even need to wear
> pants if you don't want to.
>
> The Call for Presentations is open NOW. Please submit your Tomcat (or other!) 
> related presentation
> on this site:
>
> https://acah2021.jamhosted.net/
>
> Feel free to browse the Presentations Page[1] on the Tomcat web site for some 
> idea of what
> presentations have been given in the past. Anything related to Tomcat, 
> servlet (etc.) specs, Java
> web application development, etc. would be considered in-scope for the Tomcat 
> track. There are
> many other tracks planned as well.
>
> Yous presentation does /not need to be completed/ when you submit your idea. 
> So if you have an
> idea, go ahead and submit it. You will have a few months to build your idea 
> into a presentation.
>
> If you have any questions, please send a message to the users@ list with 
> "ApacheCon" in the
> subject. Please don't email me individually unless you have a question that 
> cannot be answered by
> anyone but me. My reply would go to the users@ list anyway, so you may as 
> well post the question
> to the list in the first place :)
>
> Thanks,
> -chris
>
> [1] https://tomcat.apache.org/presentations.html
>
>

Re: Making non-Java binareis available to Tomcat, how about ...

[Rony G. Flatscher (Apache)]

Hi Chris,

On 23.04.2021 05:12, Christopher Schultz wrote:
> On 4/21/21 08:53, Rony G. Flatscher (Apache) wrote:
>> Hi Chris,
>>
>> On 20.04.2021 16:47, Christopher Schultz wrote:
>> ... cut ...
>> When bringing non-Java binaries into the picture then they work in the 
>> process environment where
>>>> e.g. PATH defines which directories are looked up for finding executables 
>>>> (which might be
>>>> important
>>>> for some natives) and on Windows DLLs, and in Linux and MacOS shared 
>>>> libraries need to be found by
>>>> the non-Java native code. Hence the desire to allow setting up the process 
>>>> environment before
>>>> starting up Tomcat in a simple, but effective way.
>>>
>>> You may want to do a Google search for "java.library.path".
>>
>> have been aware of (and using) "java.library.path" for quite some time, it 
>> does not do for natives
>> what it does for the JVM. E.g. adding a path via something like
>>
>>     -Djava.library.path="%PATH%;x:\some\path" | 
>> -Djava.library.path="${PATH}:/some/path"
>>
>> does not change the process environment variable PATH accordingly (adding 
>> "x:\some\path" |
>> "/some/path" to the PATH environment variable) such that a native library 
>> can issue a command that
>> will be looked for in addition in "x:\some\path" | "/some/path" (just tested 
>> it again on Windows
>> with Java 8).
>
> Do you mean when you call exec() or similar (yuck!) or do you mean loading 
> dependencies for your
> native library? 
There are scenarios where the former is done in the context of the native 
binaries (not from Java).

> If you have native dependencies for your shared library, you should also put 
> them into the
> java.library.path.
>
> If you are calling exec() or system() or anything like that from your Java 
> code:

No, not from the Java code, but may be a valid scenario from/via the native 
binaries.

> 1. Don't
> 2. Don't use the PATH environment variable; always use full paths

There are scenarios where PATH becomes relevant (again for native binaries, not 
Java).

>>>> However, with CATALINA_OPTS you brought the startup/stop|shutdown/catalina 
>>>> scripts into the
>>>> picture,
>>>> which might be a possible solution (though being very wary 
>>>> altering/tampering such fundamental
>>>> scripts).
>>>
>>> I didn't suggest that you modify those scripts. I only suggested that you 
>>> use an environment
>>> variable that those scripts are aware of.
>>>
>>> Typically, admins will create a bin/setenv.sh script which sets all 
>>> environment variables
>>> necessary for local operation. You could even change the PATH variable -- 
>>> if you really want to do
>>> that -- there.
>>
>> Thank you very much for this pointer, seeing "setenv.{sh|bat}" being 
>> exercised in the Tomcat
>> supplied scripts, if it exists!
>
> That's why it's there.

:)

How about services/daemons?

> You can even set $PATH in there if you really want to.

Yes, indeed, which got me a little bit excited. :)

---rony



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

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

Hi Chris,

On 20.04.2021 16:59, Christopher Schultz wrote:
> On 4/20/21 07:06, Rony G. Flatscher (Apache) wrote:
>> On 19.04.2021 17:32, Christopher Schultz wrote:
>>> On 4/18/21 08:06, Rony G. Flatscher (Apache) wrote:
>>>> On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote:
>>>>> On 11.03.2021 11:53, Mark Thomas wrote:
>>>>>> On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:
>>>>>>> Is there a way to know/infer that a JSP got freshly compiled from e.g. 
>>>>>>> a taglib library?
>>>>>>>
>>>>>>> For caching purposes it would be necessary to learn whether a JSP got 
>>>>>>> recompiled as the cache
>>>>>>> should
>>>>>>> be purged in that case.
>>>>>>>
>>>>>>> Is there a way to find out whether a JSP run is the very first after 
>>>>>>> (re-)compilation?
>>>>>>>
>>>>>>> Or can one rely that if a JSP gets recompiled that a new PageContext 
>>>>>>> gets created for it (or if
>>>>>>> reused does not contain any custom attributes placed there earlier at 
>>>>>>> the PAGE_SCOPE)?
>>>>>> Page scope gets reset at the end of a request so that won't work.
>>>>>>
>>>>>> It might not be perfect (containers are allowed to unload unused 
>>>>>> servlets/JSPs) but in you are
>>>>>> using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then 
>>>>>> you should be able
>>>>>> to use
>>>>>> the jspInit() method. (See JSP spec for details).
>>>>
>>>> It seems that the implicit JSP "page" object can probably be used to 
>>>> determine whether a JSP got
>>>> recompiled as its hashCode() changes after recompilation.
>>>
>>> Something safer might be to keep a cache of datestamps keyed by JSP name 
>>> (or whatever). When the
>>> JSP's init() method is called, you could update the datestamp.
>>>
>>> Or do you need to know about the recompliation before the init() is called?
>>
>> The BodyTag interface [1,2] does not define an init() method, you think 
>> probably of the Servlet
>> interface [3,4].
>
> Aha, it wasn't clear to me that you needed to know at the taglib level that a 
> JSP had been
> recompiled.
>
>> Ad 'page' implicit object: if the 'page' object gets referenced in the 
>> taglib, then a re-compiled
>> version of the same JSP page is guaranteed to have a different hashCode() 
>> value
>
> Really? That seems ... awfully convenient and also quite hacky. Do you have a 
> reference to the
> spec that guarantees that modified hashcode?

Sorry, it is not "guaranteed" (there are no such specs), it should have 
probably read "guaranteed
for all practical usages". (When the caching of inline scripts gets implemented 
it may use the
page's className or the className@hashCode format as a string index into a 
HashMap and then check
whether the object exists and if so, is equal to the current 'page' object and 
act accordingly.)

>> and as such suffices
>> to determine whether a page got compiled since the last time this got 
>> checked in the taglib. The
>> motivation for learning about a (re-)fresh(ed) page is to remove any cached 
>> compiled scripts of that
>> jsp (if it got recompiled then something got changed in the jsp, so also 
>> scripts might have changed)
>> and from then on build a new cache.
>
> Yeah, I don't see a great way to do that. You can get the ServletContext from 
> the PageContext, but
> ... you would still need a lot of support in there to get what you want.

Currently the externally stored scripts get cached in a static HashMap, the 
page-related script
manager and its script engines get cached and controlled via PageContext 
attributes and ThreadLocal.

> What about cheating and just putting a Tag at the top-level where you have to 
> declare the
> "version" of the script, and changing the "version" causes the cache to be 
> cleared?

Ideally the user should not have to do that (to forgo user errors).

---rony



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

Re: Making non-Java binareis available to Tomcat, how about ...

[Rony G. Flatscher (Apache)]

Hi Chris,

On 20.04.2021 16:47, Christopher Schultz wrote:
... cut ...
When bringing non-Java binaries into the picture then they work in the process 
environment where
>> e.g. PATH defines which directories are looked up for finding executables 
>> (which might be important
>> for some natives) and on Windows DLLs, and in Linux and MacOS shared 
>> libraries need to be found by
>> the non-Java native code. Hence the desire to allow setting up the process 
>> environment before
>> starting up Tomcat in a simple, but effective way.
>
> You may want to do a Google search for "java.library.path".

have been aware of (and using) "java.library.path" for quite some time, it does 
not do for natives
what it does for the JVM. E.g. adding a path via something like

   -Djava.library.path="%PATH%;x:\some\path" | 
-Djava.library.path="${PATH}:/some/path"

does not change the process environment variable PATH accordingly (adding 
"x:\some\path" |
"/some/path" to the PATH environment variable) such that a native library can 
issue a command that
will be looked for in addition in "x:\some\path" | "/some/path" (just tested it 
again on Windows
with Java 8).

>> However, with CATALINA_OPTS you brought the startup/stop|shutdown/catalina 
>> scripts into the picture,
>> which might be a possible solution (though being very wary 
>> altering/tampering such fundamental
>> scripts).
>
> I didn't suggest that you modify those scripts. I only suggested that you use 
> an environment
> variable that those scripts are aware of.
>
> Typically, admins will create a bin/setenv.sh script which sets all 
> environment variables
> necessary for local operation. You could even change the PATH variable -- if 
> you really want to do
> that -- there.

Thank you very much for this pointer, seeing "setenv.{sh|bat}" being excercised 
in the Tomcat
supplied scripts, if it exists!

---rony



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

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

Hi Chris,

On 19.04.2021 17:32, Christopher Schultz wrote:
>
> On 4/18/21 08:06, Rony G. Flatscher (Apache) wrote:
>> On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote:
>>> On 11.03.2021 11:53, Mark Thomas wrote:
>>>> On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:
>>>>> Is there a way to know/infer that a JSP got freshly compiled from e.g. a 
>>>>> taglib library?
>>>>>
>>>>> For caching purposes it would be necessary to learn whether a JSP got 
>>>>> recompiled as the cache
>>>>> should
>>>>> be purged in that case.
>>>>>
>>>>> Is there a way to find out whether a JSP run is the very first after 
>>>>> (re-)compilation?
>>>>>
>>>>> Or can one rely that if a JSP gets recompiled that a new PageContext gets 
>>>>> created for it (or if
>>>>> reused does not contain any custom attributes placed there earlier at the 
>>>>> PAGE_SCOPE)?
>>>> Page scope gets reset at the end of a request so that won't work.
>>>>
>>>> It might not be perfect (containers are allowed to unload unused 
>>>> servlets/JSPs) but in you are
>>>> using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then 
>>>> you should be able to use
>>>> the jspInit() method. (See JSP spec for details).
>>
>> It seems that the implicit JSP "page" object can probably be used to 
>> determine whether a JSP got
>> recompiled as its hashCode() changes after recompilation.
>
> Something safer might be to keep a cache of datestamps keyed by JSP name (or 
> whatever). When the
> JSP's init() method is called, you could update the datestamp.
>
> Or do you need to know about the recompliation before the init() is called?

The BodyTag interface [1,2] does not define an init() method, you think 
probably of the Servlet
interface [3,4].

Ad 'page' implicit object: if the 'page' object gets referenced in the taglib, 
then a re-compiled
version of the same JSP page is guaranteed to have a different hashCode() value 
and as such suffices
to determine whether a page got compiled since the last time this got checked 
in the taglib. The
motivation for learning about a (re-)fresh(ed) page is to remove any cached 
compiled scripts of that
jsp (if it got recompiled then something got changed in the jsp, so also 
scripts might have changed)
and from then on build a new cache.

---rony

[1] javax-BodyTag with lifecycle description:
<https://docs.oracle.com/javaee/7/api/javax/servlet/jsp/tagext/BodyTag.html>
[2] jakarta-BodyTag:
<http://tomee.apache.org/jakartaee-9.0/javadoc/jakarta/servlet/jsp/tagext/BodyTag.html#doInitBody-->
[3] jakarta-Servlet:
<https://javadoc.io/static/jakarta.servlet/jakarta.servlet-api/5.0.0/jakarta/servlet/Servlet.html>
[4] Wikipedia "Jakarta Servlet": <https://en.wikipedia.org/wiki/Jakarta_Servlet>



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

Re: Making non-Java binareis available to Tomcat, how about ...

[Rony G. Flatscher (Apache)]

Hi Chris,

CATALINA_OPTS is about passing on Java options and System property definitions, 
if not mistaken.
When bringing non-Java binaries into the picture then they work in the process 
environment where
e.g. PATH defines which directories are looked up for finding executables 
(which might be important
for some natives) and on Windows DLLs, and in Linux and MacOS shared libraries 
need to be found by
the non-Java native code. Hence the desire to allow setting up the process 
environment before
starting up Tomcat in a simple, but effective way.

However, with CATALINA_OPTS you brought the startup/stop|shutdown/catalina 
scripts into the picture,
which might be a possible solution (though being very wary altering/tampering 
such fundamental scripts).

---rony


On 19.04.2021 17:37, Christopher Schultz wrote:

> Rony,
>
> On 4/19/21 08:54, Rony G. Flatscher (Apache) wrote:
>> Java based web servers are - of course - focused on the Java programming 
>> language and the Java
>> runtime environment.
>>
>> Nevertheless, there are situations where non-Java binaries may become 
>> resources that may prove
>> helpful in a Java environment.
>>
>> As Java allows interfacing with non-Java binaries via JNI (Java native 
>> interface) it may make sense
>> to support native binaries in Tomcat as well.
>>
>> Use case in question would be to make non-Java programming languages with 
>> JNI interfaces available
>> without having to install such programming languages globally on the server. 
>>  There may be other use
>> cases as well (e.g. non-public security libraries).
>>
>> In order to make this as simple as possible and yet allow for the Tomcat 
>> setup to be as secure as
>> setting up shared Java libraries, how about allowing for the following:
>>
>>    * allow optional "$CATALINA_HOME/natives/bin" and 
>> "$CATALINA_HOME/natives/lib" directories into
>>  which the (Tomcat shared) binaries can be placed,
>
> Is there anything wrong with using CATALINA_OPTS to set java.library.path to 
> some arbitrary value?
> I always have mine set to CATALINA_BASE/lib
>
>>    * if "$CATALINA_HOME/natives/bin" exists have the PATH environment 
>> variable prepended with
>>  "$CATALINA_HOME/natives/bin" before Tomcat gets started up,
>
> Note that java.library.path (a system property) would be better than changing 
> the PATH environment
> variable.
>
>>    * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux 
>> and MacOS systems for
>> the
>>  process to become able to recognize the shared native libraries there,
>
> Nothing further is needed after java.library.path is set.
>
>>    * if there are jar files (possibly with JNI interfaces) in 
>> "$CATALINA_HOME/natives/lib" then add
>>  them to Tomcat (like the jar files in "$CATALINA_HOME/lib").
>
> If you use CATALINA_BASE/lib, then this is already done for you.
>
> -chris
>


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

Making non-Java binareis available to Tomcat, how about ...

[Rony G. Flatscher (Apache)]

Java based web servers are - of course - focused on the Java programming 
language and the Java
runtime environment.

Nevertheless, there are situations where non-Java binaries may become resources 
that may prove
helpful in a Java environment.

As Java allows interfacing with non-Java binaries via JNI (Java native 
interface) it may make sense
to support native binaries in Tomcat as well.

Use case in question would be to make non-Java programming languages with JNI 
interfaces available
without having to install such programming languages globally on the server.  
There may be other use
cases as well (e.g. non-public security libraries).

In order to make this as simple as possible and yet allow for the Tomcat setup 
to be as secure as
setting up shared Java libraries, how about allowing for the following:

  * allow optional "$CATALINA_HOME/natives/bin" and 
"$CATALINA_HOME/natives/lib" directories into
which the (Tomcat shared) binaries can be placed,
  * if "$CATALINA_HOME/natives/bin" exists have the PATH environment variable 
prepended with
"$CATALINA_HOME/natives/bin" before Tomcat gets started up,
  * if "$CATALINA_HOME/natives/lib" exists do whatever is needed for Linux and 
MacOS systems for the
process to become able to recognize the shared native libraries there,
  * if there are jar files (possibly with JNI interfaces) in 
"$CATALINA_HOME/natives/lib" then add
them to Tomcat (like the jar files in "$CATALINA_HOME/lib").

Would such an idea be seen as acceptable, helpful?

---rony

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote:
> On 11.03.2021 11:53, Mark Thomas wrote:
>> On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:
>>> Is there a way to know/infer that a JSP got freshly compiled from e.g. a 
>>> taglib library?
>>>
>>> For caching purposes it would be necessary to learn whether a JSP got 
>>> recompiled as the cache should
>>> be purged in that case.
>>>
>>> Is there a way to find out whether a JSP run is the very first after 
>>> (re-)compilation?
>>>
>>> Or can one rely that if a JSP gets recompiled that a new PageContext gets 
>>> created for it (or if
>>> reused does not contain any custom attributes placed there earlier at the 
>>> PAGE_SCOPE)?
>> Page scope gets reset at the end of a request so that won't work.
>>
>> It might not be perfect (containers are allowed to unload unused 
>> servlets/JSPs) but in you are
>> using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then you 
>> should be able to use
>> the jspInit() method. (See JSP spec for details).

It seems that the implicit JSP "page" object can probably be used to determine 
whether a JSP got
recompiled as its hashCode() changes after recompilation.

---rony



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

Re: Defining environment variables for a webapp ?

[Rony G. Flatscher (Apache)]

Martynas,

On 14.04.2021 14:20, Martynas Jusevičius wrote:
> you might want to look into containerizing your webapps. We use an
> XSLT stylesheet (invoked by the entrypoint script) that transforms env
> params into context.xml params:
> https://github.com/AtomGraph/LinkedDataHub/blob/master/platform/context.xsl

Thank you very much!

If I understood Mark correctly, the environment variable values need to be set 
in the Tomcat process
before Tomcat starts.

The aim would be to change the environment for the webapps, i.e. in a running 
Tomcat instance. A JVM
AFAIK would not honor changes to the environment after it got started, but 
thought it possible that
through some magic :) by the Tomcat developers this could be achieved for 
webapps. The CGI solution
works with a new environment as a new (relative expensive) process gets created 
through Java for
which all these aspects could be set.

---rony

> On Wed, Apr 14, 2021 at 2:16 PM Rony G. Flatscher (Apache)
>  wrote:
>> On 14.04.2021 13:25, Mark Thomas wrote:
>>> On 14/04/2021 12:22, Rony G. Flatscher (Apache) wrote:
>>>> Not finding any pointers, asking here: is it possible to define 
>>>> environment variables for a webapp?
>>>> If so, how?
>>> You can only set them globally, for the Java process - not per web 
>>> application.
>>>
>>> CGI creates a new process so can have a completely different set of 
>>> environment variables.
>>>
>>> How about using the per web application JNDI context?
>> Well the idea was to adjust PATH to have it point to a webapp based 
>> directory containing the
>> binaries. :)
>>
>> ---rony
>>
>> P.S.: The aim would be to make it simple and easy for deploying webapps that 
>> also need to have
>> access to non-Java binaries (executables and/or shared libraries).
>>
>>
>>


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

Re: Defining environment variables for a webapp ?

[Rony G. Flatscher (Apache)]

On 14.04.2021 13:25, Mark Thomas wrote:
> On 14/04/2021 12:22, Rony G. Flatscher (Apache) wrote:
>> Not finding any pointers, asking here: is it possible to define environment 
>> variables for a webapp?
>> If so, how?
>
> You can only set them globally, for the Java process - not per web 
> application.
>
> CGI creates a new process so can have a completely different set of 
> environment variables.
>
> How about using the per web application JNDI context?

Well the idea was to adjust PATH to have it point to a webapp based directory 
containing the
binaries. :)

---rony

P.S.: The aim would be to make it simple and easy for deploying webapps that 
also need to have
access to non-Java binaries (executables and/or shared libraries).



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

Defining environment variables for a webapp ?

[Rony G. Flatscher (Apache)]

Not finding any pointers, asking here: is it possible to define environment 
variables for a webapp?
If so, how?

---rony

P.S.: Tomcat can manipulate the process' environment, e.g. in the case of CGI 
execution. Here a
sample of the process' environment from some CGI-invocation on a Windows 
machine:

(debug) current cgi process environment:||

 1. |AUTH_TYPE=
 2. COMSPEC=C:\WINDOWS\SysWOW64\CMD.EXE
 3. CONTENT_LENGTH=7
 4. CONTENT_TYPE=application/x-www-form-urlencoded
 5. GATEWAY_INTERFACE=CGI/1.1
 6. 
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 7. HTTP_ACCEPT_ENCODING=gzip, deflate
 8. HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.5
 9. HTTP_COOKIE=JSESSIONID=2137ECEC8CC5EE35AEFA475E5C5D8250
10. HTTP_HOST=localhost:8080
11. 
HTTP_REFERER=http://localhost:8080/demoSTL-Core-SQL_ooRexx/JSTL_CGI_05-GroupWorkDivider.jsp
12. HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) 
Gecko/20100101 Firefox/87.0
13. PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC
14. PATH_INFO=
15. PROMPT=$P$G
16. 
QUERY_STRING=name=Andreas+Burgstaller=Max+Mustermann=Nadine+Berger=Klaus+Karter=Simon+Hauser=Michael+Nimmervoll
17. REMOTE_ADDR=127.0.0.1
18. REMOTE_HOST=127.0.0.1
19. REMOTE_IDENT=
20. REMOTE_USER=
21. REQUEST_METHOD=POST
22. REQUEST_URI=/demoSTL-Core-SQL_ooRexx/cgi-bin/groupStudents.rexx
23. RXQUEUESESSION=3B1C
24. SCRIPT_FILENAME=D:\Apache Software Foundation\Tomcat
9.0\webapps\demoSTL-Core-SQL_ooRexx\WEB-INF\cgi\groupStudents.rexx
25. SCRIPT_NAME=/demoSTL-Core-SQL_ooRexx/cgi-bin/groupStudents.rexx
26. SERVER_NAME=localhost
27. SERVER_PORT=8080
28. SERVER_PROTOCOL=HTTP/1.1
29. SERVER_SOFTWARE=TOMCAT
30. SystemRoot=C:\WINDOWS
31. X_TOMCAT_SCRIPT_PATH=D:\Apache Software Foundation\Tomcat
9.0\webapps\demoSTL-Core-SQL_ooRexx\WEB-INF\cgi\groupStudents.rexx
| 

Re: Question ad distributing non-Java-binaries with a webapp ...

[Rony G. Flatscher (Apache)]

Hi Konstantin,

thank you *very* much for your extremely helpful information, which gives me 
quite something to
digest and think about!

Your remark about the JVM and loading a native library through one classloader 
only makes me think
that it would not be possible at the moment to have two or more webapps with 
binary resources (that
may even be at different version levels over time). Although I would not pursue 
this therefore at
the moment, I still will put your valuable information on the table of 
"interesting things to
explore" and may come back later.

The motivation behind such thoughts is to exploit Tomcat as much as possible as 
it has turned out to
be really *great* boon for empowering business administration students to get 
to create web
applications with Tomcat in surprisingly short time (and if BA students can get 
empowered to exploit
Tomcat within a short time, then professionals can get empowered in a fraction 
of that time, even if
they do not speak Java). [In the context of this question the idea was to 
supply the ooRexx
interpreter together with the webapp, such that the webapp contains everything 
needed to run it.
OTOH the students have the interpreter already installed together with its Java 
bridge and as such
can become productive with Tomcat, right after having Tomcat installed on their 
machines (Windows,
Apple and Linux).]

Again, thank you very much!

---rony


On 11.04.2021 15:19, Konstantin Kolinko wrote:
> сб, 10 апр. 2021 г. в 21:50, Rony G. Flatscher (Apache) :
>> Is it possible to place and use binaries (including shared libraries) in a 
>> webapp? Very much like
>> supplying jars to the "lib"-directory?
>>
>> Use case: if possible, I would like to create a webapp that includes 
>> non-Java binaries (executable,
>> image and shared libraries) that get interfaced with via JNI.
>>
>> If this is possible then how so? Any pointers/hints would be highly 
>> appreciated!
> Hi, Rony!
>
> 1) You may look for an inspiration on how Tomcat Navive library is loaded
> https://tomcat.apache.org/tomcat-9.0-doc/apr.html
> https://tomcat.apache.org/native-doc/
>
> Note that "64-bit Windows zip" binary distribution includes the
> library (tcnative-1.dll).
> https://tomcat.apache.org/download-90.cgi
>
> In the source code, look at
> org.apache.tomcat.jni.Library
> org.apache.catalina.core.AprLifecycleListener
> and its message resources,
> java/org/apache/catalina/core/LocalStrings.properties
>
> You may find examples of System.load(), System.loadLibrary(),
> System.mapLibraryName() calls in the Library class.
>
> See also the system property "java.library.path".
>
>
> 2) JVM has a limitation that a library is allowed to be loaded by one
> classloader only.
>
> That is why using a web application classloader looks to be a poor
> place for loading a library, if you are ever going to use its full
> features (parallel deployment of several web applications, a reload /
> redeploy without stopping Tomcat, etc.) See
> https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html
>
> 3) It is possible to load any classes when Apache Tomcat starts:
>
> a) with a custom Listener,
>
> b) abusing a JreMemoryLeakPreventionListener
> https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html
>
> c) as a custom resource
> https://tomcat.apache.org/tomcat-9.0-doc/jndi-resources-howto.html#Generic_JavaBean_Resources
>
> HTH.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Question ad distributing non-Java-binaries with a webapp ...

[Rony G. Flatscher (Apache)]

Is it possible to place and use binaries (including shared libraries) in a 
webapp? Very much like
supplying jars to the "lib"-directory?

Use case: if possible, I would like to create a webapp that includes non-Java 
binaries (executable,
image and shared libraries) that get interfaced with via JNI.

If this is possible then how so? Any pointers/hints would be highly appreciated!

---rony



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

Re: Possible to refer to the contextPath in a Resource database url ?

[Rony G. Flatscher (Apache)]

On 11.03.2021 12:14, Mark Thomas wrote:
> On 10/03/2021 19:44, Rony G. Flatscher (Apache) wrote:
>> For a little nutshell example I would like to use SQLite as the JDBC driver 
>> includes the native code
>> for all the major operating systems already (this way a user does not really 
>> need to install SQLite
>> just place its JDBC driver in the lib directory).
>>
>> The SQLite database (with sample data) should reside in the webapp itself, 
>> maybe in a subdirectory
>> named "data". Is it possible to define a "Resource" of type 
>> "javax.sql.DataSource" and use some
>> variable that would resolve the contextPath and that can be used in the 
>> "url" attribute? (The
>> Resource definition should be contained placed in the webapps' 
>> "META-INF/context.xml" Content
>> element.)
>>
>> There are samples that show how to use "${catalina.home}" as part of such a 
>> path. Is there a
>> variable that represents the contextPath of the webapp such that one can use 
>> that in the "url"
>> attribute?
>
> Not currently, no. It would be a little tricky to implement given how ${...} 
> replacement currently
> works.

O.K., thank you very much!

---rony


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

Re: Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

On 11.03.2021 11:53, Mark Thomas wrote:
> On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote:
>> Is there a way to know/infer that a JSP got freshly compiled from e.g. a 
>> taglib library?
>>
>> For caching purposes it would be necessary to learn whether a JSP got 
>> recompiled as the cache should
>> be purged in that case.
>>
>> Is there a way to find out whether a JSP run is the very first after 
>> (re-)compilation?
>>
>> Or can one rely that if a JSP gets recompiled that a new PageContext gets 
>> created for it (or if
>> reused does not contain any custom attributes placed there earlier at the 
>> PAGE_SCOPE)?
>
> Page scope gets reset at the end of a request so that won't work.
>
> It might not be perfect (containers are allowed to unload unused 
> servlets/JSPs) but in you are
> using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then you 
> should be able to use
> the jspInit() method. (See JSP spec for details).

Thank you very much!

---rony


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

Possible to refer to the contextPath in a Resource database url ?

[Rony G. Flatscher (Apache)]

For a little nutshell example I would like to use SQLite as the JDBC driver 
includes the native code
for all the major operating systems already (this way a user does not really 
need to install SQLite
just place its JDBC driver in the lib directory).

The SQLite database (with sample data) should reside in the webapp itself, 
maybe in a subdirectory
named "data". Is it possible to define a "Resource" of type 
"javax.sql.DataSource" and use some
variable that would resolve the contextPath and that can be used in the "url" 
attribute? (The
Resource definition should be contained placed in the webapps' 
"META-INF/context.xml" Content element.)

There are samples that show how to use "${catalina.home}" as part of such a 
path. Is there a
variable that represents the contextPath of the webapp such that one can use 
that in the "url"
attribute?

---rony





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

Is there a way to know/infer that a JSP got freshly compiled from a taglib library ?

[Rony G. Flatscher (Apache)]

Is there a way to know/infer that a JSP got freshly compiled from e.g. a taglib 
library?

For caching purposes it would be necessary to learn whether a JSP got 
recompiled as the cache should
be purged in that case.

Is there a way to find out whether a JSP run is the very first after 
(re-)compilation?

Or can one rely that if a JSP gets recompiled that a new PageContext gets 
created for it (or if
reused does not contain any custom attributes placed there earlier at the 
PAGE_SCOPE)?

---rony

P.S.: Currently the pageContext gets used already for storing an attribute with 
PAGE_SCOPE.



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

Re: JSP: question: how to make tld-files part of the taglib library like STL is able to do?

[Rony G. Flatscher (Apache)]

On 10.03.2021 14:44, Mark Thomas wrote:
> On 10/03/2021 13:19, Rony G. Flatscher (Apache) wrote:
>> The STL (standard tag library) jstl-1.2_1.jar is able to have its tags 
>> processed without requiring
>> the user to place its tld-files into the webapps WEB-INF directory. Rather 
>> jstl-1.2_1.jar stores the
>> tld files in its META-INF directory and yet they seem to be found by the JSP 
>> processor (not sure
>> whether this is the correct term).
>>
>> How can this be achieved for any taglib? What needs to be done to allow 
>> including the tld-files
>> within the taglib library such as to become able to remove the need to place 
>> the taglib library's
>> tld files into the webapps WEB-INF directory?
>
> 
> When deployed inside a JAR file, the tag library descriptor files must be in 
> the META-INF
> directory, or a subdirectory of it.
> 
>
> You also need to make sure that Tomcat isn't configured to skip your JAR file 
> when scanning for
> tag libraries (see CATALINA_BASE/conf/catalina.properties).

Thank you very much!

It turns out that I forgot to adjust the uri value in the JSP files to match 
the uri defined in the
tld files! :(

The reason why I thought that something was wrong with the jar file and the tld 
locations within
(despite having them in META-INF) was the following entry in the log file:

... cut ...
10-Mar-2021 15:13:14.264 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory
Deploying web application directory [D:\Apache Software Foundation\Tomcat 
9.0\*webapps\aa_rgf_test*]
10-Mar-2021 15:13:16.362 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars /At least one
JAR was scanned for TLDs yet contained no TLDs/. Enable debug logging for 
this logger for a
complete list of JARs that were scanned but no TLDs were found in them. 
Skipping unneeded JARs
during scanning can improve startup time and JSP compilation time.
10-Mar-2021 15:13:16.362 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory
Deployment of web application directory [D:\Apache Software 
Foundation\Tomcat
9.0\webapps\aa_rgf_test] has finished in [2,098] ms
... cut ...

So actually the log message means what it states: there was at least one jar 
that did not contain a
TLD file (I read it: no TLD files were found in the scanned jars)! :)

Very sorry for the noise, typical user error. :(

Yet, now it is possible to forgo the current need to copy the tld files to the 
WEB-INF directory,
which is really great!

---rony

JSP: question: how to make tld-files part of the taglib library like STL is able to do?

[Rony G. Flatscher (Apache)]

The STL (standard tag library) jstl-1.2_1.jar is able to have its tags 
processed without requiring
the user to place its tld-files into the webapps WEB-INF directory. Rather 
jstl-1.2_1.jar stores the
tld files in its META-INF directory and yet they seem to be found by the JSP 
processor (not sure
whether this is the correct term).

How can this be achieved for any taglib? What needs to be done to allow 
including the tld-files
within the taglib library such as to become able to remove the need to place 
the taglib library's
tld files into the webapps WEB-INF directory?

---rony



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

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Hi Chris,

On 03.03.2021 22:33, Christopher Schultz wrote:
> Rony,
>
> On 3/3/21 06:42, Rony G. Flatscher (Apache) wrote:
>> Hi Chris,
>>
>> On 02.03.2021 17:48, Christopher Schultz wrote:
>>> Rony,
>>>
>>> On 2/28/21 11:33, Rony G. Flatscher (Apache) wrote:
>>>> Leo,
>>>>
>>>> On 26.02.2021 01:52, leo wrote:
>>>>> On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote:
>>>>>
>>>>>> P.S.: Have tested my implementation with Nashorn on Java 8 and it works 
>>>>>> out of the box!
>>>>>> Still, you
>>>>>> would need to test the implementation thoroughly yourself (stability, 
>>>>>> performance, resources)
>>>>>> and
>>>>>> would be asked to come back with feedback on each of these qualities. So 
>>>>>> stay tuned, will
>>>>>> publish a
>>>>>> link to the implementation with a proper Nashorn/JavaScript sample war 
>>>>>> in this mail thread in a
>>>>>> few
>>>>>> days.
>>>>>
>>>>> How cool is this! Let me know when you it ready, please. Thanks a lot!
>>>>
>>>> O.K., had a few things I could finalize. Created two war files, 
>>>> "demoJavaScript.war" and
>>>> "demoRhino.war". The first got tested against Nashorn, the second - you 
>>>> guessed it ;) - against
>>>> Rhino (7.1.13). They are meant as little proof-of-concepts that should 
>>>> help you to get up and
>>>> running with them.
>>>>
>>>> Please note that the libraries are beta, though appear to be stable. Yet, 
>>>> there may be
>>>> errors/problems in them or there may be changes coming up.
>>>>
>>>> If you have feedback of any sorts, please come forward (stability, 
>>>> usability, performance,
>>>> resources, etc.).
>>>>
>>>> Basically you just need to go to [1] and get the two war-files (copy to 
>>>> $CATALINA_HOME/webapps)
>>>> plus
>>>> either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or 
>>>> jakarta.ScriptTagLibs.jar (for Tomcat
>>>> 10) which you should copy to the shared directory at $CATALINA_HOME/lib 
>>>> and restart Tomcat to get
>>>> them recognized. If you want to test with Rhino you should follow the 
>>>> directions at [1] and
>>>> copy the
>>>> mentioned two rhino jar files to the shared library directory as well.
>>>>
>>>> In general you should take the time and look over that page at [1], I 
>>>> tried to remain as brief as
>>>> possible. :)
>>>>
>>>> Also please do not forget that the target audience of [1] has been so far 
>>>> the Rexx community
>>>> and my
>>>> BA students who learned programming using ooRexx in a semester and with 
>>>> that knowledge should now
>>>> become able to create little web sites for their own purposes and maybe 
>>>> with some experience for
>>>> small businesses/organizations given the information at [1] as a starting 
>>>> point.
>>>>
>>>> Of course, if there are any questions please do not hesitate and please 
>>>> ask them!
>>>
>>> Any source available?
>>
>> Sure, sorry forgot to point that out explicitly!
>>
>> You can get at it either in the ScriptTagLibs jar files from [1] (yes, in 
>> this case I have the
>> source and also the tld files in the jar for completeness as well) or from 
>> [2] with the appropriate
>> checkout strings given in the upper half.
>>
>> Also, the license is AL 2.0, of course (dual licensed with the CPL 1.0 
>> license in addition which the
>> ooRexx project uses).
>>
>> Please note: currently the state is beta, it is functional and appears to be 
>> stable.
>
> This is a pretty awesome effort. 
Thank you!
> Since you work at a university, perhaps some of your students would be 
> interested in working on
> the library itself and not just in being an end-user. Maybe CS students at 
> the same uni though not
> in your program. They could probably get credit for working on it, too.

Currently there are only BA students available, some of them with an interest 
in CS and rarely some
that have already good programming skills in Java when coming to my "business 
programming" classes.
That situation h

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Hi Leo,

On 03.03.2021 00:40, leo wrote:
> Rony,
>
>> O.K., had a few things I could finalize. Created two war files, 
>> "demoJavaScript.war" and
>> "demoRhino.war". The first got tested against Nashorn, the second - you 
>> guessed it ;) - against
>> Rhino (7.1.13). They are meant as little proof-of-concepts that should help 
>> you to get up and
>> running with them.
>> […]
>
> Thank you very much. Will check it out!

Fine, please be so kind and give feedback of any sorts you have!

---rony


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

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Hi Chris,

On 02.03.2021 17:48, Christopher Schultz wrote:
> Rony,
>
> On 2/28/21 11:33, Rony G. Flatscher (Apache) wrote:
>> Leo,
>>
>> On 26.02.2021 01:52, leo wrote:
>>> On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote:
>>>
>>>> P.S.: Have tested my implementation with Nashorn on Java 8 and it works 
>>>> out of the box! Still, you
>>>> would need to test the implementation thoroughly yourself (stability, 
>>>> performance, resources) and
>>>> would be asked to come back with feedback on each of these qualities. So 
>>>> stay tuned, will
>>>> publish a
>>>> link to the implementation with a proper Nashorn/JavaScript sample war in 
>>>> this mail thread in a
>>>> few
>>>> days.
>>>
>>> How cool is this! Let me know when you it ready, please. Thanks a lot!
>>
>> O.K., had a few things I could finalize. Created two war files, 
>> "demoJavaScript.war" and
>> "demoRhino.war". The first got tested against Nashorn, the second - you 
>> guessed it ;) - against
>> Rhino (7.1.13). They are meant as little proof-of-concepts that should help 
>> you to get up and
>> running with them.
>>
>> Please note that the libraries are beta, though appear to be stable. Yet, 
>> there may be
>> errors/problems in them or there may be changes coming up.
>>
>> If you have feedback of any sorts, please come forward (stability, 
>> usability, performance,
>> resources, etc.).
>>
>> Basically you just need to go to [1] and get the two war-files (copy to 
>> $CATALINA_HOME/webapps) plus
>> either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or 
>> jakarta.ScriptTagLibs.jar (for Tomcat
>> 10) which you should copy to the shared directory at $CATALINA_HOME/lib and 
>> restart Tomcat to get
>> them recognized. If you want to test with Rhino you should follow the 
>> directions at [1] and copy the
>> mentioned two rhino jar files to the shared library directory as well.
>>
>> In general you should take the time and look over that page at [1], I tried 
>> to remain as brief as
>> possible. :)
>>
>> Also please do not forget that the target audience of [1] has been so far 
>> the Rexx community and my
>> BA students who learned programming using ooRexx in a semester and with that 
>> knowledge should now
>> become able to create little web sites for their own purposes and maybe with 
>> some experience for
>> small businesses/organizations given the information at [1] as a starting 
>> point.
>>
>> Of course, if there are any questions please do not hesitate and please ask 
>> them!
>
> Any source available?

Sure, sorry forgot to point that out explicitly!

You can get at it either in the ScriptTagLibs jar files from [1] (yes, in this 
case I have the
source and also the tld files in the jar for completeness as well) or from [2] 
with the appropriate
checkout strings given in the upper half.

Also, the license is AL 2.0, of course (dual licensed with the CPL 1.0 license 
in addition which the
ooRexx project uses).

Please note: currently the state is beta, it is functional and appears to be 
stable.

A request: if you see something questionable, improvable or missing, please be 
so kind and let me know!

There is certainly room for improvements, especially through the eyes of an 
Tomcat/Servlet expert
like yourself! :) E.g., it would be nice to put the tld files into the jar and 
allow the JSPs to
refer to them without the need to copy them to WEB-INF as is possible with the 
STL ; if I knew how
to do that, I would do it as it improves usability (ran out of time to research 
that specific feature).

---rony

[1] Beta directory for the ScriptTagLibs and demo war files for ooRexx, 
Nashorn, Rhino, source
included in the jar files:
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/beta/>.
Please note: "demoRexx.war" demonstrates all attributes and in addition has two 
utility samples, one
injecting the implicit JSP objects and the current values of the getter 
methods, which might be
helpful when developing or debugging a webapp.

[2] dev directory for the ScriptTagLibs:
<https://sourceforge.net/p/bsf4oorexx/code/HEAD/tree/sandbox/rgf/taglibs/>
Please note: the dev subdirectories have Windows cmd-files for creating the jar 
files, if you create
Unix versions of them, please share (just did not have the time to create the 
appropriate shell
scripts, an item on the todo list)! :) In essence the bsf and jsr223 are 
identical except for the
compile attribute which is only available for the JSR-223.




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

Re: Tomcat Security Office Hours

[Rony G. Flatscher (Apache)]

On 24.02.2021 12:59, Mark Thomas wrote:
> All,
>
> Inspired by this post [1] I am going to try an experiment with running
> weekly office hours every Thursday.
>
> I'm going to start off by focussing on security. If there is anything
> you'd like to discuss and/or provide feedback on and/or ask questions
> about around Tomcat security then feel free to book a 20 min slot via:
>
> https://calendly.com/markt-asf
>
> Slots are available every Thursday. Booking a meeting should trigger a
> Zoom invite for the requested slot.
>
> This is an experiment so the number of slots, timing of slots etc are
> subject to change as the experiment progresses. If Tomcat security turns
> out to be too narrow a focus, I'll open it up to anything Tomcat related.
>
> Mark
>
>
> [1] https://simonwillison.net/2021/Feb/19/office-hours/

Just curious: how did it work out?

---rony


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

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Leo,

On 26.02.2021 01:52, leo wrote:
> On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote:
>
>> P.S.: Have tested my implementation with Nashorn on Java 8 and it works out 
>> of the box! Still, you
>> would need to test the implementation thoroughly yourself (stability, 
>> performance, resources) and
>> would be asked to come back with feedback on each of these qualities. So 
>> stay tuned, will publish a
>> link to the implementation with a proper Nashorn/JavaScript sample war in 
>> this mail thread in a few
>> days.
>
> How cool is this! Let me know when you it ready, please. Thanks a lot!

O.K., had a few things I could finalize. Created two war files, 
"demoJavaScript.war" and
"demoRhino.war". The first got tested against Nashorn, the second - you guessed 
it ;) - against
Rhino (7.1.13). They are meant as little proof-of-concepts that should help you 
to get up and
running with them.

Please note that the libraries are beta, though appear to be stable. Yet, there 
may be
errors/problems in them or there may be changes coming up.

If you have feedback of any sorts, please come forward (stability, usability, 
performance,
resources, etc.).

Basically you just need to go to [1] and get the two war-files (copy to 
$CATALINA_HOME/webapps) plus
either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or 
jakarta.ScriptTagLibs.jar (for Tomcat
10) which you should copy to the shared directory at $CATALINA_HOME/lib and 
restart Tomcat to get
them recognized. If you want to test with Rhino you should follow the 
directions at [1] and copy the
mentioned two rhino jar files to the shared library directory as well.

In general you should take the time and look over that page at [1], I tried to 
remain as brief as
possible. :)

Also please do not forget that the target audience of [1] has been so far the 
Rexx community and my
BA students who learned programming using ooRexx in a semester and with that 
knowledge should now
become able to create little web sites for their own purposes and maybe with 
some experience for
small businesses/organizations given the information at [1] as a starting point.

Of course, if there are any questions please do not hesitate and please ask 
them!

HTH,

---rony

[1] Homepage of the ScriptTagLibs libraries:
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/beta/>



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

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

On 23.02.2021 04:21, leo wrote:
> On 18 Feb 2021, at 3:15, André Warnier wrote:
>
>> On 17.02.2021 14:59, Christopher Schultz wrote:
>>
>> […] On the face of it, it looks much simpler to set up a local Nodejs 
>> server, and proxy the
>> corresponding requests from Tomcat to it.
>
>
> Regarding why a servlet _in_ Tomcat and not a proxy: The production 
> environment is very
> restricted. We can add wars and jars to Tomcat, but we can't install new 
> separate OS native
> applications.
>
> That’s why I thought Nashorn could be a way to deal with this restriction - 
> it even is built into
> Java 8!
Note, Nashorn got removed from the standard JDK 15, but got resurrected as its 
own proper OpenJDK
module such that one can continue to use Nashorn on JDK 15 or later. [1]

---rony

[1] 

P.S.: Have tested my implementation with Nashorn on Java 8 and it works out of 
the box! Still, you
would need to test the implementation thoroughly yourself (stability, 
performance, resources) and
would be asked to come back with feedback on each of these qualities. So stay 
tuned, will publish a
link to the implementation with a proper Nashorn/JavaScript sample war in this 
mail thread in a few
days.


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

Re: Ad Apache Sling scripting (Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Woonsan,

On 18.02.2021 18:02, Woonsan Ko wrote:

> You might want to take a look at this, too:
> - http://portals.apache.org/bridges/bridges-script/index.html
>
> Of course, there must be outdated dependencies, but the idea is the
> same and it has working code: integrate with JSR-223 for jruby,
> jython, bsh, js, etc.
> The portlet api (e.g, PortletRequest, PortletResponse, PortletContext,
> etc) should be converted to servlet-api though.

thank you very much for this pointer. The overview page [1] includes references 
to the Portlet
specifications [2,3] which allow to learn about the motivation and also about 
its devised features.
It was also interesting to skim over some bird-eye's-view comparisons between 
Portlets and Servlets
e.g. in [4, 5].

As I have an implementation already in place (with BA students trying it out 
who have been serving a
little bit as a very small subject group) that supports both BSF and JSR-223, I 
would make further
work dependent on my assessment of the student's work (and of course whatever 
feedback comes up
later). The goal was to keep it as simple as possible (KISS principle) such 
that it is easy to
understand/teach and easy to take advantage of, yet make it versatile for the 
script developers
(including demo script samples that will dump the request and response objects 
and query their
getter values such that the students get to see/learn what they convey to them 
at the point of
invocation; just skimming over this extensive information causes them to learn 
what is available and
over time get a "feeling" of what they can expect and do with each request).

---rony

[1] Apache Portals Bridges Homepage: 
<http://portals.apache.org/bridges/index.html>
[2] JSR-168, Portlet Specification: <http://www.jcp.org/en/jsr/detail?id=168>
[3] JRS-286, Portlet Specification 2.0: 
<http://www.jcp.org/en/jsr/detail?id=286>
[4] Nilang, Servlet vs Portlet: 
<https://www.opensource-techblog.com/2014/10/servlet-vs-portlet.html>
[5] Sarin A., Portlets vs. Servlets: Request Processing with Web Components:
<https://www.developer.com/java/web/article.php/3891786/Portlets-vs-Servlets-Request-Processing-with-Web-Components.htm>


> On Thu, Feb 18, 2021 at 11:09 AM Rony G. Flatscher (Apache)
>  wrote:
>> Chris,
>>
>> On 18.02.2021 15:56, Christopher Schultz wrote:
>> ... cut ...
>>> A BSF / JSR-233 environment that is available for any servlet container 
>>> would certainly be an
>>> accomplishment, and probably very useful for some shops (and students!).
>>>
>>> I wonder if there is anything we can learn / steal from Apache Sling.
>> hmm, at first sight Apache Sling defines its own Scripting classes [1] and 
>> seems to not use JSR-223
>> [2, 3] (or BSF [4] for that matter). As a result it seems that each 
>> scripting language that you wish
>> to use in the Sling environment needs to get a proper SlingScript 
>> implementation otherwise you are
>> out of luck.
>>
>> Personally I think one should adhere to the standard Java scripting 
>> framework [2] whenever possible
>> (and I would see no compelling reason at first sight why the Sling project 
>> created its own scripting
>> framework). The Java scripting framework allows non-Java programmers to 
>> create scripts that can be
>> deployed by the Java application and allow them to interact directly with 
>> explicitly supplied Java
>> objects of the Java application. Loading a scripting language for the Java 
>> application programmer is
>> as easy as using javax.script.ScriptEngineManager methods that start with 
>> getEngineBy...() supplying
>> the name of the scripting language (like "groovy", "javascript", "netrexx", 
>> "rexx" and the like),
>> one of its mime-types or one of its file-extensions and then (re-)using that 
>> engine to evaluate
>> script code.
>>
>> The JSR-223 [3] implementation of Java 6 makes it also quite easy to create 
>> new bindings for new
>> programming languages (one merely needs to extend 
>> javax.script.AbstractScriptEngine, which
>> implements already most of the javax.script.ScriptEngine interface, and 
>> implement the
>> javax.script.ScriptFactory interface).
>>
>> ---rony
>>
>> [1] Sling's Scripting Framework:
>> <https://sling.apache.org/apidocs/sling10/org/apache/sling/api/scripting/package-summary.html>
>> [2] Java's Scripting Framework (Since Java 6):
>> <https://docs.oracle.com/javase/8/docs/api/index.html?javax/script/package-summary.html>
>> [3] JCP JSR-223: <https://www.jcp.org/en/jsr/detail?id=223>
>> [4] Apache BSF: <https://commons.apache.org/proper/commons-bsf/>
>>
>>
>

Ad Apache Sling scripting (Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Chris,

On 18.02.2021 15:56, Christopher Schultz wrote:
... cut ...
> A BSF / JSR-233 environment that is available for any servlet container would 
> certainly be an
> accomplishment, and probably very useful for some shops (and students!).
>
> I wonder if there is anything we can learn / steal from Apache Sling.

hmm, at first sight Apache Sling defines its own Scripting classes [1] and 
seems to not use JSR-223
[2, 3] (or BSF [4] for that matter). As a result it seems that each scripting 
language that you wish
to use in the Sling environment needs to get a proper SlingScript 
implementation otherwise you are
out of luck.

Personally I think one should adhere to the standard Java scripting framework 
[2] whenever possible
(and I would see no compelling reason at first sight why the Sling project 
created its own scripting
framework). The Java scripting framework allows non-Java programmers to create 
scripts that can be
deployed by the Java application and allow them to interact directly with 
explicitly supplied Java
objects of the Java application. Loading a scripting language for the Java 
application programmer is
as easy as using javax.script.ScriptEngineManager methods that start with 
getEngineBy...() supplying
the name of the scripting language (like "groovy", "javascript", "netrexx", 
"rexx" and the like),
one of its mime-types or one of its file-extensions and then (re-)using that 
engine to evaluate
script code.

The JSR-223 [3] implementation of Java 6 makes it also quite easy to create new 
bindings for new
programming languages (one merely needs to extend 
javax.script.AbstractScriptEngine, which
implements already most of the javax.script.ScriptEngine interface, and 
implement the
javax.script.ScriptFactory interface).

---rony

[1] Sling's Scripting Framework:

[2] Java's Scripting Framework (Since Java 6):

[3] JCP JSR-223: 
[4] Apache BSF: 



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

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Hi Chris,

On 17.02.2021 14:59, Christopher Schultz wrote:
> Rony and Leo,
>
> On 2/17/21 02:58, Rony G. Flatscher (Apache) wrote:
>> Hi Leo,
>>
>> why would you want to do that if you could do the same with Java? What is 
>> the motivation, the use
>> case for you?
>>
>> How urgent is this (I may have something for both, Java EE and Jakarta EE, 
>> but need a little bit of
>> time)?
>>
>> —-rony
>>
>>
>>
>> On 15.02.2021 07:29, leo wrote:
>>> Hi there
>>>
>>> I am trying to find out how to process servlets written in server-side 
>>> JavaScript through Tomcat.
>>>
>>> I looked through the Tomcat FAQ and How-To but couldn't find anything. By 
>>> googling I found a way
>>> to hook up Python through Jython's PyServlet class. I tried this and it 
>>> works great.
>>>
>>> But I am looking for server-side JavaScript in Tomcat. I am aware of the 
>>> JavaScript engine
>>> Nashorn. Is there a way to hook up Nashorn with a servlet class, so that 
>>> Tomcat serves JavaScript
>>> servlets? Something like a "JavaScript Server Page" for Tomcat would be 
>>> fine too.
>>>
>>> Many thanks for any pointers,
>>> Leo
>>>
>>> ps: I use Tomcat 8.5, but I could move to another Tomcat version for this.
>
> Weird; I never saw the OP on the list, only Rony's reply.

Yes, somehow it appeared later (Tuesday evening here, but the date and time in 
the post is Monday),
at least I recognized it Tuesday evening for the first time.


> Usually if you want to use server-side JavaScript, you use something like 
> Node.js instead of a
> servlet container. Why not use Node?

This may be an option if you desire to write in JavaScript.
(But it may be the case that creating web applications under e.g. Tomcat may be 
even easier than
with Node, one would have to check it out though. ;) )


> If you'd really like to use Tomcat, you will need to write a Servlet that 
> establishes a JavaScript
> environment (e.g. Nashhorn), provides all the plumbing for the 
> servlet-container provided
> resources (e.g. request, response, streams, session, etc.) as well as 
> error-handling, etc.
>
> It's a big job.
>
> I'd be surprised is nobody had built something like this before. Or maybe 
> everybody just uses
> Node.js.

Well, I had a need to let Business Administration (BA) students who just 
learned programming in an
easy to learn, yet powerful programming language (ooRexx, a message based, 
dynamically typed
language, originating at IBM, but in open-source for a long time) create little 
web applications
with Tomcat. This way they experience what is basically involved when creating 
a web app in person
(even if they never will create fully fledged web apps on their own it will 
help them get a basic
understanding, better estimates for web app projects and the like).

For these BA students - even if they "experienced" - Java or JavaScript would 
be outside of their
scope, short of having enough learning and training time needed for mastering 
Java and JavaScript to
the extent that is needed to create fully-fledged web applications in Java 
(like a web-shop with
cart, e-mail-newsletter, uploading files, etc.). This has to do with the BA 
curriculum in question
that does not provide enough resources/time (in this particular case a four 
hours lecture with
homework assignments for the duration of one semester, i.e. appr. for four 
months) for learning a
programming language like Java or JavaScript to a professional extent, which 
would be possible e.g.
at a technical university or in specific IS/CIS studies.

My BA students on the other hand have a working knowledge and expierence with 
ooRexx (which they
learned in a four hour class during a semester and learned to apply it to 
interact with Windows, MS
Office, but also with Java - camouflaged as ooRexx - in an operating-system 
independent manner, i.e.
creating GUI, socket programs, OpenOffice/LibreOffice, exploiting JavaFX in an 
operating system
platform independent manner) such that ooRexx would have become feasible for 
them for using it to
learn and to experiment with creating  web apps, if they so desire. If only 
Tomcat et.al. would
allow for that somehow.

As having authored Apache BSF and JSR-223 (package javax.script introduced in 
Java 6) bindings for
ooRexx (using a combination of JNI, C++, Java, ooRexx) it would be feasible and 
desirable to create
a solution that not only supports a single scripting/programming language like 
ooRexx in this case,
but supports in general also any other programming language for which there is 
a bindings either for
Apache BSF and/or JSR-223 out of the box. As there is a JSR-223 bindings for 
Nash

Re: Run servlets on Nashorn written in server-side JavaScript

[Rony G. Flatscher (Apache)]

Hi Leo,

why would you want to do that if you could do the same with Java? What is the 
motivation, the use
case for you?

How urgent is this (I may have something for both, Java EE and Jakarta EE, but 
need a little bit of
time)?

—-rony



On 15.02.2021 07:29, leo wrote:
> Hi there
>
> I am trying to find out how to process servlets written in server-side 
> JavaScript through Tomcat.
>
> I looked through the Tomcat FAQ and How-To but couldn't find anything. By 
> googling I found a way
> to hook up Python through Jython's PyServlet class. I tried this and it works 
> great.
>
> But I am looking for server-side JavaScript in Tomcat. I am aware of the 
> JavaScript engine
> Nashorn. Is there a way to hook up Nashorn with a servlet class, so that 
> Tomcat serves JavaScript
> servlets? Something like a "JavaScript Server Page" for Tomcat would be fine 
> too.
>
> Many thanks for any pointers,
> Leo
>
> ps: I use Tomcat 8.5, but I could move to another Tomcat version for this.
>
>


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

Re: How to get the tag name from within a taglib class ?

[Rony G. Flatscher (Apache)]

Hi Chris,

On 11.09.2020 19:31, Christopher Schultz wrote:
> > P.S.: If possible I would like to write a single tagclass, but use
> > it for two or more different tags, as the implementation would
> > share quite a lot of code. Besides, it might be helpful for
> > debugging.
>
> It seems like this is the wrong approach, unless you just want to use
> this for something like logging.

Not logging, but support for scripting languages.

> I you want the tags to behave differently, then you should have
> separate tag implementations. 

In this case the only difference would be that in one case ("script", 
"scriptlet") a return value
gets ignored, in the other case ("expression") the return value is used to 
print its string value to
the JSPWriter ("out").

> Feel free to build a base class with the shared code and then implement the 
> differences in subclasses.
Yes, if there is no easy way to learn about the tag that the tagclass got 
invoked for, which seems
to be the case here.
> It's been a lng time since I wrote a custom tag library but I do
> remember that the whole process was very painful and despite the
> flexibility allowed by the API, lots of common things (like getting
> the tag name!) were either awkward or impossible.

Well, it is not really "painful", just a lot of power, many roads that could be 
chosen and
flexibility at hand which at times is overwhelming for a newbie in this corner, 
hence my brief
question. :)

> IMO, the JSP effort was a stepping-stone on a path to better
> technologies like Velocity, FreeMarker, and others. If I were king,
> JSP would just go away. Just my POV of course, you are welcome to fall
> in love with JSP. :)

This assumes that the JSPs get written in Java only and one is ready to take on 
the learning curves
for additional frameworks.

In this case the aim is to allow scripting languages either via Apache BSF [1] 
(like Groovy
implemented in Java, ooRexx implemented in C++) or via the Java scripting 
framework [2] ("JSR-223"
[3], "javax.script") to be used for writing JSPs. This may not be 
attractive/interesting for
Java-savvy programmers who would create their server pages in Java, but it is 
*very* attractive,
even important for non-Java programmers who know one of the supported scripting 
languages.

In the end it should be easy to use Tomcat as the (Java-implemented) web server 
for web applications
that get implemented in other programming languages. Very much like the Apache 
web server [4] which
is written in C and allows other programming languages to exploit it.

---rony

P.S.: Maybe I should come up with a brief posting that tries to explain why it 
is important to
support non-Java programming languages in JSPs by default (and if 
interestesting to the Tomcat
community I can offer the code under AL, once it is done). Not sure whether all 
in the Tomcat
community know that Apache BSF ("Bean Scripting Framework") was created 
originally to allow
scripting languages to be used in JSPs! Hence I was very surprised to learn 
that scripting languages
are not supported in Tomcat by default.

[1] "Apache Bean Scripting Framework (BSF)": 


[2] Java package "javax.script" ("JSR-223"):


[3] "JSR-223", the "Java specification request 223":
 or


[4] "Apache Web Server", "Apache HTTP Server Project": 

How to get the tag name from within a taglib class ?

[Rony G. Flatscher (Apache)]

While exploring, experimenting with creating a taglib (implementing the BodyTag 
interface) I would
have a need to find out the tag name that caused the tagclass to run.

Is this possible? If so, how would one be able to get at that tag name (any 
brief hints would suffice) ?

---rony

P.S.: If possible I would like to write a single tagclass, but use it for two 
or more different
tags, as the implementation would share quite a lot of code. Besides, it might 
be helpful for debugging.




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

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

Hi Chris,
> On 10/13/19 08:40, Rony G. Flatscher (Apache) wrote:
... cut ...
> > Or with other words, what is needed to allow "<%@page
> > language="rexx"%>" ("rexx" being a javax.script.Engine, could be
> > "javascript", "jython", "php", "jacl", "jlog", ...), which might
> > be the easiest for the script language programmers?
>
> I think your question *does* have an actual answer, but I'm going to
> put it off for one more post, because I think this is the better
> answer to your question: "It doesn't matter what is needed, because
> it's a bad idea and shouldn't be done, anyway."
>
> If you agree that better tag libraries are needed more than
> scripting-style code blocks, then why persist in trying to build-out
> technology to enable scripting-style code blocks?
>
> If I were king, I'd deprecate the "language" attribute in JSP and
> abolish scriptlets *entirely*, making this whole question moot.
>
> You can also resurrect the BSF-style tag library and allow any kind of
> scripting in there -- even mixed-language pages! -- that you want,
> which I also think is a bad idea.

Maybe an example makes clear what I would be after, using two JSP samples [1], 
[2] from the net that
serve as tutorials for JSPs being deployed via Tomcat:

  * [1] shows the following sample JSP page:
  o the code uses Java:

<%@ page language="java" contentType="text/html"%>
<%@ page import="java.text.*,java.util.*" %>


Date JSP

<% SimpleDateFormat sdf=new SimpleDateFormat("MM/dd/"); %>

Welcome to Tomcat! Today is <%= sdf.format(new Date()) %>



  o the above JSP should be replacable by e.g. using the RexxScriptEngine 
(implementing
javax.script.ScriptEngine) hence with the following Rexx code [3] 
replacing the Java code above:

<%@ page language="rexx" contentType="text/html"%>


Date JSP


Welcome to Tomcat! Today is <%= date("usa") %>




  * [2] shows the following sample JSP page:
  o the code uses Java:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="java.util.Date" %>


Hello World


<% out.print("Hello World!"); %>
Today is: <% out.print(new Date().toString()); %>



  o the above JSP should be replacable by e.g. using the RexxScriptEngine 
(implementing
javax.script.ScriptEngine) hence with the following Rexx code [3] 
replacing the Java code above:

<%@ page contentType="text/html;charset=UTF-8" language="rexx" %>


Hello World


<% out~print("Hello World!") %>
Today is: <% out~print(date()) %>



If the JSP samples [1], [2] are good for Java, than the suggested alternatives 
above (using Rexx for
the sake of the example) would be good for any other (Java scripting) language 
as well?

Such a solution would allow non-Java-programmers to create and deploy JSPs 
written in their language
of choice [4] using Tomcat without a need to know Java.

---rony

[1] "How to Run a JSP Program in Apache Tomcat (Windows)", URL:
<https://www.webucator.com/how-to/how-run-jsp-program-apache-tomcat-windows.cfm>

[2] "HelloWorld from Java jsp with OpenJDK 11 packaged Maven war and deploy on 
Tomcat 9", URL:
<https://github.com/jbilander/HowTos/wiki/HelloWorld-from-Java-jsp-with-OpenJDK-11-packaged-Maven-war-and-deploy-on-Tomcat-9>

[3] Here ooRexx ("open object Rexx") is being employed which is an interpreted, 
dynamically typed
and (like Smalltalk) message based language with a very easy syntax, yet quite 
powerful. The message
operator is the tilde (~), left is the receiver, right the message name with 
optional arguments
(conceptually the receiver looks up the method that has the same name as the 
received message,
invokes it and returns the result, if any). Here the built-in-function date() 
gets used to get and
display the current day.

[4] The idea would be to create a generic support by using javax.script such 
that all languages for
which javax.script.ScriptEngine implementations exist could be deployed by 
merely changing the
language attribute from "java" to the registered name of the scripting language 
one wishes to use.
Such a javax.script support would allow for supplying e.g. the request and 
response objects as
arguments for each invocation in a standardized way by placing them in the
ScriptContext.ENGINE_SCOPE Bindings using e.g. ScriptEngine.ARGV as a key (a 
constant resolving to
"javax.script.argv") for the Java array that contains the arguments, optionally 
adding "out" and the
like into the ScriptContext.ENGINE_SCOPE Bindings etc. (like submitting the 
name of the JSP file for
debugging via ScriptContext.FILENAME, ...)

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

Chris:

thank you for your information and reflections!

> On 10/10/19 08:16, Rony G. Flatscher (Apache) wrote:
>
... cut ...
> > 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!

How (where, what needs to be extended, what needs to be deployed how) would 
this have to be
implemented to allow it to work generically in all containers for all 
javax.script engines?


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

Concurring! :)

Actually in [1], p. 58, last paragraph ( almost ten years ago) the student 
concluded:

"While the Script Tag Library fills a gap in current Java web development 
technology, more work
could be done on the JSP specification
itself. The specification already includes the page directive facility for 
specifying the
language of a JSP page. Now that JSR-223 is part of the
core Java library, it is possible to mandate that implementing containers 
should support
languages other than Java by using the javax.script
API. While this would prevent the mixing of multiple scripting languages on 
one page, it is
unlikely that a JSP page would be worked on by multiple developers using 
different scripting
languages, making that ability something of an edge case."

What would be the starting point, how would you advise to implement this such 
that any javax.script
language could be used just by denoting its name?
(Short of such a possibility the "scriptlet"-concept can hardly be 
circumvented.)

Or with other words, what is needed to allow "<%@page language="rexx"%>" 
("rexx" being a
javax.script.Engine, could be "javascript", "jython", "php", "jacl", "jlog", 
...), which might be
the easiest for the script language programmers?

---rony

[1]  Ryabenkiy S.: "Java Web Scripting und Apache Tomcat",
<http://wi.wu.ac.at/rgf/diplomarbeiten/BakkStuff/2010/201007_Ryabenkiy/201007_Ryabenkiy_WebScripting_ApacheTomCat_TagLib.pdf>.

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

George:

On 12.10.2019 02:17, George S. wrote:
> I'm a little confused. What would one hope to gain by doing this?

This way you gain all non-Java-programmers to use Tomcat and create server 
applications in their
programming languages of choice. Targeting javax.script languages any such 
language could be then
used, cf. [1].

It seems that it is still the case that PHP is predominately used for server 
pages.

In the case of Microsoft developed software cf. ASP.NET [2] which allows for 
using any of the .NET
languages [3], like VB.NET, C#, JScript.NET et.al.

So with other words, the idea is to make Apache Tomcat a friendly host for all 
those programmers who
do not program in Java, but rather in one of the JVM/javax.script languages, 
putting it again on par
with Microsoft's solution if not allowing for surpassing it! :)

---rony

[1] "List of JVM languages" (incomplete list): 
<https://en.wikipedia.org/wiki/List_of_JVM_languages>

[2] "ASP.NET": <https://en.wikipedia.org/wiki/ASP.NET>

[3] "List of CLI languages": 
<https://en.wikipedia.org/wiki/List_of_CLI_languages>


> 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

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

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.

---rony

[1]

with an example that instrumentaes PHP and Rexx.




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

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

Hi Konstantin,

On 09.10.2019 15:31, Konstantin Kolinko wrote:
> вт, 8 окт. 2019 г. в 18:11, Rony G. Flatscher (Apache) :
>> 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!
> 1. There is no such feature in Apache Tomcat.
>
> Tomcat implements JSP specification and the specification [1] only
> supports language="java" in a JSP declaration.
>
> [1] 
> https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-JavaServerPagesandExpressionLanguageSpecifications
>
> Support for other language needs some specification document of such a
> feature, and I do not know about any such document.

Hmm, what steps would be necessary and where? One idea would be to extend the 
support for any of the
javax.script languages.

... cut ...

---rony



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

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

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)?
>>
>> If not, any advice/hint how to realize/create such a functionality (for then 
>> creating such a
>> tutorial instead) would be highly appreciated!
>>
>
> I know nothing about the subject matter, but was searching Google for 
> "javax.script language jsp"
> and found this :
> http://wi.wu.ac.at:8002/rgf/diplomarbeiten/BakkStuff/2010/201007_Ryabenkiy/201007_Ryabenkiy_WebScripting_ApacheTomCat_TagLib.pdf
>
> (look around page 50).
> Does this help ?

Yes and no! :)

This work has been created under my supervision almost ten years ago. :)

The student did an exceptional job and created proof-of-concept taglibs for BSF 
(Apache Bean
Scripting Framework) and JSR223 (Java scripting framework 'javax.script') (and 
even a
proof-of-concept javax.script implementation for ooRexx).

> On the side, even though (or maybe because) I did not previously know 
> anything about this, I found
> this document really impressive in terms of providing a terse but extremely 
> readable background of
> the whole thing, all the way to some practical examples, all in less than 100 
> pages. And this was
> a bachelor's thesis. So I don't know if it helps you, but I enjoyed it.
*Great!*
:)
> Looking up the author in Google, it doesn't seem that he really needs my 
> modest plaudits though.

:)

---

Maybe I should reformulate the request in form of open questions:

  * Is there any container that supports for the page directive the use of any 
javax.script language
such as Jython, ooRexx, et.al.?
  * Is there any official/supported taglib to allow javax.script languages to 
be deployed in JSPs
like demonstrated as a proof-of-concept in Stanislav Ryabenkiy's work? Are 
there any initiatives
for creating such a support?
  * Is there any interest in allowing Java scripting languages to be used in 
JSPs as demonstrated as
a proof-of-concept in Ryabenkiy's work with PHP/Quercus, Python/Jython and 
ooRexx?

---rony

P.S.: My request stems from the expectation that by now javax.script languages 
are fully supported
in JSPs, which may not be the case at all judging from the answers so far.

P.P.S.: <http://wi.wu.ac.at/rgf/diplomarbeiten/> would list all sorts of 
student's work that might
be interesting or of help for others (like the above mentioned Bachelor thesis).

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

On 08.10.2019 17:53, Zero wrote:
> On 10/8/19 5:11 PM, 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
>
>
> How about TutorialsPoint ?

Thank you, already went through that but did not find anything related to 
javax.script languages (it
documents the "language" attribute (giving "java" as a value) in the page 
directive
(https://www.tutorialspoint.com/jsp/page_directive.htm).

---rony


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

Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

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

[BSF,Tomcat] ad JSR-223 taglib for Tomcat ... (Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Rony G. Flatscher (Apache)]

Resending attempt.


Hi Henri,

relating to our conversation of last fall, I just wanted to point out
that Mr. Ryabenkiy posts of today (copied at the end to inform the
BSF-community) fulfills the idea of creating a jsr-223 taglib for Tomcat.

He applies the Apache License 2.0 to his work, such that it can be taken
on by ASF.

The Quercus/Resin
http://www.caucho.com/resin-3.0/quercus/tutorial/module/index.xtp
package Mr. Ryabenkiy refers to is used in his work as proof of concept
to use PHP scripts in Tomcat served JSP (which might be quite
interesting for PHP-acquantied programmers, who have no expert knowledge
of Java) !
(He also uses the scripting language ooRexx as a proof of concept for
which he wrote a JSR-223 engine.)

In effect all scripting languages can be used, that adhere to Java 6
scripting a.k.a. JSR-223 with his taglib to create scripts for JSP. It
would even be possible to use multiple scripts in different languages
for the same JSP.

It will (again) allow for JSP and Java what ASP allows for the MS world.

---rony



On 13.10.2009 08:17, Rony G. Flatscher (Apache) wrote:
 Henri Yandell wrote:
   
 Not sure where Christopher's email was, but:

 If there is any interest in a retired taglib, I'm all for it being
 merged into the Extended Taglib. Currently I plan to consider
 replacing the functionality from String Taglib (mostly as EL
 functions), Log Taglib and JNDI Taglib (perhaps).

 It sounds like BSF taglib, given it has only the two tags, might be
 very interesting if a dependency on BSF itself can be avoided (ie:
 base it on javax.script).
   
 
 +1

 If you include just the taglib (the JSR-223 to be created), then its
 usage would be restricted to Java 6 and up, such that current Java 1.4
 and 1.5 installations in the field could not take advantage of it.

 To cover Java 1.4 and 1.5 BSF 3.0 got created, which implements the
 javax.script specifications. If BSF 3.0 is included then the scripting
 support will be available from Java 1.4 on. Starting with Java 6 the
 Java 6 javax.script would prevail due to using its own package by
 placement of the classes.

 ---rony


 cut here, Mr. Ryabenskiy post of 2010-08-04
--
 Original Message 
Subject:New taglib to script JSP pages in languages other than Java
Date:   Wed, 4 Aug 2010 09:49:20 +0200
From:   Stanislav Ryabenkiy stani.ryaben...@gmail.com
To: taglibs-u...@tomcat.apache.org, d...@tomcat.apache.org



Hello,

as I haven't posted here before, I hope I won't make a mistake by
posting to both of these lists. IMHO, this announcement is relevant to
both communities.

This is to inform the taglibs-user and tomcat-dev communities of a
small new taglib which allows to script JSP pages in laqnguages other
than Java. Scriptlets and expressions using the taglib have access to
the same implicit objects normal JSP scriptlets have access to.
Internally, the taglib only depends on the javax.script interface
defined as part of JSR-223 and included in Java 6 onwards, although it
can also work with other implementations of javax.script on earlier
version of Java (such as, for instance, Bean Scripting Framework 3).
So for people who want to include scripts in their JSP pages, any
scripting language that exposes a javax.script interface can be used.

Given the nature of the project, and the existence of partial
alternatives at least for some languages (such as Quercus/Resin), I
expect interest to be quite small (if any), but if there's any
interest it could be included in the newly re-organized Extended
Taglib. Ideally, I would want Tomcat to support this kind of
functionality natively via the language attribute of the page
directive, but the taglib at least offers a simpler and
container-independent solution.

Source code can be found at:
http://stani.ryabenkiy.com/downloads/releases/script-taglib-1.0.tar.gz
The related thesis paper (with source code in appendix):
http://stani.ryabenkiy.com/downloads/papers/scripting_thesis.pdf

Kind Regards,
Stani

Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Rony G. Flatscher (Apache)]

Henri Yandell wrote:
 Not sure where Christopher's email was, but:

 If there is any interest in a retired taglib, I'm all for it being
 merged into the Extended Taglib. Currently I plan to consider
 replacing the functionality from String Taglib (mostly as EL
 functions), Log Taglib and JNDI Taglib (perhaps).

 It sounds like BSF taglib, given it has only the two tags, might be
 very interesting if a dependency on BSF itself can be avoided (ie:
 base it on javax.script).
   
+1

If you include just the taglib (the JSR-223 to be created), then its
usage would be restricted to Java 6 and up, such that current Java 1.4
and 1.5 installations in the field could not take advantage of it.

To cover Java 1.4 and 1.5 BSF 3.0 got created, which implements the
javax.script specifications. If BSF 3.0 is included then the scripting
support will be available from Java 1.4 on. Starting with Java 6 the
Java 6 javax.script would prevail due to using its own package by
placement of the classes.

---rony




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

Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Rony G. Flatscher (Apache)]

Christopher,

thanks for your information!

  AFAIK the BSF taglib has been allowing one to add code in all of the
  BSF supported scripting languages to JSPs. Not knowing, wheter there
  are alternatives available in the current Tomcat

 Tomcat itself contains little in the way of tag libraries, except for
 the JSTL required by the JSP 2.1 specification (and higher).

  In case the BSF taglib is needed for adding scripts in scripting
  languages to JSPs, I would kindly suggest to not retire it, but to
  keep it available for interested parties in the Tomcat realm.

 So, let me clear a few things up:

 1. The Tomcat team didn't retire the BSF tag library. The Jakarta BSF
 tag library folks retired it. You should complain to them.
They are all off (enjoying retirement) ...
;-)

 2. The Apache Software Foundation (ASF) never deletes code forever. Just
 because it's retired doesn't mean it's no longer available: it just
 means that they will no longer be maintaining it by adding features,
 fixing bugs, or answering questions about it.
Yes, but the semantics of retirement indicates that they go out of
service (are not useful in todays world anymore).

 Note that the jakarta-taglibs-BSF project hadn't had a news announcement
 since 2002, so it was pretty much already dead.
Yes, but does that mean it is not useful anymore, needs to get retired,
has become irrelevant?

In this particular case it is just a sign that this particular
functionality has become stable and there has not been a need to add new
functionality (what functionality would have been needed in this taglib,
other than enabling scripting languages to become usable to create
scripts embedded in JSPs) ?

Coming from BSF (which BSF taglib exploits) it is not clear to me,
whether Tomcat users have been exploiting this taglib or not (actually,
if it gets retired, this means that either the taglib is not needed
anymore, because of an alternative technology put in place, or the
taglib has not been exploited, used at all).

  In case there are alternatives available in Tomcat to the BSF taglib,
  please be so kind and point them out (just short pointers would
  suffice!).

 What is it that you are trying to do, exactly? It's possible that simply
 using the BSF library directly (without a tag library) is your best
 option. There was a fad for a while where everything was being wrapped
 into a tag library and JSP was starting to look like ColdFusion. CF was
 eventually re-implemented in Java using JSP tag libraries so I guess JSP
 had the last laugh.

 I never thought non-UI-related tag libraries had any business existing
 because I firmly believe in separation between model/controller and
 view: the view simply should not be sending emails, communicating with
 databases (at least not directly), sending JMS messages, or copying
 files around.
E.g. if you look into the MS world you will immediately stumble over
tons of ASPs which employ tons (even a mix) of scripting languages.
Scripting languages in that world empower even end-user kind of
programmers to quickly and easily insert code in a language they can
master for web-based applications (and again, they take advantage of
that possibility). (There are more reasons, arguments, why it may
actually make sense to allow scripting languages to be used in server
pages, of cours.)

Also, experts in once scripting language are enabled to apply their
knowledge for Web apps by creating the needed logic in their scripting
language for server pages, removing the need for them to learn a new
programming language. (Again, there are other good reasons as well.)

 If you want to use another scripting language to generate content, then
 why bother with JSP in the first place? Why not use a tool geared
 towards allowing you to use your scripting-language of choice outside of
 a JSP context?
This would lead to environments that lock-in the developers in specific
environments, which only are available for themselves (cf. PHP, Ruby,
etc. environments). Having an established and proven environment
available, like Tomcat, making it possible to mix-in code in scripting
languages, would be a boon.

If it is possible to include script code into JSPs, then why not allow
for that? The BSF taglib would allow for that, making it possible to
mix-and-match all supported scripting languages in JSPs. (And again,
there may be many different reasons for doing that.)

---

Having said all that I would like to make sure that I have no intentions
to run (or start) a war of opinions. It is o.k. with me if I learn
that currently in Tomcat this functionality is not really seen as a
benefit for Tomcat (hence not taking over the BSF taglib, but instead
letting it retire).

---rony

P.S.: As long as the BSF taglib can be used with Tomcat, users who have
a need to use scripts in JSPs will be able to do so (if they know that
this is possible exists in the first place).

P.P.S.: Also in the controller (citing your MVC argument above) you
could use 

Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]

[Rony G. Flatscher (Apache)]

Hi there,

not sure whether this is a user or dev question, hence sending it to
both, please forgive, if wrong.

Learning about the finalization of moving taglib from jakarta to tomcat,
one could also learn that the BSF taglib got retired in the process.
AFAIK the BSF taglib has been allowing one to add code in all of the BSF
supported scripting languages to JSPs. Not knowing, wheter there are
alternatives available in the current Tomcat (did a coarse research on
that issue, but did not find any info on this) I created the enclosed
e-mail to the BSF user and dev list to make sure, that users of the BSF
taglib learn about where it has moved to, in case it is still needed.

In case the BSF taglib is needed for adding scripts in scripting
languages to JSPs, I would kindly suggest to not retire it, but to keep
it available for interested parties in the Tomcat realm. In case there
are alternatives available in Tomcat to the BSF taglib, please be so
kind and point them out (just short pointers would suffice!).

TIA,

---rony

P.S.: If the BSF taglib is still needed, then one more (dev) point to
discuss/raise would be to create in a addition a new JSR-223/BSF3 taglib
for the newly released BSF 3.0, which implements the JSR-223
(javax.script) specs. Unlike JSR-223, which is only available starting
with Java 6, BSF 3 supplies the same functionality for Java 1.4
installations or higher, making it a very attractive technology for Java
1.4 and 1.5 installations, as they gain the standard scripting APIs with
it. There would be more to this, but should only be discussed, if a need
for this exists.


 Original Message 
Subject:In the move of some taglibs to Tomcat, the BSF taglib got 
retired
Date:   Fri, 09 Oct 2009 12:18:31 +0200
From:   Rony G. Flatscher rony.flatsc...@wu-wien.ac.at
Reply-To:   Bean Scripting Framework developers bsf-...@jakarta.apache.org
To: Bean Scripting Framework developers bsf-...@jakarta.apache.org,
Bean Scripting Framework users bsf-u...@jakarta.apache.org



Hi there,

just learned from the announcement that in the process of moving taglibs
from Jakarta to Tomcat a lot of taglibs got retired, among them the BSF
taglib.

Not sure at the moment how Tomcat will allow for creating JSPs that
embed code in scripting languages, which was one of the original
applications of BSF, when it was originally developed at IBM (as a
matter of fact, IBM's WebSphere distributed BSF in order to enable Java
Server Page authors to embed scripts in any of its supported scripting
languages, very much like MS allows for in their ASPs).

So for those who have a need for the BSF taglib, here the relevant links:

Information about BSF taglib and examples on how to use it:

http://jakarta.apache.org/taglibs/doc/bsf-doc/

Download BSF taglib from:

http://svn.apache.org/repos/asf/jakarta/taglibs/deprecated/bsf/trunk/

Retired taglibs as of 2009-10:

http://jakarta.apache.org/site/retired-taglibs.html

---rony