You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Alex Chaffee <gu...@edamame.stinky.com> on 2000/09/21 20:01:31 UTC
Jasper Changes
Are these Jasper changes (new features / bug fixes / JSP 1.2
additions) going to be rolled back into the Tomcat 3 Jasper source?
If not, then I think it's time to spin Jasper off as a separate
project, or at least a separate top-level subdirectory under
jakarta-tomcat. Then both Tomcat and Catalina will have to change
their build process to include it.
Remember, we want Jasper to work with any servlet engine, including
Tomcat 3, and including other Servlet 2.2 containers.
- Alex
On Thu, Sep 21, 2000 at 06:06:00PM -0000, pierred@locus.apache.org wrote:
> pierred 00/09/21 11:05:59
>
> Modified: jasper/src/share/org/apache/jasper/compiler
> TagBeginGenerator.java
> Log:
> Moved the code to catch a null method to its proper location.
>
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Jasper Changes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> On Thu, Sep 21, 2000 at 03:42:31PM -0700, Craig R. McClanahan wrote:
> > Alex Chaffee wrote:
> >
> > > OK, everyone likes the spin-off idea in theory. Now, before I open up
> > > Craig's gotchas, let me ask:
> > >
> > > Should it live in
> > >
> > > 1) jakarta-tomcat/jasper
> > > 2) jakarta-tomcat-4.0/jasper
> > > 3) jakarta-jasper/
> > >
> > > I vote for 3. How hard is it to set up a new repository?
> > >
> >
> > Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
> > for show? :-)
>
> Yes, it reinforces the fact that Jasper is a separate product from
> either version of Tomcat,
By itself, this action would perpetuate a justifiable confusion among users of Tomcat,
who ask "what in the heck is it?"
Well, our web site says what Tomcat has always meant (and I see know reason to change it,
other than updating the version numbers): a world-class implementation of the Java
Servlet 2.2 and JavaServer Pages 1.1 Specifications. In other words, "Tomcat = Servlets
+ JSP".
For instance, you can ship a servlet container based on the Tomcat 4.0 servlet container
code (Catalina) without the JSP engine, and add anything else you want -- but it's not
Tomcat any more at that point.
Likewise, you can take Jasper and plug it in to a different servlet container and ship it
-- the Apache license is wonderful that way -- but again, it's not Tomcat.
How that is relevant in this discussion is that if you split the JSP engine out as a
separate project, you need to do the same with the servlet container, which needs its own
unique name as well -- in either a 3.x or 4.0 environment -- to avoid confusion. For the
4.0 world that name already exists (even in the bugs database :-) -- in 3.x the name
"Tomcat" is pretty ambiguous.
> and diminishes the temptation to submit bug
> fixes and (non-spec-oriented) feature additions to one or the other
> source tree (excluding the other and leading to source fragmentation).
>
On the servlet container side, the code bases are so totally separate already that there
isn't any reasonable mechanism to share anything more than basic utility classes -- and I
got tired of doing that when people kept making changes to meet 3.x needs (a perfectly
legitimate thing to do) without considering the fact that it would break the 4.x code.
The JSP side needs a similar overhaul. Once you make fundamental changes in the internal
organization, implementing any substantial new feature is two development efforts, not
one, no matter how you slice it.
>
> ---
>
> As for the rest of your message -- I may have time to reply in more
> detail later but --
>
> Given that JSP 1.1 files should run flawlessly in a JSP 1.2 container,
> the only obstacle I see to merging the two is the classfile
> dependencies on the Servlet 2.3 container.
>
> If these cannot be resolved programmatically (and I have a sinking
> feeling they can't), then I propose a version-numbering sort of code
> freeze:
>
Good luck trying to fix this programmatically (it is not just the engine -- the JSP code
generator would have to create version-specific Java code for the servlets it creates,
plus you'd need two versions of most of the runtime support infrastructure).
IMHO it's not worth the effort.
>
> Jasper 1.0 is declared to be the version that shipped with Tomcat 3.x,
> and supports JSP 1.1 and can be deployed on a Servlet 2.2 container
>
> Jasper 2.0 is declared to be the current code base, supporting JSP 1.2
> and requiring Servlets 2.3
>
> Each version will have a build option, selectable at
> build.bat/build.sh time
>
> Until and unless Tomcat 3.x supports a 2.3 facade, it will continue to
> ship with Jasper 1.0 (the included jasper.jar will be version 1.0)
>
> At the time Tomcat 3.x gets a facade, it will switch to shipping with
> Jasper 2.0 (the included jasper.jar will be version 2.0)
>
> Unfortunately, this still leads to fragmentation :-(
>
It's an unavoidable price of progress, especially on major version changes. Labelling
things, or rearranging CVS directories, isn't going to change a thing in that regard.
>
> - A
>
> --
> Alex Chaffee mailto:alex@jguru.com
> jGuru - Java News and FAQs http://www.jguru.com/alex/
> Creator of Gamelan http://www.gamelan.com/
> Founder of Purple Technology http://www.purpletech.com/
> Curator of Stinky Art Collective http://www.stinky.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Jasper Changes
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
On Thu, Sep 21, 2000 at 03:42:31PM -0700, Craig R. McClanahan wrote:
> Alex Chaffee wrote:
>
> > OK, everyone likes the spin-off idea in theory. Now, before I open up
> > Craig's gotchas, let me ask:
> >
> > Should it live in
> >
> > 1) jakarta-tomcat/jasper
> > 2) jakarta-tomcat-4.0/jasper
> > 3) jakarta-jasper/
> >
> > I vote for 3. How hard is it to set up a new repository?
> >
>
> Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
> for show? :-)
Yes, it reinforces the fact that Jasper is a separate product from
either version of Tomcat, and diminishes the temptation to submit bug
fixes and (non-spec-oriented) feature additions to one or the other
source tree (excluding the other and leading to source fragmentation).
---
As for the rest of your message -- I may have time to reply in more
detail later but --
Given that JSP 1.1 files should run flawlessly in a JSP 1.2 container,
the only obstacle I see to merging the two is the classfile
dependencies on the Servlet 2.3 container.
If these cannot be resolved programmatically (and I have a sinking
feeling they can't), then I propose a version-numbering sort of code
freeze:
Jasper 1.0 is declared to be the version that shipped with Tomcat 3.x,
and supports JSP 1.1 and can be deployed on a Servlet 2.2 container
Jasper 2.0 is declared to be the current code base, supporting JSP 1.2
and requiring Servlets 2.3
Each version will have a build option, selectable at
build.bat/build.sh time
Until and unless Tomcat 3.x supports a 2.3 facade, it will continue to
ship with Jasper 1.0 (the included jasper.jar will be version 1.0)
At the time Tomcat 3.x gets a facade, it will switch to shipping with
Jasper 2.0 (the included jasper.jar will be version 2.0)
Unfortunately, this still leads to fragmentation :-(
- A
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Jasper Changes
Posted by cm...@yahoo.com.
> > 1) jakarta-tomcat/jasper
> > 2) jakarta-tomcat-4.0/jasper
> > 3) jakarta-jasper/
> >
> > I vote for 3. How hard is it to set up a new repository?
> >
>
> Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
> for show? :-)
A simple solution is to make a symlink on locus (
i.e. jakarta-tomcat-4/jaseper to jakarta-tomcat/jasper ), and everyone can
use whatever name it prefers.
> > (or, instead of catching an exception, it could switch on the results
> > of context.getMajorVersion()/getMinorVersion() -- taking the context
> > at its word what version it supports)
> >
>
> Ask Costin (and others) how easy it has been to support JDK 1.1 and JDK 1.2 in the
> same container :-). It is really hard to do this right, without substantial
> impacts on your performance (i.e. having to use reflection) or code maintenance
> (two versions).
???
So far the only "hard" thing is to get people that use JDK1.1 and tomcat (
like Jason on SGI, or me on locus ). As long as the code is modular the
1.2 ( and servlet 2.3 ) specific features can easily be implemented in
modules ( that are conditionaly compiled ).
Regarding the impact on performance - all reflection happens on startup (
and it's insignifiant compared with other startup tasks ). ( tomcat still
supports 1.1 and doesn't seem too slow because of that - I never saw any
1.1-specific code in any profiling )
> > In other words, are there any backwards-incompatible features of the
> > JSP-1.2 spec? Or will any JSP-1.1 compliant .jsp file run identically
> > in a JSP-1.2-compliant JSP container?
>
> As things stand right now (and as is currently true of Tomcat 4.0 for everything
> I've tested so far), 100% of servlet 2.2 / JSP 1.1 applications should run under
> containers implementing the new specs, unless they depend on bugs in the
> implementation of their existing container. Failure to do this is a bug.
Tomcat-3.3 will probably implement servlet2.2 also ( or 3.4 if 3.3 freezes
before we have a chance to do it ), and we're trying to make it support
both versions and interpretations.
> Which, going back to the earlier point, raises the question that we are all
> tiptoeing around: what is the future of the Tomcat 3.x code base after 3.2 goes
> final? While bug fix support (and perhaps 3.2.1 or 3.2.2 releases) might be needed
> before Tomcat 4.0 is production quality (it undoubtedly has bugs that need to be
> shaken out, but nearly all of the bug reports recently on 3.1 and 3.2 are for
> things that already work correctly in 4.0 :-), I have no personal time or energy or
> interest in continuing down the current path (although there's a bunch of good
> ideas on performance tuning that can be harvested).
I don't know about future, but 3.3 will have significant performance
enhancements over 3.2 and will likely support servlet 2.3 API in paralel
with 2.2, plus many enhancements in the core.
Other goals: real support for foreign charsets and improvements in
sandboxing
3.4 will probably focus on modules - and will probably result in another
performance boost.
My goal: be able to run sandboxed webapps on a public server with decent
performance.
Costin
Re: Jasper Changes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> OK, everyone likes the spin-off idea in theory. Now, before I open up
> Craig's gotchas, let me ask:
>
> Should it live in
>
> 1) jakarta-tomcat/jasper
> 2) jakarta-tomcat-4.0/jasper
> 3) jakarta-jasper/
>
> I vote for 3. How hard is it to set up a new repository?
>
Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
for show? :-)
>
> Changing the build scripts for tomcat/catalina is not hard -- I like
> Ant -- we just <copydir src="../jakarta-jasper/src" dest="{tomcat.build}"/>
> or some such.
>
> > In the migration to the "jakarta-tomcat-4.0" workspace, this has already been
> > functionally and technically separated (although it wasn't really advertised
> > all that much).
> >
> > The "jakarta-tomcat-4.0" workspace has the following top level
> > subdirectories:
> >
> > catalina -- The 2.3-compatible servlet container
> >
> > jasper -- The 1.2-compatible JSP container
> >
> > webapps -- The 2.3/1.2 compatible example applications
> >
> > Each of these three top level subdirectories contains completely independent
> > build scripts, so you can build what you want and use it separately. So, for
> > example, you can build a servlet container with no JSP engine by just going
> > into the catalina directory and doing a "build dist". Likewise, the "jasper"
> > directory's "build dist" will create a JSP engine you can take anywhere that
> > is 2.3/1.2 compatible.
>
> Unfortunately, there's also
> jakarta-tomcat/src/share/org/apache/jasper/*
> which contains different code than
> jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/*
> and now needs to be merged. :-(
>
Note that the "jakarta-tomcat/src/share/org/apache/jasper" code was the basis for
the Jasper code in "jakarta-tomcat-4.0". It's in the process of being
substantially remodelled (based on the proposal that was presented and voted on
last month), partly due to the new spec requirements (including the requirement to
accept pages in XML format and expose them as an XML stream to validator classes in
custom tag libraries), partly to improve the portability (remove dependencies on
org.apache.tomcat code, which is already done), and partly to provide a clean basis
for improving the quality of the generated code.
Therefore, I disagree (with the idea that it needs to be merged) -- but see more
below.
>
> > > Remember, we want Jasper to work with any servlet engine, including
> > > Tomcat 3, and including other Servlet 2.2 containers.
> > >
> >
> > There are two gotchas to this portability goal:
> >
> > * The new Jasper code requires Servlet 2.3 and JSP 1.2 support, so it
>
> (By the way, your phrase "and JSP 1.2" is a mistake, right? It
> *implements* JSP 1.1 or 1.2, so how can it "require" JSP 1.2?)
>
It *requires* the servlet 2.3 and JSP 1.2 version of "servlet.jar". Jasper
*implements* the JSP 1.2 part of the API, in the same way that Catalina
*implements* the Servlet 2.3 part.
>
> > won't run on 2.2 containers.
>
> I'm not familiar enough with Jasper to know how best to solve this. I
> can imagine at least three possibilities (potentially overlapping):
>
> * a single code base, where 2.3-specific method calls are wrapped in
> "catch (NoSuchMethodError)" and fall back to either 2.2-specific
> implementations, or throw an exception (where the functionality is
> impossible to provide)
>
> (or, instead of catching an exception, it could switch on the results
> of context.getMajorVersion()/getMinorVersion() -- taking the context
> at its word what version it supports)
>
Ask Costin (and others) how easy it has been to support JDK 1.1 and JDK 1.2 in the
same container :-). It is really hard to do this right, without substantial
impacts on your performance (i.e. having to use reflection) or code maintenance
(two versions).
>
> * a set of separate peer classes for JSP 1.1 and 1.2 that are
> instantiated on the fly based on which version mode it's running in
>
> * a separate build process for Jasper-supporting-JSP-1.1 and
> Jasper-supporting-JSP-1.2
>
> It's a tough one. I'm leaning towards the first but it may be
> difficult to do across all Jasper code.
>
> Let me ask another question:
>
> Is there any reason for a JSP-1.1-only version of Jasper to exist? Or
> should we transparently allow (force?) everyone using Jasper to use
> JSP-1.2 features?
>
The only way to get JSP 1.2 is run on a servlet 2.3 container (i.e. the specs are
linked).
For example, JSP 1.2 lets you say <jsp:include page="..." include="false/>, but
implementing this requires the new 2.3 feature of being able to wrap the arguments
to a RequestDispatcher.include() call. This is not going to work on a 2.2
container that depends on the current (2.2) restriction that the arguments must be
the original request and response objects.
>
> In other words, are there any backwards-incompatible features of the
> JSP-1.2 spec? Or will any JSP-1.1 compliant .jsp file run identically
> in a JSP-1.2-compliant JSP container?
As things stand right now (and as is currently true of Tomcat 4.0 for everything
I've tested so far), 100% of servlet 2.2 / JSP 1.1 applications should run under
containers implementing the new specs, unless they depend on bugs in the
implementation of their existing container. Failure to do this is a bug.
There are a very small number of clarifications likely to be included in the final
2.3 release covering some issues that are not currently specified, and where
experience has shown that containers vary in their implementation (example: is a
relative argument to response.sendRedirect() interpreted as context-relative or
server-relative?). If the final answer to this one differs from what Tomcat 3.x
currently does (which interprets it as server-relative), there will be a
compatibility issue due to the spec requirement. But other than that kind of
thing, every app that runs under Tomcat 3.x should work fine under Tomcat 4.0 as
well.
Which, going back to the earlier point, raises the question that we are all
tiptoeing around: what is the future of the Tomcat 3.x code base after 3.2 goes
final? While bug fix support (and perhaps 3.2.1 or 3.2.2 releases) might be needed
before Tomcat 4.0 is production quality (it undoubtedly has bugs that need to be
shaken out, but nearly all of the bug reports recently on 3.1 and 3.2 are for
things that already work correctly in 4.0 :-), I have no personal time or energy or
interest in continuing down the current path (although there's a bunch of good
ideas on performance tuning that can be harvested).
Others, of course, will have different opinions. It's open source -- people can do
what they want.
As for me, I'm putting my time/talent/energy into making a 4.0 release that fully
implements the new specs, has quite a few interesting new features outside of
spec-related things, and is of at least beta quality by ApacheCon Europe (October
23-25). Look for milestone releases between now and then to supplement the nightly
builds that are already available.
>
> > * Although there are zero code dependencies between Jasper and Catalina,
> > there is a dependency on setting a servlet context attribute correctly to
> > pass the webapp classpath to the Jasper servlet. This same dependency
> > (plus some code dependencies) is currently present in Tomcat 3.x.
> >
> > However, Jasper should run fine on any 2.3 container that is hacked to set
> > the right context attributes. And Jon is free to package Catalina (without
> > Jasper) with any page template language he wants :-).
>
> I'm not quite sure I understand this completely but it sounds solved. :-)
>
It means that no reorganization of the current source code base is required to
accomplish the goal of separating the JSP engine from the core servlet container
:-).
> Alex Chaffee mailto:alex@jguru.com
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Jasper Changes
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
OK, everyone likes the spin-off idea in theory. Now, before I open up
Craig's gotchas, let me ask:
Should it live in
1) jakarta-tomcat/jasper
2) jakarta-tomcat-4.0/jasper
3) jakarta-jasper/
I vote for 3. How hard is it to set up a new repository?
Changing the build scripts for tomcat/catalina is not hard -- I like
Ant -- we just <copydir src="../jakarta-jasper/src" dest="{tomcat.build}"/>
or some such.
> In the migration to the "jakarta-tomcat-4.0" workspace, this has already been
> functionally and technically separated (although it wasn't really advertised
> all that much).
>
> The "jakarta-tomcat-4.0" workspace has the following top level
> subdirectories:
>
> catalina -- The 2.3-compatible servlet container
>
> jasper -- The 1.2-compatible JSP container
>
> webapps -- The 2.3/1.2 compatible example applications
>
> Each of these three top level subdirectories contains completely independent
> build scripts, so you can build what you want and use it separately. So, for
> example, you can build a servlet container with no JSP engine by just going
> into the catalina directory and doing a "build dist". Likewise, the "jasper"
> directory's "build dist" will create a JSP engine you can take anywhere that
> is 2.3/1.2 compatible.
Unfortunately, there's also
jakarta-tomcat/src/share/org/apache/jasper/*
which contains different code than
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/*
and now needs to be merged. :-(
> > Remember, we want Jasper to work with any servlet engine, including
> > Tomcat 3, and including other Servlet 2.2 containers.
> >
>
> There are two gotchas to this portability goal:
>
> * The new Jasper code requires Servlet 2.3 and JSP 1.2 support, so it
(By the way, your phrase "and JSP 1.2" is a mistake, right? It
*implements* JSP 1.1 or 1.2, so how can it "require" JSP 1.2?)
> won't run on 2.2 containers.
I'm not familiar enough with Jasper to know how best to solve this. I
can imagine at least three possibilities (potentially overlapping):
* a single code base, where 2.3-specific method calls are wrapped in
"catch (NoSuchMethodError)" and fall back to either 2.2-specific
implementations, or throw an exception (where the functionality is
impossible to provide)
(or, instead of catching an exception, it could switch on the results
of context.getMajorVersion()/getMinorVersion() -- taking the context
at its word what version it supports)
* a set of separate peer classes for JSP 1.1 and 1.2 that are
instantiated on the fly based on which version mode it's running in
* a separate build process for Jasper-supporting-JSP-1.1 and
Jasper-supporting-JSP-1.2
It's a tough one. I'm leaning towards the first but it may be
difficult to do across all Jasper code.
Let me ask another question:
Is there any reason for a JSP-1.1-only version of Jasper to exist? Or
should we transparently allow (force?) everyone using Jasper to use
JSP-1.2 features?
In other words, are there any backwards-incompatible features of the
JSP-1.2 spec? Or will any JSP-1.1 compliant .jsp file run identically
in a JSP-1.2-compliant JSP container?
> * Although there are zero code dependencies between Jasper and Catalina,
> there is a dependency on setting a servlet context attribute correctly to
> pass the webapp classpath to the Jasper servlet. This same dependency
> (plus some code dependencies) is currently present in Tomcat 3.x.
>
> However, Jasper should run fine on any 2.3 container that is hacked to set
> the right context attributes. And Jon is free to package Catalina (without
> Jasper) with any page template language he wants :-).
I'm not quite sure I understand this completely but it sounds solved. :-)
- A
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Jasper Changes
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/21/2000 12:18 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> And Jon is free to package Catalina (without
> Jasper) with any page template language he wants :-).
I'm already doing it with Tomcat + Turbine + WebMacro + Hypersonic SQL +
every .jar under the Sun (pun intended)...
<http://java.apache.org/turbine/tdk/>
It even has Ant build scripts to get you up and running with your own
webapp.
Expect a new version of the Turbine Developers Kit (TDK) available tonight
hopefully.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Jasper Changes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
> Are these Jasper changes (new features / bug fixes / JSP 1.2
> additions) going to be rolled back into the Tomcat 3 Jasper source?
>
Anyone who wants to is welcome to do this ... I'm afraid I don't have time
(and likewise for Pierre) -- we've got deadlines for completing servlet 2.3 /
JSP 1.2 functionality that require us to focus on the 4.0 tree.
>
> If not, then I think it's time to spin Jasper off as a separate
> project, or at least a separate top-level subdirectory under
> jakarta-tomcat. Then both Tomcat and Catalina will have to change
> their build process to include it.
>
In the migration to the "jakarta-tomcat-4.0" workspace, this has already been
functionally and technically separated (although it wasn't really advertised
all that much).
The "jakarta-tomcat-4.0" workspace has the following top level
subdirectories:
catalina -- The 2.3-compatible servlet container
jasper -- The 1.2-compatible JSP container
webapps -- The 2.3/1.2 compatible example applications
Each of these three top level subdirectories contains completely independent
build scripts, so you can build what you want and use it separately. So, for
example, you can build a servlet container with no JSP engine by just going
into the catalina directory and doing a "build dist". Likewise, the "jasper"
directory's "build dist" will create a JSP engine you can take anywhere that
is 2.3/1.2 compatible.
There are also convenience scripts at the top level directory that combine
everything to create the combination of features that make up Tomcat as a
whole (servlet container + JSP engine + example webapps). But you are
welcome to pick and choose the pieces you want independently.
>
> Remember, we want Jasper to work with any servlet engine, including
> Tomcat 3, and including other Servlet 2.2 containers.
>
There are two gotchas to this portability goal:
* The new Jasper code requires Servlet 2.3 and JSP 1.2 support, so it
won't run on 2.2 containers.
* Although there are zero code dependencies between Jasper and Catalina,
there is a dependency on setting a servlet context attribute correctly to
pass the webapp classpath to the Jasper servlet. This same dependency
(plus some code dependencies) is currently present in Tomcat 3.x.
However, Jasper should run fine on any 2.3 container that is hacked to set
the right context attributes. And Jon is free to package Catalina (without
Jasper) with any page template language he wants :-).
>
> - Alex
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Jasper Changes
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Alex Chaffee wrote:
>
> Are these Jasper changes (new features / bug fixes / JSP 1.2
> additions) going to be rolled back into the Tomcat 3 Jasper source?
>
> If not, then I think it's time to spin Jasper off as a separate
> project, or at least a separate top-level subdirectory under
> jakarta-tomcat. Then both Tomcat and Catalina will have to change
> their build process to include it.
>
> Remember, we want Jasper to work with any servlet engine, including
> Tomcat 3, and including other Servlet 2.2 containers.
+1
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Jasper Changes
Posted by cm...@yahoo.com.
+1
> Are these Jasper changes (new features / bug fixes / JSP 1.2
> additions) going to be rolled back into the Tomcat 3 Jasper source?
For 3.2 - I hope not.
For 3.3 - we can just use jasper 1.2 ( with the 2.3 facade ), and keep
the old 1.1 code with the 2.2 facade.
( and make clear that only critical bugs will be fixed in the 1.1/2.2
pair )
Building will be a bit tricky, but I think we can handle that.
Costin
Re: Jasper Changes
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/21/2000 11:01 AM, "Alex Chaffee" <gu...@edamame.stinky.com> wrote:
> Are these Jasper changes (new features / bug fixes / JSP 1.2
> additions) going to be rolled back into the Tomcat 3 Jasper source?
>
> If not, then I think it's time to spin Jasper off as a separate
> project, or at least a separate top-level subdirectory under
> jakarta-tomcat. Then both Tomcat and Catalina will have to change
> their build process to include it.
>
> Remember, we want Jasper to work with any servlet engine, including
> Tomcat 3, and including other Servlet 2.2 containers.
>
> - Alex
+1
How long have I been asking for this? :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/