Re: efficient redirect map with embedded Tomcat

[Garret Wilson]

On 10/13/2019 11:52 AM, Mark Thomas wrote:

That depends on how you define best. Simplest to implement? Easiest to
maintain? Minimum overhead?


How about, "What best follows the spirit of the Tomcat architecture?"

Or alternatively, "What would be most efficient (i.e. not slowing down 
normal requests)?"




It also depends on how many redirects are you talking about as well as
what sort of % of the over all requests need to be redirected.


Let's say 100 resources need redirecting, to pick an arbitrary number.

(The use case is simply to migrate some old URLs that have probably been 
indexed already or even linked on the web. Theoretically the entire site 
would need to redirect its old URLs, but probably only the pages.)


Garret


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

Re: efficient redirect map with embedded Tomcat

[Mark Thomas]

On 12/10/2019 20:35, Felix Schumacher wrote:
> 
> Am 12.10.19 um 17:13 schrieb Garret Wilson:
>> Could somebody at least point me to the best place to wire in
>> site-level per-resource redirects in embedded Tomcat? I can create a
>> solution, I just need to know where it is best to start.
> 
> Did you look at https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html

That depends on how you define best. Simplest to implement? Easiest to
maintain? Minimum overhead?

It also depends on how many redirects are you talking about as well as
what sort of % of the over all requests need to be redirected.

I'd either start with the redirect valve as Felix suggests or - possibly
- a custom resource implementation.

Mark

> 
> Felix
> 
>>
>> Thanks,
>>
>> Garret
>>
>> On 10/11/2019 11:06 AM, Garret Wilson wrote:
>>> This is a question for Tomcat experts before I get started
>>> implementing a new feature.
>>>
>>> Let's say I'm embedding Tomcat to serve static files. At the time of
>>> creation I know that certain paths, such as `foo/bar.txt`, should
>>> redirect to other paths, such as `some/other.txt`. What's the best
>>> way to configure Tomcat to do those redirects? I'm comfortable with
>>> extending the source code.
>>>
>>> Here are a couple of ideas that come to mind:
>>>
>>>  * I could create a redirect servlet and map different instances of it
>>>    to different targets in the context when I configure everything. But
>>>    in Tomcat's routing engine, is the most efficient way to do things?
>>>    (I assume that the servlet mappings can be placed "over" the default
>>>    servlet's path space, that is, cherry-pick paths for redirection,
>>>    falling back to the default file-serving servlet for non-redirect
>>>    paths.)
>>>  * I thought of patching into the default file servlet, overriding
>>>    `org.apache.catalina.WebResource`, and creating virtual
>>>    `RedirectResource` resources that don't correspond to any physical
>>>    file. However it's not obvious to me where I would create a
>>>    redirect. Maybe throw some redirect exception inside
>>>    `WebResource.getInputStream()`? (This is probably not correct. I'm
>>>    just brainstorming. The idea is sound if I knew where to put it.)
>>>  * Should I install a configured rewrite valve when I'm setting up
>>>    embedded Tomcat?
>>>  * Is there some other routing logic in Tomcat I could tap into most
>>>    efficiently, providing a known set of redirects?
>>>
>>> Thanks for any guidance. I'm want to figure out the best way to
>>> attack this before getting very deep in an implementation.
>>>
>>> Garret
>>>
>>>
>>
>> -
>> 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
> 


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

RE: Setting samesite attribute on JSESSIONID

[David Cleary]

On 10/10/19 14:08, David Cleary wrote:
> Have a customer asking about this. I see Tomcat supports it here.
> https://tomcat.apache.org/tomcat-9.0-doc/config/cookie-processor.html
> .apache.org
>
>
>
We currently use defaults, so I'm looking for an XML fragment and
> the file it goes in to add the samesite attribute to the JSESSIONID. 
> I'm assuming they want it globally for all webapps.

>What have you tried already?

To paraphrase Maxwell Smart, "Missed it by that much". Our shipping version is 
at 9.0.20, so the warnings about unknown attribute are expected.

Thanks
Dave


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

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",
.

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


[2] "ASP.NET": 

[3] "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?

[tomcat]

Hi.

On 12.10.2019 02:17, George S. wrote:

I'm a little confused. What would one hope to gain by doing this?


I'm not that much of an expert on Tomcat or its "ecological niche", but in a general 
overall point of view, I would tend to say that anything that "opens up" tomcat to more 
programmers and more users cannot really be a bad thing.
As an example, maybe off-track : there are a lot of web applications based on ruby, 
python, javascript, perl, php, etc.. Mostly, they are based on development frameworks 
similar to the ones for JSP pages, only written in something else than java.  Porting 
these to tomcat using the CGI model is not really practical, and translating them to Java 
and JSP isn't either. (Apart from the fact that in order to really dominate java, you 
pretty much have to spend all your time on it.)
So if this "javax.script" would provide a shortcut to run, with minimal adaptations, pages 
written using some of these other languages, if only temporarily and as a prototype, why not ?


Of course there is a cost, and as Christopher previously pointed out, some previous 
attempt at this did not seem to have had many takers, and it pretty much seems to have 
died by lack of interest.
But then again, in terms of market coverage as a webserver, the cost for tomcat to be 
"single language centric", is certainly not null either.




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




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