Role of different components in the lucee stack

I realize this probably sounds like a ridiculous question, but I’m going to
ask it anyway. For the layman (aka cfml/lucee-script developer), leaving
buzzwords aside, why is the “servlet container” necessary in the world of
lucee (and other languages built on top of Java)?

If the JVM process java bytecode, and Lucee compiles lucee script into java
bytecode, then why do we need Tomcat? I realize that it “implements several
Java EE specifications https://en.wikipedia.org/wiki/Apache_Tomcat,” but
that doesn’t help my understanding (as a layman). Could Tomcat (and the
specifications it implements) be considered an “extension” of the Java,
much like the Lucee 5 “core” will only implement a subset of language
features, with additional features (i.e. image processing, or pdf
processing, or whatever) only available as “extensions” to that core?

In plain English, what exactly does Tomcat provide that Java itself doesn’t
already offer, and why doesn’t Java implement those specifications on its
own?? Help me wrap my melon around this please. Google seems to offer very
little beginner friendly content to “introduction to tomcat
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=introduction%20to%20tomcat.”
Thank you Java/Tomcat/Lucee enlightened warriors.

Brian,

In layman terms (and I’m sure some could consider this an over-simplification, as there are much more complex explanations to be had), the Lucee servlet is the “app" that runs within the servlet container, which is the “app" that runs within the “app" that is the JRE.

Your CFML code is the smallest “doll” in the Java Russian nesting doll, if you will. Each “doll” introduces shared language, classes and conventions along the way that the nested applications/servlets can take advantage of. You wouldn’t want those all in the language, itself, because their purposes, classes and conventions are not universal to all of the potential use-cases of the language.

This is not uncommon in any programming languages. Though they are not called such and differ in their implementation, NodeJS effectively functions as a “JRE" for Javascript, with each dependency in the chain (e.g. ExpressJS) becoming a “container” of sorts that introduces new language and conventions. Rails the same for Ruby - along with its framework ( aka - the Rails "container” ). PHP for the web requires a “container” in the form of FastCGI or some other middleware that can speak to a web server. Building apps with Go, Python, or any other language often requires (or is made easier by) the inclusion of “containers” along the way.

In short, Lucee introduces, via the JRE first and then the servlet container, the shared conventions through which a translation from CFML to the top-level language is possible. Without the nested “doll” the final step of translation is impossible.

HTH,

JonOn April 1, 2016 at 4:32:50 PM, Brian FitzGerald (@Brian_FitzGerald) wrote:

I realize this probably sounds like a ridiculous question, but I’m going to ask it anyway. For the layman (aka cfml/lucee-script developer), leaving buzzwords aside, why is the “servlet container” necessary in the world of lucee (and other languages built on top of Java)?

If the JVM process java bytecode, and Lucee compiles lucee script into java bytecode, then why do we need Tomcat? I realize that it “implements several Java EE specifications,” but that doesn’t help my understanding (as a layman). Could Tomcat (and the specifications it implements) be considered an “extension” of the Java, much like the Lucee 5 “core” will only implement a subset of language features, with additional features (i.e. image processing, or pdf processing, or whatever) only available as “extensions” to that core?

In plain English, what exactly does Tomcat provide that Java itself doesn’t already offer, and why doesn’t Java implement those specifications on its own?? Help me wrap my melon around this please. Google seems to offer very little beginner friendly content to “introduction to tomcat.” Thank you Java/Tomcat/Lucee enlightened warriors.

Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/66032e04-2be9-4064-aaf8-fb59b2e49852%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thank you for your detailed response Jon! I really appreciate you sharing
that analogy with me. Took me a couple reads, but it makes sense and gives
me a better baseline from which I can dig in further.

Just moved my Lucee application to Elastic Beanstalk and was needing to
troubleshoot why Tomcat was crashing, which as you might guess can prove
rather difficult when you know next to nothing about Tomcat!On Friday, April 1, 2016 at 5:29:23 PM UTC-4, Jon Clausen wrote:

On a related note, the servlet container doesn’t need to be as
fully-featured as Tomcat. It just needs to have enough of the shared
classes and conventions in the chain to let Lucee do its thing. For an
example of how CFML can be used as a server-side scripting language, you
need only look at CommandBox:
https://www.ortussolutions.com/products/commandbox

On April 1, 2016 at 5:22:03 PM, Jon Clausen (jon_c...@silowebworks.com <javascript:>) wrote:

Brian,

In layman terms (and I’m sure some could consider this an
over-simplification, as there are much more complex explanations to be
had), the Lucee servlet is the “app" that runs within the servlet
container, which is the “app" that runs within the “app" that is the JRE.

Your CFML code is the smallest “doll” in the Java Russian nesting doll, if
you will. Each “doll” introduces shared language, classes and conventions
along the way that the nested applications/servlets can take advantage of.
You wouldn’t want those all in the language, itself, because their
purposes, classes and conventions are not universal to all of the potential
use-cases of the language.

This is not uncommon in any programming languages. Though they are not
called such and differ in their implementation, NodeJS effectively
functions as a “JRE" for Javascript, with each dependency in the chain
(e.g. ExpressJS) becoming a “container” of sorts that introduces new
language and conventions. Rails the same for Ruby - along with its
framework ( aka - the Rails "container” ). PHP for the web requires a
“container” in the form of FastCGI or some other middleware that can speak
to a web server. Building apps with Go, Python, or any other language often
requires (or is made easier by) the inclusion of “containers” along the way.

In short, Lucee introduces, via the JRE first and then the servlet
container, the shared conventions through which a translation from CFML to
the top-level language is possible. Without the nested “doll” the final
step of translation is impossible.

HTH,

Jon

On April 1, 2016 at 4:32:50 PM, Brian FitzGerald (bmfitz...@gmail.com <javascript:>) wrote:

I realize this probably sounds like a ridiculous question, but I’m going
to ask it anyway. For the layman (aka cfml/lucee-script developer), leaving
buzzwords aside, why is the “servlet container” necessary in the world of
lucee (and other languages built on top of Java)?

If the JVM process java bytecode, and Lucee compiles lucee script into
java bytecode, then why do we need Tomcat? I realize that it “implements
several Java EE specifications
https://en.wikipedia.org/wiki/Apache_Tomcat,” but that doesn’t help my
understanding (as a layman). Could Tomcat (and the specifications it
implements) be considered an “extension” of the Java, much like the Lucee 5
“core” will only implement a subset of language features, with additional
features (i.e. image processing, or pdf processing, or whatever) only
available as “extensions” to that core?

In plain English, what exactly does Tomcat provide that Java itself
doesn’t already offer, and why doesn’t Java implement those specifications
on its own?? Help me wrap my melon around this please. Google seems to
offer very little beginner friendly content to “introduction to tomcat
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=introduction%20to%20tomcat.”
Thank you Java/Tomcat/Lucee enlightened warriors.

Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/66032e04-2be9-4064-aaf8-fb59b2e49852%40googlegroups.com
https://groups.google.com/d/msgid/lucee/66032e04-2be9-4064-aaf8-fb59b2e49852%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.