Now it's almost clear that SRV 2.4 requires JDK 1.2 and JSP 2.0 does JDK
1.4. The main issue is discrepancy of J2SE requirement between SRV 2.4
and JSP 2.0, which are supposed to come up together.
At this point, I'd like to propose an idea. It's "Tomcat subprojects"
plan.
So far, Tomcat has had always SRV container and JSP engine(compiler and
runtime), and there has been no problem about their co-existence.
However, the relationship should be changed somehow because SRV is
considered stable and settled and JSP growing and immature.
My main idea is seperation between SRV container and JSP engine.
Actually from Tomcat 4, we have distinguished catalina(SRV part) from
jasper(JSP part). However, it was not outer-distribution level but
inner-development level.
I suggest the following table:
Catalina 2.4 - Servlet 2.4 - JDK 1.2
Jasper 2.0 - JSP 2.0 - JDK 1.4
Connectors - Coyote, JK2
Add-ons - JDBC SE, NIO Accelaration, Administration, Manager
Basically, catalina and jasper have the same major.minor version with
related technologies. For example, if somebody have catalina
2.3.1distribution, them he or she can make use of SRV 2.3.
Another important feature of these distributions is "independency". For
example, you are able to run a servlet just with catalina servlet
container. If you want to use SRV 2.4, you will choose catalina 2.4.x.
In this case, you don't need JDK 1.4 as JSP 2.0-compliant engine is not
related at all.
This independency also can bring new possibility toward lightness and
harmony with other dynamic page generation technologies such as Tea, or
template engines like Velocity. If someone want to use not JSP but
alternative paging script, catalina servlet container is sufficient and
necessary for that purpose.
However, the key feature is "free-combination". If a developer likes to
utilize SRV 2.4 on JDK 1.2 or 1.3 (call those versions "Java 2 classic"
later), he or she can do so by electing catalina 2.4 and avoiding jasper
2.0 at the same time. For instance, imagine catalina 2.4 + jasper 1.2
under JDK 1.3.
Maybe there are some worrying about disabilities to use JSP 2.0, but we
have JSTL and JSF for compensation. JSTL supports EL that JSP 2.0 also
provids. JSF requires JSP 1.2(and SRV 2.3), so we will be happy with
them.
Let's see some different impact from this architecture: Still we can
release integraed Tomcat distribution that consists of catalina, jasper,
connectors, and add-ons. For example, Tomcat 5 contains catalina 2.4,
jasper 2.0, some connectors, and several extras. In that case, Tomcat 5
definitely requires JDK 1.4(call that version "Java 2 modern" later). As
we already knew, Windows-Intel, Solaris-Intel-or-Sparc, and Linux-Intel
are considerable majority of Java Platform Infrastructure for both
production and service. Tomcat 5 stands for a start to a new era of Java
web application development and deployment.
While Tomcat 5 empowers JSP 2 style with great ease, obviously there
should be some who need web containers running with Java 2 classic. For
their convenience and survival, catalina 2.4 and jasper 1.2 are ready.
They are unable to get what JSP 2 style gives, but still do enjoy SRV
2.4's enhanced features and JSTL-JSF ensemble with JSP 1.2 under Java 2
classic platform.
This architecture helps Tomcat-involved developers too. Now Tomcat has
so many subpackages, so it's very hard to keep track of all of them and
even build it without conflict. Historically Tomcat was a servlet
container. Since JSP technology was born, it has been taken for granted
that Tomcat should support JSP as well. Now it is about time for SRV and
JSP to go their own way respectively. Moreover, Tomcat has been
providing a lot of optional features for users' sake. DB Connection
Pooling and useful web applications such as adminstration and manager
are some of them. Notwithstanding the merit, they are actually optional
and distinct. Instead of packaging all the presents, we can develop and
release each package indepedently and give full guidance to deploy and
undeploy them on catalina. Choices are up to users, who are supposed to
be capable of manipulating.
Let me tell you some scenarios: A is a beginner, and feel like making
and running servlets and JSP pages with MySQL DB. Absolutely A's choice
is Tomcat 5 integrated distribution(all-in-one type). On the other hand,
B is a skillful Java web developers, and wants his web container to work
standalone as light and fast as possible. B's choice is catalina 2.4 +
jasper 2.0 + Coyote + NIO acceleration add-on because B may not need
additional connectors or extra web applications.
Structure
jasper(JSP engine) | Add-on | Add-on | ... | some other engine |....
<- every pluggable component is
------------------------------------------------------------------------
-------------- downloadable and deployable.
catalina(SRV Container)
In short, Tomcat subprojects will be like this:
catalina [servlet container] : 2.2, 2.3, 2.4 (Java 2 classic)
jasper [jsp engine] : 1.1, 1.2 (Java 2 classic), 2.0 (Java 2 modern)
connectos : Coyote, JK2, ...
add-ons: JDBC SE guidance(only documents can be OK), administration,
manager, ...
and finally
Tomcat [fully-equipped web container] : 3.x, 4.x (Java 2 classic), 5.x
(Java 2 modern)
Once again, the motto of the idea is "freedom of choice" and "economy of
collaboration".
IAS
Independent Java Technology Evangelist
http://www.iasandcb.pe.kr
-----Original Message-----
From: Mark Roth [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 05, 2002 8:44 AM
To: [EMAIL PROTECTED]
Subject: JSP 2.0's J2SE 1.4 Requirement
It has been brought to my attention that some members of the Tomcat
community have expressed a desire to see a requirement lower than J2SE
1.4 in JSP 2.0.
First, let me reassure you that the JSP 2.0 specification is not final.
Actually, we are in Proposed Final Draft phase, and we are explicitly
soliciting feedback! Early feedback is always much appreciated. As per
the cover of the specification, the appropriate forum for feedback is
[EMAIL PROTECTED]
Regarding the J2SE 1.4 requirement, the expert group discussed the topic
in early August (as issue "[OTH-17] J2SE Version Requirement") and there
was concensus from the different experts, but the EG is open to
additional comments. You can send mail directly to
[EMAIL PROTECTED], or, maybe better in this case, talk
directly to the Apache representatives to the Expert Group: Ricardo
Rocha ([EMAIL PROTECTED]) and Geir Magnusson Jr. ([EMAIL PROTECTED]).
In general the more feedback the rep has from his community the better
for the Expert Group.
For what it's worth, the only technical reasons we require J2SE 1.4 are:
1. We require support for JSR-45 (Debugging Support for Other
Languages)
2. We declare support for Unicode 3.0 in our I18N chapter.
Actually, JSR-45 is quite important for the platform as a whole. For
example, it was recently pointed out to me that there's a bug report
against Tomcat 5 because we didn't re-implement the pseudo-debug
comments that Jasper 1 used to create, and that some tools relied on.
Standard debugging annotations is an important enabler, and it would be
a shame to have to wait even longer for it.
From my perspective, the most significant reason to require J2SE 1.4 is
that it would be best if people can write portable tag handlers that
utilize J2SE 1.4 libraries, and be able to use them in any JSP 2.0
application. Do we really want to stagnate on J2SE 1.2 APIs forever?
I've compiled a list of new features in J2SE 1.3 and J2SE 1.4 that I
believe would be of use to page authors and tag library developers that
would decide to use JSP 2.0. It would be awesome, IMHO, if page authors
and tag library developers could rely on these features being present in
any JSP 2.0 compliant container. This list was also discussed in the
Expert Group.
J2SE 1.3 adds (among other features):
* Built-in JNDI
* RMI/IIOP
* CORBA ORB
* PNG support (for image taglibs)
* Various Security enhancements
* Improved socket support
* HTTP 1.1 client-side support
* DynamicProxy
* Serialization enhancements
* Collections enhancements
* BigDecimal and BigInteger enhancements
* StrictMath
* Timer API
* Delete-on-close mode for opening zip and jar files
* JPDA tool support
J2SE 1.4 adds (among other features):
* XML Processing
* New I/O APIs
* Security: Java Cryptography integrated
* Security: GSS-API, Certification Path API
* Pluggable Image I/O framework
* Print Service API
* Standard Logging APIs
* Long-term Persistence of JavaBeans
* JDBC 3.0
* Assertions
* Preferences API
* Chained Exception Facility
* IPv6 Networking Support
* JNDI enhancements
* CORBA ORB with POA
* *** JSR-45 (Debugging Support for Other Languages) ***
* *** Unicode 3.0 ***
* Currency class
* Collections Framework enhancements
* Built-in support for Regular Expressions
Regards,
--
Mark Roth, Java Software
JSP 2.0 Specification Co-Lead
Sun Microsystems, Inc.
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
