iasandcb wrote: > 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.
Actually, it isn't. All we know is that the current draft has this requirement. We should find a proper procedure ( for example a vote on tomcat dev ) and then ask our representative in JCP ( Geir for example - he's a very nice person ) to request a change. I don't know what's the proper mechanism yet - but Apache does have a representative and a vote, and we should have a way to have the opinion of tomcat-dev expressed. If the final JSP2.0 will require 1.4 - then we'll have to do that. It would be very unfortunate ( especially for jsp people ), and will require ( IMO ) a separate tomcat without JSPs. My opinion ( and it seems a lot of people have the same opinion ) that portability ( in the sense of beeing able to run on most OS and platforms ) seems to agree with what Apache is doing in most projects ( Apache server runs on more platforms than java - and did that even before 'write once, run everywhere'). We should first explore the alternative for having this opinion confirmed ( vote ? ) and expressed in the expert group. If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. Costin > > 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, -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
