You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Roth <ma...@sun.com> on 2002/10/05 01:43:55 UTC
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
jsp-spec-comments@eng.sun.com.
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
jsp-spec-comments@eng.sun.com, or, maybe better in this case, talk
directly to the Apache representatives to the Expert Group: Ricardo
Rocha (ricardo@apache.org) and Geir Magnusson Jr. (geirm@apache.org).
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
My opinion is that being cross platform (IBM VM, JRockit (BEA), etc.) is
very important and making it required using Sun VM (1.4) is not a good idea.
Until there are other VMs that are 1.4, there must be a workaround (add
these JARs to make 1.3 work).
.V
Mark Roth wrote:
> 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
> jsp-spec-comments@eng.sun.com.
>
> 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
> jsp-spec-comments@eng.sun.com, or, maybe better in this case, talk
> directly to the Apache representatives to the Expert Group: Ricardo
> Rocha (ricardo@apache.org) and Geir Magnusson Jr. (geirm@apache.org). 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,
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Steve Downey <st...@netfolio.com>.
The spec defines a conforming JSP 2.0 implementation as one that runs on JDK
1.4. A JSP author may therefore assume the new API's are available when
creating their webapp. It's a serious issue for, say, Oracle, or IBM, who has
a custom Java VM.
But, I hadn't noticed that Apache is bundling JDK's with Tomcat. To assemble a
conforming platform, a JDK 1.4 must be provided. If you use a 1.3 level JDK,
then the conformance test would, presumeably, fail. And some conforming JSP
pages that rely on new APIs wouldn't work.
I don't see any requirement that a random JSP 2.0 page absolutely not run on
JDK 1.2 or 1.3. It's simply out of scope for the spec.
It comes down to what JDK level Jakarta wants to support. Tomcat 5.0 MUST run
on JDK 1.4. Allowing it to run on JDK 1.3 or 1.2 should not hinder that.
On Monday 07 October 2002 04:50 pm, Remy Maucherat wrote:
> Costin Manolache wrote:
> > 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.
>
> Personally, I would support 1.3 (and 1.2 assuming you are willing to
> download missing libraries). 1.4 brings I/O improvements so it's a nice
> JDK choice, even if the nio API itself seems useless for Tomcat.
>
> I have no problem with including Velocity if people want it. As for
> Cocoon, it is huge, so this looks like a bad idea.
>
> If you're interested in the issue, you should make a proper call for vote.
>
> Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JSP 2.0's J2SE 1.4 Requirement
Posted by IAS <to...@iasandcb.pe.kr>.
Catalina 2.4(assumed) Standalone could work with JSF very well and light
as well.
For example,
JSF 1.0
---------------
Struts 1.1
----------------
Catalina 2.4 (<- also known as Tomcat 5 servlet container)
IAS
Indepedent Java Technology Evangelist
http://www.iasandcb.pe.kr
Jakarta Seoul Project Coordinator
http://jakarta.apache-korea.org
-----Original Message-----
From: jean-frederic clere [mailto:jfrederic.clere@fujitsu-siemens.com]
Sent: Tuesday, October 08, 2002 7:15 PM
To: Tomcat Developers List
Subject: Re: JSP 2.0's J2SE 1.4 Requirement
Henri Gomez wrote:
> Costin Manolache wrote:
>
>> 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.
>
>
> +1 here .
>
> If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or
> 4.1.x on my Linux and iSeries productions boxes.
>
> Could we imagine alternatives ?
>
> - Tomcat 5 using Serlvet 2.3/JSP 1.2 ?
>
> - Tomcat 5 using Servlet 2.4 and JSP 1.2 ?
>
> - Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0
> depending the JVM found at runtime ?
>
> - Tomcat 5 bundled without JSP 2.0 ?
>
> - Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ?
>
> I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0)
> will delay for a long time its adoption by companies, until all
> platform got JDK 1.4, which means for example that people which use
> IBM SDK on Linux or mainframes systems will have to wait up to the end
> of year ad minima.
As I will probably have to deliver JSP 2.0 with the next Tomcat I would
prefer
that JSP 2.0 only requires JDK 1.3.
But I like the idea of having a modular Tomcat.
So Tomcat 5 bundled without JSP 2.0 but with ready for adding adding
JSP,
velocity or whatever sounds great.
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Costin Manolache wrote:
>
>> 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.
>
>
> +1 here .
>
> If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or
> 4.1.x on my Linux and iSeries productions boxes.
>
> Could we imagine alternatives ?
>
> - Tomcat 5 using Serlvet 2.3/JSP 1.2 ?
>
> - Tomcat 5 using Servlet 2.4 and JSP 1.2 ?
>
> - Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0
> depending the JVM found at runtime ?
>
> - Tomcat 5 bundled without JSP 2.0 ?
>
> - Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ?
>
> I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0)
> will delay for a long time its adoption by companies, until all
> platform got JDK 1.4, which means for example that people which
> use IBM SDK on Linux or mainframes systems will have to wait up
> to the end of year ad minima.
As I will probably have to deliver JSP 2.0 with the next Tomcat I would prefer
that JSP 2.0 only requires JDK 1.3.
But I like the idea of having a modular Tomcat.
So Tomcat 5 bundled without JSP 2.0 but with ready for adding adding JSP,
velocity or whatever sounds great.
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tomcat 4.1.12 rpm release 2 uploaded
Posted by Henri Gomez <hg...@apache.org>.
A quick note to warn rpms users that rpm release 2 of tomcat 4.1.12
has been released and fix :
- fix tomcat4.conf to use /etc/java/java.conf
- fix tomcat4 initd to be sure that we'll stop/start the task owner by
TOMCAT_USER and running catalina
- fix perms on /etc/tomcat4, contents is owned by root.tomcat4, and only
jk2.properties and tomcat-users.xml could be updated by tomcat4 user.
- change ref and use of xerces-j2.jar by jaxp_parser_impl.jar.
- include ant 1.5.1
- remove commons-lang as no more required
- copy a correct mod_jk.jpeg
Regards
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tomcat 4.1.12 rpm release 2 uploaded
Posted by Henri Gomez <hg...@apache.org>.
A quick note to warn rpms users that rpm release 2 of tomcat 4.1.12
has been released and fix :
- fix tomcat4.conf to use /etc/java/java.conf
- fix tomcat4 initd to be sure that we'll stop/start the task owner by
TOMCAT_USER and running catalina
- fix perms on /etc/tomcat4, contents is owned by root.tomcat4, and only
jk2.properties and tomcat-users.xml could be updated by tomcat4 user.
- change ref and use of xerces-j2.jar by jaxp_parser_impl.jar.
- include ant 1.5.1
- remove commons-lang as no more required
- copy a correct mod_jk.jpeg
Regards
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JSP 2.0's J2SE 1.4 Requirement
Posted by IAS <to...@iasandcb.pe.kr>.
Assuming Tomcat subproject plan, Tomcat 5 basically consists of Catalina
2.4, Jasper 2.0, and it requires JDK 1.4 according to JSP 2.0 PFD.
However, you still have choices laying stacks as you want for your
mission.
any possible Jasper (or even none)
-------------------------------------------------- --> mandates only
common JDK requirement.
any possible Catalina (necessary)
IAS
Indepedent Java Technology Evangelist
http://www.iasandcb.pe.kr
Jakarta Seoul Project Coordinator
http://jakarta.apache-korea.org
-----Original Message-----
From: Henri Gomez [mailto:hgomez@apache.org]
Sent: Tuesday, October 08, 2002 5:20 PM
To: Tomcat Developers List
Subject: Re: JSP 2.0's J2SE 1.4 Requirement
Costin Manolache wrote:
> 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.
+1 here .
If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or
4.1.x on my Linux and iSeries productions boxes.
Could we imagine alternatives ?
- Tomcat 5 using Serlvet 2.3/JSP 1.2 ?
- Tomcat 5 using Servlet 2.4 and JSP 1.2 ?
- Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0
depending the JVM found at runtime ?
- Tomcat 5 bundled without JSP 2.0 ?
- Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ?
I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0) will
delay for a long time its adoption by companies, until all platform got
JDK 1.4, which means for example that people which use IBM SDK on Linux
or mainframes systems will have to wait up to the end of year ad minima.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> 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.
+1 here .
If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or
4.1.x on my Linux and iSeries productions boxes.
Could we imagine alternatives ?
- Tomcat 5 using Serlvet 2.3/JSP 1.2 ?
- Tomcat 5 using Servlet 2.4 and JSP 1.2 ?
- Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0
depending the JVM found at runtime ?
- Tomcat 5 bundled without JSP 2.0 ?
- Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ?
I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0)
will delay for a long time its adoption by companies, until all
platform got JDK 1.4, which means for example that people which
use IBM SDK on Linux or mainframes systems will have to wait up
to the end of year ad minima.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Jean-Francois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>Remy Maucherat wrote:
>
>
>
>>>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.
>>>
>>>
>>Personally, I would support 1.3 (and 1.2 assuming you are willing to
>>download missing libraries). 1.4 brings I/O improvements so it's a nice
>>JDK choice, even if the nio API itself seems useless for Tomcat.
>>
+1... I think 1.3 is available on several platforms. From a previous
email send last week, I re-call there were only 2 classes that do not
compile on 1.2. We should consider supporting 1.2 as well if it's
true....We can always optimize/abstract the code to use the stength of
the target platform (like NIO).
>>
>>
>
>I'm fine with using any API in JDK1.4 that we need - but not with
>_requiring_ JDK1.4. We can easily detect JDK1.4 and enable NIO for that
>case, or anything else that would help up.
>
>I'm obviously -1 on using jdk1.4 regexp or logging API or any 'boundled'
>feature that can't be used in plain Java2 ( especially when we have
>better alternatives that work with any java).
>
>
>
>>I have no problem with including Velocity if people want it. As for
>>Cocoon, it is huge, so this looks like a bad idea.
>>
Just by curiosity, which JDK version are they supporting?
>>
>>
>
>If we can't include JSP2.0 for JDK1.2 and JDK1.3 ( and more important for
>me - for GCJ and Kaffe and open source VMs ) - then we should include
>some alternative. We could include JSP1.2, but I doubt we're allowed to
>do so by licence.
>
>The 'default' tomcat release ( in case JSP2 remains with JDK1.4 requirement)
>will obviously continue to be the same. What I'm interested is what we'll
>do for the 'tomcat for java2' release.
>
>
>
>>If you're interested in the issue, you should make a proper call for vote.
>>
+1 The JSP 2.0 spec is not final, so we have time to ask for a change.
-- Jeanfrancois
>>
>>
>
>I'm interested in having tomcat and java-based webapps on most platforms. I
>would prefer to have JSP - and I'm more interested in having this
>requirement fixed. But if it stops beeing an option, then we need
>alternatives.
>
>
>If I would care more about features and less about portability, then I could
>write C# and use windows.
>
>
>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> 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.
>
> Personally, I would support 1.3 (and 1.2 assuming you are willing to
> download missing libraries). 1.4 brings I/O improvements so it's a nice
> JDK choice, even if the nio API itself seems useless for Tomcat.
I'm fine with using any API in JDK1.4 that we need - but not with
_requiring_ JDK1.4. We can easily detect JDK1.4 and enable NIO for that
case, or anything else that would help up.
I'm obviously -1 on using jdk1.4 regexp or logging API or any 'boundled'
feature that can't be used in plain Java2 ( especially when we have
better alternatives that work with any java).
> I have no problem with including Velocity if people want it. As for
> Cocoon, it is huge, so this looks like a bad idea.
If we can't include JSP2.0 for JDK1.2 and JDK1.3 ( and more important for
me - for GCJ and Kaffe and open source VMs ) - then we should include
some alternative. We could include JSP1.2, but I doubt we're allowed to
do so by licence.
The 'default' tomcat release ( in case JSP2 remains with JDK1.4 requirement)
will obviously continue to be the same. What I'm interested is what we'll
do for the 'tomcat for java2' release.
> If you're interested in the issue, you should make a proper call for vote.
I'm interested in having tomcat and java-based webapps on most platforms. I
would prefer to have JSP - and I'm more interested in having this
requirement fixed. But if it stops beeing an option, then we need
alternatives.
If I would care more about features and less about portability, then I could
write C# and use windows.
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> 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.
Personally, I would support 1.3 (and 1.2 assuming you are willing to
download missing libraries). 1.4 brings I/O improvements so it's a nice
JDK choice, even if the nio API itself seems useless for Tomcat.
I have no problem with including Velocity if people want it. As for
Cocoon, it is huge, so this looks like a bad idea.
If you're interested in the issue, you should make a proper call for vote.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JSP 2.0's J2SE 1.4 Requirement
Posted by Costin Manolache <cm...@yahoo.com>.
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:mark.roth@sun.com]
> Sent: Saturday, October 05, 2002 8:44 AM
> To: tomcat-dev@jakarta.apache.org
> 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
> jsp-spec-comments@eng.sun.com.
>
> 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
> jsp-spec-comments@eng.sun.com, or, maybe better in this case, talk
> directly to the Apache representatives to the Expert Group: Ricardo
> Rocha (ricardo@apache.org) and Geir Magnusson Jr. (geirm@apache.org).
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSP 2.0's J2SE 1.4 Requirement
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 5/10/02 12:43 am, "Mark Roth" <ma...@sun.com> wrote:
> 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.
Great... One more reason to start thinking about kicking JSP out of the
door! :-) I'm not going to run 1.4 in production for quite some time :-)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JSP 2.0's J2SE 1.4 Requirement
Posted by iasandcb <ia...@hotmail.com>.
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:mark.roth@sun.com]
Sent: Saturday, October 05, 2002 8:44 AM
To: tomcat-dev@jakarta.apache.org
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
jsp-spec-comments@eng.sun.com.
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
jsp-spec-comments@eng.sun.com, or, maybe better in this case, talk
directly to the Apache representatives to the Expert Group: Ricardo
Rocha (ricardo@apache.org) and Geir Magnusson Jr. (geirm@apache.org).
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need some clarifications
Posted by iasandcb <ia...@hotmail.com>.
In order to thank you for your kind explanation, I'd like to share my
TC5 pre-build and post-build result and some updated tips .(Notice: The
following processes are wholly up to 7 Oct. 2002.)
Test Build Environment:
IBM ThinkPad R32
Windows XP
JDK 1.4.1
Ant 1.5.1
WinCVS 1.3b8(dos command cvs is based on cvs 1.11)
Python 2.2.1
First, we need to modify jakart-tomcat-5's build.properties as followed.
1. Since there's no LogKit-1.0.1 in latest directory,
# ----- LogKit -----
logkit.home=${base.path}/LogKit-1.1
logkit.lib=${logkit.home} logkit.jar=${logkit.lib}/logkit-1.1.jar
logkit.loc=http://jakarta.apache.org/builds/jakarta-
avalon/release/logkit/latest/LogKit-1.1-bin.tar.gz
2. There's brand-new Java Mail and JAF libraries now, so I downloaded
and copied them instead of previously specified versions. (Make
javamail-1.3 and jaf-1.0.2 directories and copy the specified jar files
to there respectively.)
# ----- Java Mail, version 1.2 or later -----
mail.home=${base.path}/javamail-1.3
mail.lib=${mail.home}
mail.jar=${mail.lib}/mailapi.jar
# ----- Java Activation Framework (JAF), version 1.0.1 or later -----
activation.home=${base.path}/jaf-1.0.2
activation.lib=${activation.home}
activation.jar=${activation.lib}/activation.jar
3. This is optional, however, I prefer JDK 1.4 version.
#Build lightweight JDK 1.4 distribution
light.dist=on
Next, we are on the step of build stage. Unfortunately, there's no
"build" target in tomcat 5 ant build.xml. Instead, we can do "ant dist"
after "ant download". Actually it emitted quite many warnings including
deprecations and absences of libraries, but successfully completed.
I put some built distribution(zip format) here:
http://www.iasandcb.pe.kr/starbucks/special/jakarta-tomcat-5.0-ias-
build.zip
I've not tested fully enough, but tomcat startup shell displayed like
this:
2002. 10. 7. 오후 1:44:26 org.apache.commons.modeler.Registry
loadRegistry
정보: Loading registry information
2002. 10. 7. 오후 1:44:26 org.apache.commons.modeler.Registry
getRegistry
정보: Creating new Registry instance
2002. 10. 7. 오후 1:44:26 org.apache.commons.modeler.Registry getServer
정보: Creating MBeanServer
2002. 10. 7. 오후 1:44:28 org.apache.coyote.http11.Http11Protocol init
정보: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/5.0
2002. 10. 7. 오후 1:44:30 org.apache.catalina.startup.ContextConfig
tldScan
정보: Processed tld jar /WEB-INF/lib/struts.jar 261
2002. 10. 7. 오후 1:44:30 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
정보: Configured an authenticator for method FORM
2002. 10. 7. 오후 1:44:39 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
정보: Configured an authenticator for method BASIC
2002. 10. 7. 오후 1:44:41 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
정보: Configured an authenticator for method FORM
2002. 10. 7. 오후 1:44:42 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
정보: Configured an authenticator for method FORM
2002. 10. 7. 오후 1:44:42 org.apache.coyote.http11.Http11Protocol start
정보: Starting Coyote HTTP/1.1 on port 8080
2002. 10. 7. 오후 1:44:42 org.apache.jk.common.ChannelSocket init
정보: JK2: ajp13 listening on tcp port 8009
2002. 10. 7. 오후 1:44:42 org.apache.jk.server.JkMain start
정보: Jk running ID=0 time=10/30 config=C:\java\jakarta\cvs\jakarta-
tomcat-5\di
st\bin\..\conf\jk2.properties
(Sorry for some broken characters. They are Korean.)
The built Tomcat 5 examples with EL-based JSP 2 style works fine.
I wish all the Tomcat players and spectators good luck with version 5.
IAS
Independent Java Technical Evangelist
http://www.iasandcb.pe.kr
--------------------
From: Steve Downey
Subject: Re: Need some clarifications
Date: Wed, 02 Oct 2002 10:54:53 -0700
On Wednesday 02 October 2002 09:38 am, Christian Gross wrote:
> Hi
>
> So I worked myself through the various CVS sources and have a couple
of
> "official" position questions to ask.
>
> The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper,
will be
> forming the Tomcat 5 work?
jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina,
jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-
4.0
are the CVS repositories involved in Tomcat 5.0
>
> The CVS project jakarta-tomcat-4.0 is the 4.x branch?
>
Yes
> The CVS project jakarta-tomcat is anything before 4.0
>
Tomcat 3.x, at least.
> The CVS project jakarta-tomcat-5.0 does nothing??????
>
It's the master project for the whole Tomcat 5.0 project. To use it,
start
with a directory like tc5-workspace. In that directory:
export CVSROOT=:pserver:anoncvs@cvs.apache.org:/home/cvspublic
cvs co jakarta-servletapi-5
cvs co jakarta-tomcat-5
cvs co jakarta-tomcat-catalina
cvs co jakarta-tomcat-connectors
cvs co jakarta-tomcat-jasper
then, in jakarta-tomcat-5 create a build.properties file with the
following
definition
base.path = /home/sdowney/tc5-workspace/depends
(replace /home/sdowney/tc5-workspace with path to your workspace. I
don't know
if relative will work. I stopped dinking when I got my build system to
function)
You need ant 1.5 to build Tomcat 5
export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5
PATH=$PATH:$ANT_HOME/bin
ant download
The download target in Tomcat 5 gets the necessary ancillary libraries
to
build the system. I'm using JDK 1.4, which has a few things built in.
You may
need to install some things in JDK 1.3, like JCE. I'm not sure.
Then:
ant build
ant test
[Not many tests at the moment]
If you're contributing, you may also want to do
ant -Dfull.dist=on build
That will force a full compile, rather than checking which optional
components
are available and setting things on or off based on the presense or
absense
of classes. That useful for building a customized version, but for
testing
purposes, a full build is better.
To run the watchdog conformance test suite:
ant watchdog
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>