Overall, JAXP is a very painful thing to those deploying any intensive
XML or XSLT that might care what implementation is used and not having
the luxury of dictating this implementation to everything else in the
JVM. For instance, JAXP requires a separate classloader to change the
XML or XSLT
Jeanfrancois Arcand wrote:
[back from vacation :-)]
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in
Tomcat
5.1? Since we're gearing
[back from vacation :-)]
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might
Costin Manolache wrote:
- jdk1.3 - it'll work if you add your own parser in common/lib or
jre/lib/ext or classpath
- jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema
validation might fail, everything else should work.
- jdk1.5 - AFAIK everything should work.
The reason
Jeanfrancois Arcand wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
We are using it also and it is very helpful.
It is one of the standard product features of a container to be able to
seperate container product installation from runtime instance specific
files.
It works very nicely with tomcat. We can even allow instance admins to
extend TC by changing to an
Hola,
OK, feedback well put. Thanks,
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Rainer Jung [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 4:10 AM
To: Tomcat Developers List
Subject: Re: Tomcat 5.0.28 release
We are using it also and it is very
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
Hola,
I must say I don't fully understand the above. So what exactly will
happen if the common/endorsed directory is removed? What will stop
working and on which platform(s)? Are there any specific pointers to
bug
ids or discussions, that would explain why the endorsed directory was
added in the
Petr Jiricka wrote:
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to
To clarify: I wasn't proposing to remove the separate product
installation and runtime, but the contrary - to make that the default.
Right now tomcat operates in 2 modes - one where CATALINA_HOME is
identical with CATALINA_BASE, and one where you have them separate (
like you use ).
I think it
Costin Manolache wrote:
If you remove common/endorsed:
- jdk1.3 - it'll work if you add your own parser in common/lib or
jre/lib/ext or classpath
- jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema
validation might fail, everything else should work.
- jdk1.5 - AFAIK everything
FYI - progress on the 5.0.28 changes:
Petr Jiricka wrote:
- The Sun Developer Tools group would like to include into this
release several bug fixes in the Jasper area, that are currently
available in the trunk (5.1.x codebase), and that affect NetBeans 4.0
functionality, such as JSP debugging
How about stopping support for that scenario? I mean drop
the CATALINA_BASE versus CATALINA_HOME feature, (or set them
to always equal each other, if we want to leave them in the
code base), and don't allow users to share installations
except by the user home directory valve.
I am
I'm sorry, but can't remember - why do we still need the endorsed ?
I tought they were a temporary solution for JDK1.4 and some validation
problems - tomcat should work fine with any SAX/DOM parser, including
the one in JDK1.4.
The only problem is JDK1.3 - and I agree that it would be better to
Informatics
Petr
-Original Message-
From: Petr Jiricka [mailto:[EMAIL PROTECTED]
Sent: Monday, August 09, 2004 12:43 PM
To: [EMAIL PROTECTED]
Subject: Tomcat 5.0.28 release
Hi,
we have been using Tomcat in the NetBeans product for about 4 years now
(since the 3.2 beta releases), so first
Remy Maucherat wrote:
Petr Jiricka wrote:
- Continue to deliver a stable release of Tomcat in roughly 1 month
intervals. One of the reasons why Tomcat is so highly valued in the
community is because the time between finding a bug and deliveing the
fix is very short, thanks to the short release
Costin Manolache wrote:
I'm sorry, but can't remember - why do we still need the endorsed ?
I tought they were a temporary solution for JDK1.4 and some validation
problems - tomcat should work fine with any SAX/DOM parser, including
the one in JDK1.4.
This would be good, if it's indeed
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum. I'm +0.5 on this.
As for the nature of
I for one use the CATALINA_BASE vs CATALINA_HOME
Mitchell Marx
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 8:53 AM
To: Tomcat Developers List
Subject: RE: Tomcat 5.0.28 release
Hi,
I have a couple of only-slightly-related comments
I would have to agree with the gentlemen from Sun and NetBeans that it
is preferable to have a standard stable version bundled with other
products as opposed to some other file set which one cannot
independently reproduce.
Why?
Users of NetBeans, etc, would like to know that they can reproduce
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum. I'm +0.5 on this.
Hola,
I'm using JDK1.3 most of the time, and I think a lot of other people
and
companies are still using it. I don't mind having the default
distribution built for 1.4+ ( no xerces ), with instructions on how to
get the additional jars for 1.3. But I think it would be very bad to
not
be able to
Hi,
we have been using Tomcat in the NetBeans product for about 4 years now
(since the 3.2 beta releases), so first off, Thanks! for all your great
work. Tomcat provides NetBeans users with the ability to run their
applications out of the box, debug in on the Java and JSP level, and
generally
]
Sent: Monday, August 09, 2004 12:43 PM
To: [EMAIL PROTECTED]
Subject: Tomcat 5.0.28 release
Hi,
we have been using Tomcat in the NetBeans product for about 4 years now
(since the 3.2 beta releases), so first off, Thanks! for all your great
work. Tomcat provides NetBeans users with the ability
, 2004 1:05 PM
To: Tomcat Developers List
Subject: RE: Tomcat 5.0.28 release
Hi,
A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm
not gung-ho about making significant Tomcat 5.0 additions and
enhancements, given the advanced state of Tomcat 5.1 development. If
there's
Petr Jiricka wrote:
- Continue to deliver a stable release of Tomcat in roughly 1 month
intervals. One of the reasons why Tomcat is so highly valued in the
community is because the time between finding a bug and deliveing the
fix is very short, thanks to the short release cycles. The community
Didn't we already try that with the tomcat 4 LE edition?
-Tim
Remy Maucherat wrote:
My current idea for the new branch is to ship a JDK 1.5 bundle with a
separate zip/tar.gz to easily install the additional binaries when using
JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher
28 matches
Mail list logo