You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christian Gross <ma...@devspace.com> on 2002/10/03 01:54:07 UTC
Is Compile Failure? was Re: Need some clarifications
Thanks for your answer. That helps quite a bit. Now I have another issue...
build-catalina:
[javac] Compiling 94 source files to
D:\Instructor\Projects\jakarta-tomcat-c
atalina\build\server\classes
[javac]
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol
[javac] symbol : method
setEntityResolver (org.apache.catalina.util.Schema
Resolver)
[javac] location: class org.apache.commons.digester.Digester
[javac] tldDigester.setEntityResolver(tldEntityResolver);
[javac] ^
[javac]
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol
[javac] symbol : method
setEntityResolver (org.apache.catalina.util.Schema
Resolver)
[javac] location: class org.apache.commons.digester.Digester
[javac] webDigester.setEntityResolver(webEntityResolver);
[javac] ^
[javac]
D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol
[javac] symbol : method setPublicId (java.lang.String)
[javac] location: class org.apache.commons.digester.Digester
[javac] digester.setPublicId(publicId);
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 3 errors
BUILD FAILED
file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801:
Comp
ile failed; see the compiler error output for details.
I checked out digester 1.3 and 1.2 and there does not seem to be a method
setEntityResolver. Or am I missing something?
Christian Gross
At 14:18 02/10/2002 -0400, you wrote:
>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>
Christian Gross
Software Engineering Consultant
http://www.devspace.com
North America: 1-450-675-4208
Europe +41.1.701.1166
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Steve Downey <st...@netfolio.com>.
Yes, just a blank line before the line indicated in the parsing exception. I
found this trying to move the line number, hoping to find the -- that
shouldn't be there. Putting blanks at the beginning of the file moved the
error line from 307 to 308:
SEVERE: Parse Fatal Error at line 307 column 39: The string "--" is not
permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.
to
SEVERE: Parse Fatal Error at line 308 column 39: The string "--" is not
permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.
So I went to line 306, added a /n and tried again. I was just trying to locate
the problem. And it vanished.
On Friday 04 October 2002 03:55 am, Henri Gomez wrote:
> Steve Downey wrote:
> > On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote:
> >>Steve Downey wrote:
> >>>Actually, with the recent release of commons-logging, we should be able
> >>>to get rid of the explicit LogKit and Log4J. They're there so as to get
> >>> a complete build of commons-logging. Tomcat 5 itself doesn't use either
> >>> directly.
> >>>
> >>>Xerces is a different issue. There was a bug that was preventing Tomcat
> >>>from migrating to the latest version. Unfortunately, I no longer
> >>> remember the details. Anyone know why we're using 2.1.0 instead of
> >>> 2.2.0?
> >>
> >> From what I experienced with Xerces j 2.2.0 it seems it does
> >>much more validity check and for instance found a '--' somewhere
> >>in comments (1 EUR to the first who find where).
> >>
> >>Previous version of Xerces or crimson didn't got that problem.
> >>
> >>if we could see which xml/dtd/tld is reported buggy, which
> >>will able to see if it's a bug or a features (ie a more strict
> >>check of xml rules)
> >
> > OK, from the 'this shouldn't work department', this patch 'fixes' the
> > problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd
> > ===================================================================
> > RCS file:
> > /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibra
> >ry_1_2.dtd,v retrieving revision 1.1.1.1
> > diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd
> > --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 13 Aug 2002
> > 16:20:58 -0000 1.1.1.1
> > +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 3 Oct 2002
> > 20:42:30 -0000
> > @@ -304,6 +304,7 @@
> > java.lang.String is default.
> >
> > declare Whether the variable is declared or not.
> > +
> > True is the default.
> >
> > scope The scope of the scripting varaible
> >
> >
> >
> > Something quite strange is going on.
>
> You just add an empty line in this dtd and it works now ?
>
> I was thinking it could be with ------ in some dtd, ie
> ---- line in web-app_2_3.dtd :
>
> <!--
> Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road,
> Palo Alto, CA 94303, U.S.A. All rights reserved.
>
> This product or document is protected by copyright and distributed
> under licenses restricting its use, copying, distribution, and
> decompilation. No part of this product or documentation may be
> reproduced in any form by any means without prior written authorization
> of Sun and its licensors, if any.
>
> Third party software, including font technology, is copyrighted and
> licensed from Sun suppliers.
>
> Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaServer Pages, Java
> Naming and Directory Interface, JDBC, JDK, JavaMail and Enterprise
> JavaBeans,
> are trademarks or registered trademarks of Sun Microsystems, Inc in the
> U.S. and other countries.
>
> All SPARC trademarks are used under license and are trademarks
> or registered trademarks of SPARC International, Inc.
> in the U.S. and other countries. Products bearing SPARC
> trademarks are based upon an architecture developed by Sun Microsystems,
> Inc.
>
> PostScript is a registered trademark of Adobe Systems, Inc.
>
> Federal Acquisitions: Commercial Software - Government Users Subject to
> Standard License Terms and Conditions.
>
> DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED
> CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
> IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
> PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT
> TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
> INVALID.
>
> _________________________________________________________________________
>
> Copyright 2000-2001 Sun Microsystems, Inc.,
> 901 San Antonio Road, Palo Alto, CA 94303, Etats-Unis.
> Tous droits re'serve's.
>
>
> Ce produit ou document est prote'ge' par un copyright et distribue' avec
> des licences qui en restreignent l'utilisation, la copie, la distribution,
> et la de'compilation. Aucune partie de ce produit ou de sa documentation
> associe'e ne peut e^tre reproduite sous aucune forme, par quelque moyen
> que ce soit, sans l'autorisation pre'alable et e'crite de Sun et de ses
> bailleurs de licence, s'il y en a.
>
> Le logiciel de'tenu par des tiers, et qui comprend la technologie
> relative aux polices de caracte`res, est prote'ge' par un copyright
> et licencie' par des fournisseurs de Sun.
>
> Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaServer Pages, Java
> Naming and Directory Interface, JDBC, JDK, JavaMail, et Enterprise
> JavaBeans,
> sont des marques de fabrique ou des marques de'pose'es de Sun
> Microsystems, Inc. aux Etats-Unis et dans d'autres pays.
>
> Toutes les marques SPARC sont utilise'es sous licence et sont
> des marques de fabrique ou des marques de'pose'es de SPARC
> International, Inc. aux Etats-Unis et dans
> d'autres pays. Les produits portant les marques SPARC sont
> base's sur une architecture de'veloppe'e par Sun Microsystems, Inc.
>
> Postcript est une marque enregistre'e d'Adobe Systems Inc.
>
> LA DOCUMENTATION EST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS,
> DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES,
> DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT
> TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L'APTITUDE
> A UNE UTILISATION PARTICULIERE OU A L'ABSENCE DE CONTREFACON.
> -->
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Han Ming Ong <ha...@apple.com>.
On Friday, October 4, 2002, at 12:55 AM, Henri Gomez wrote:
> Steve Downey wrote:
>> On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote:
>>> Steve Downey wrote:
>>>
>>>> Actually, with the recent release of commons-logging, we should be
>>>> able
>>>> to get rid of the explicit LogKit and Log4J. They're there so as to
>>>> get a
>>>> complete build of commons-logging. Tomcat 5 itself doesn't use
>>>> either
>>>> directly.
>>>>
>>>> Xerces is a different issue. There was a bug that was preventing
>>>> Tomcat
>>>> from migrating to the latest version. Unfortunately, I no longer
>>>> remember
>>>> the details. Anyone know why we're using 2.1.0 instead of 2.2.0?
>>>
>>> From what I experienced with Xerces j 2.2.0 it seems it does
>>> much more validity check and for instance found a '--' somewhere
>>> in comments (1 EUR to the first who find where).
>>>
>>> Previous version of Xerces or crimson didn't got that problem.
>>>
>>> if we could see which xml/dtd/tld is reported buggy, which
>>> will able to see if it's a bug or a features (ie a more strict
>>> check of xml rules)
>> OK, from the 'this shouldn't work department', this patch 'fixes' the
>> problem:
>> Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd
>> ===================================================================
>> RCS file:
>> /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-
>> jsptaglibrary_1_2.dtd,v
>> retrieving revision 1.1.1.1
>> diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd
>> --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 13 Aug 2002
>> 16:20:58 -0000 1.1.1.1
>> +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 3 Oct 2002
>> 20:42:30 -0000
>> @@ -304,6 +304,7 @@
>> java.lang.String is default.
>> declare Whether the variable is declared or not.
>> +
>> True is the default.
>> scope The scope of the scripting varaible
>> Something quite strange is going on.
>
> You just add an empty line in this dtd and it works now ?
>
> I was thinking it could be with ------ in some dtd, ie
> ---- line in web-app_2_3.dtd :
>
I checked that long line before. It's made up of underscores.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Henri Gomez <hg...@apache.org>.
Steve Downey wrote:
> On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote:
>
>>Steve Downey wrote:
>>
>>>Actually, with the recent release of commons-logging, we should be able
>>>to get rid of the explicit LogKit and Log4J. They're there so as to get a
>>>complete build of commons-logging. Tomcat 5 itself doesn't use either
>>>directly.
>>>
>>>Xerces is a different issue. There was a bug that was preventing Tomcat
>>>from migrating to the latest version. Unfortunately, I no longer remember
>>>the details. Anyone know why we're using 2.1.0 instead of 2.2.0?
>>
>> From what I experienced with Xerces j 2.2.0 it seems it does
>>much more validity check and for instance found a '--' somewhere
>>in comments (1 EUR to the first who find where).
>>
>>Previous version of Xerces or crimson didn't got that problem.
>>
>>if we could see which xml/dtd/tld is reported buggy, which
>>will able to see if it's a bug or a features (ie a more strict
>>check of xml rules)
>
> OK, from the 'this shouldn't work department', this patch 'fixes' the problem:
> Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd
> --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 13 Aug 2002 16:20:58
> -0000 1.1.1.1
> +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 3 Oct 2002 20:42:30
> -0000
> @@ -304,6 +304,7 @@
> java.lang.String is default.
>
> declare Whether the variable is declared or not.
> +
> True is the default.
>
> scope The scope of the scripting varaible
>
>
>
> Something quite strange is going on.
You just add an empty line in this dtd and it works now ?
I was thinking it could be with ------ in some dtd, ie
---- line in web-app_2_3.dtd :
<!--
Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road,
Palo Alto, CA 94303, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed
under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or documentation may be
reproduced in any form by any means without prior written authorization
of Sun and its licensors, if any.
Third party software, including font technology, is copyrighted and
licensed from Sun suppliers.
Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaServer Pages, Java
Naming and Directory Interface, JDBC, JDK, JavaMail and Enterprise
JavaBeans,
are trademarks or registered trademarks of Sun Microsystems, Inc in the U.S.
and other countries.
All SPARC trademarks are used under license and are trademarks
or registered trademarks of SPARC International, Inc.
in the U.S. and other countries. Products bearing SPARC
trademarks are based upon an architecture developed by Sun Microsystems,
Inc.
PostScript is a registered trademark of Adobe Systems, Inc.
Federal Acquisitions: Commercial Software - Government Users Subject to
Standard License Terms and Conditions.
DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED
CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT
TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID.
_________________________________________________________________________
Copyright 2000-2001 Sun Microsystems, Inc.,
901 San Antonio Road, Palo Alto, CA 94303, Etats-Unis.
Tous droits re'serve's.
Ce produit ou document est prote'ge' par un copyright et distribue' avec
des licences qui en restreignent l'utilisation, la copie, la distribution,
et la de'compilation. Aucune partie de ce produit ou de sa documentation
associe'e ne peut e^tre reproduite sous aucune forme, par quelque moyen
que ce soit, sans l'autorisation pre'alable et e'crite de Sun et de ses
bailleurs de licence, s'il y en a.
Le logiciel de'tenu par des tiers, et qui comprend la technologie
relative aux polices de caracte`res, est prote'ge' par un copyright
et licencie' par des fournisseurs de Sun.
Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaServer Pages, Java
Naming and Directory Interface, JDBC, JDK, JavaMail, et Enterprise
JavaBeans,
sont des marques de fabrique ou des marques de'pose'es de Sun
Microsystems, Inc. aux Etats-Unis et dans d'autres pays.
Toutes les marques SPARC sont utilise'es sous licence et sont
des marques de fabrique ou des marques de'pose'es de SPARC
International, Inc. aux Etats-Unis et dans
d'autres pays. Les produits portant les marques SPARC sont
base's sur une architecture de'veloppe'e par Sun Microsystems, Inc.
Postcript est une marque enregistre'e d'Adobe Systems Inc.
LA DOCUMENTATION EST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS,
DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES,
DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT
TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L'APTITUDE
A UNE UTILISATION PARTICULIERE OU A L'ABSENCE DE CONTREFACON.
-->
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Steve Downey <st...@netfolio.com>.
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote:
> Steve Downey wrote:
> > Actually, with the recent release of commons-logging, we should be able
> > to get rid of the explicit LogKit and Log4J. They're there so as to get a
> > complete build of commons-logging. Tomcat 5 itself doesn't use either
> > directly.
> >
> > Xerces is a different issue. There was a bug that was preventing Tomcat
> > from migrating to the latest version. Unfortunately, I no longer remember
> > the details. Anyone know why we're using 2.1.0 instead of 2.2.0?
>
> From what I experienced with Xerces j 2.2.0 it seems it does
> much more validity check and for instance found a '--' somewhere
> in comments (1 EUR to the first who find where).
>
> Previous version of Xerces or crimson didn't got that problem.
>
> if we could see which xml/dtd/tld is reported buggy, which
> will able to see if it's a bug or a features (ie a more strict
> check of xml rules)
OK, from the 'this shouldn't work department', this patch 'fixes' the problem:
Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd
===================================================================
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd
--- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 13 Aug 2002 16:20:58
-0000 1.1.1.1
+++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd 3 Oct 2002 20:42:30
-0000
@@ -304,6 +304,7 @@
java.lang.String is default.
declare Whether the variable is declared or not.
+
True is the default.
scope The scope of the scripting varaible
Something quite strange is going on.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Steve Downey <st...@netfolio.com>.
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote:
> Steve Downey wrote:
> > Actually, with the recent release of commons-logging, we should be able
> > to get rid of the explicit LogKit and Log4J. They're there so as to get a
> > complete build of commons-logging. Tomcat 5 itself doesn't use either
> > directly.
> >
> > Xerces is a different issue. There was a bug that was preventing Tomcat
> > from migrating to the latest version. Unfortunately, I no longer remember
> > the details. Anyone know why we're using 2.1.0 instead of 2.2.0?
>
> From what I experienced with Xerces j 2.2.0 it seems it does
> much more validity check and for instance found a '--' somewhere
> in comments (1 EUR to the first who find where).
>
> Previous version of Xerces or crimson didn't got that problem.
>
> if we could see which xml/dtd/tld is reported buggy, which
> will able to see if it's a bug or a features (ie a more strict
> check of xml rules)
Going through my old mail, I was remembering the 2.0.1/2.0.2 problems that
were keeping us on xerces nightly for a while. 2.1.0 fixed those problems.
This seems to be a problem in parsing the 1.2 taglibs DTD. This one fails
http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd
where this one
http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd
succeeds.
Failure is at line 307, column 39. But I don't see anything significant there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Remy Maucherat <re...@apache.org>.
Jean-Francois Arcand wrote:
>
>
> Henri Gomez wrote:
>
>> Steve Downey wrote:
>>
>>> Actually, with the recent release of commons-logging, we should be
>>> able to get rid of the explicit LogKit and Log4J. They're there so as
>>> to get a complete build of commons-logging. Tomcat 5 itself doesn't
>>> use either directly.
>>>
>>> Xerces is a different issue. There was a bug that was preventing
>>> Tomcat from migrating to the latest version. Unfortunately, I no
>>> longer remember the details. Anyone know why we're using 2.1.0
>>> instead of 2.2.0?
>>
>>
> Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually
> testing Xerces 2.2.....knowing how much problem we have with Xerces
> 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no
> regression ;-)
I upgraded the properties file (sorry, didn't know you hadn't done it on
purpose), as IMO it's a good idea to test as much as possible since
we're still in pre-alpha stages.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Jean-Francois Arcand <jf...@apache.org>.
Henri Gomez wrote:
> Steve Downey wrote:
>
>> Actually, with the recent release of commons-logging, we should be
>> able to get rid of the explicit LogKit and Log4J. They're there so as
>> to get a complete build of commons-logging. Tomcat 5 itself doesn't
>> use either directly.
>>
>> Xerces is a different issue. There was a bug that was preventing
>> Tomcat from migrating to the latest version. Unfortunately, I no
>> longer remember the details. Anyone know why we're using 2.1.0
>> instead of 2.2.0?
>
Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually
testing Xerces 2.2.....knowing how much problem we have with Xerces
2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no
regression ;-)
-- Jeanfrancois
>>
>
> From what I experienced with Xerces j 2.2.0 it seems it does
> much more validity check and for instance found a '--' somewhere
> in comments (1 EUR to the first who find where).
>
> Previous version of Xerces or crimson didn't got that problem.
>
> if we could see which xml/dtd/tld is reported buggy, which
> will able to see if it's a bug or a features (ie a more strict
> check of xml rules)
>
>
>
> --
> 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: Is Compile Failure? was Re: Need some clarifications
Posted by Han Ming Ong <ha...@apple.com>.
On Thursday, October 3, 2002, at 09:14 AM, Henri Gomez wrote:
> Steve Downey wrote:
>> Actually, with the recent release of commons-logging, we should be
>> able to get rid of the explicit LogKit and Log4J. They're there so as
>> to get a complete build of commons-logging. Tomcat 5 itself doesn't
>> use either directly.
>> Xerces is a different issue. There was a bug that was preventing
>> Tomcat from migrating to the latest version. Unfortunately, I no
>> longer remember the details. Anyone know why we're using 2.1.0
>> instead of 2.2.0?
>
> From what I experienced with Xerces j 2.2.0 it seems it does
> much more validity check and for instance found a '--' somewhere
> in comments (1 EUR to the first who find where).
>
:-)
I scanned though quite a lot of xml/dtd/tld in 4.1.12, hoping to get
that elusive 1 EUR.
Not such luck. The only thing that I can come up with is:
the TLDs are referring an DTD that has been moved by Sun. Here's what
you get when you go to
http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd
"The file named http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd
has been renamed to http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd
in the most current version of the specification.
Please update your application to use the new name."
Thus, if the parser has been set to be validating, it would fail
(albeit with a different error). Maybe updating the DOCTYPE in the TLDs
should help?
> Previous version of Xerces or crimson didn't got that problem.
>
> if we could see which xml/dtd/tld is reported buggy, which
> will able to see if it's a bug or a features (ie a more strict
> check of xml rules)
>
>
>
> --
> 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: Is Compile Failure? was Re: Need some clarifications
Posted by Henri Gomez <hg...@apache.org>.
Steve Downey wrote:
> Actually, with the recent release of commons-logging, we should be able to get
> rid of the explicit LogKit and Log4J. They're there so as to get a complete
> build of commons-logging. Tomcat 5 itself doesn't use either directly.
>
> Xerces is a different issue. There was a bug that was preventing Tomcat from
> migrating to the latest version. Unfortunately, I no longer remember the
> details. Anyone know why we're using 2.1.0 instead of 2.2.0?
From what I experienced with Xerces j 2.2.0 it seems it does
much more validity check and for instance found a '--' somewhere
in comments (1 EUR to the first who find where).
Previous version of Xerces or crimson didn't got that problem.
if we could see which xml/dtd/tld is reported buggy, which
will able to see if it's a bug or a features (ie a more strict
check of xml rules)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Steve Downey <st...@netfolio.com>.
Actually, with the recent release of commons-logging, we should be able to get
rid of the explicit LogKit and Log4J. They're there so as to get a complete
build of commons-logging. Tomcat 5 itself doesn't use either directly.
Xerces is a different issue. There was a bug that was preventing Tomcat from
migrating to the latest version. Unfortunately, I no longer remember the
details. Anyone know why we're using 2.1.0 instead of 2.2.0?
On Thursday 03 October 2002 06:43 am, Christian Gross wrote:
> Thank-you, but I still seem to get errors.
>
> Namely the logkit from Avalon is referencing an old verion. I fixed it up
> to the following
>
> 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/l
>atest/LogKit-1.1-bin.tar.gz
>
> xerces.home=${base.path}/xerces-2_2_0
> xerces.lib=${xerces.home}
> xercesImpl.jar=${xerces.lib}/xercesImpl.jar
> xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
> xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
>
> I do not know if you can commit changes, but these worked for me, since the
> old versions either do not exist or the references have been made updated.
>
> Christian Gross
>
> At 09:40 PM 02/10/2002 -0400, you wrote:
> >You need to be using the HEAD version of digester. It should have been
> > built in the directory specified by base.path. Double check that it was
> > built correctly. I just recreated it in my depends directory, and the
> > system built fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Christian Gross <ma...@devspace.com>.
Thank-you, but I still seem to get errors.
Namely the logkit from Avalon is referencing an old verion. I fixed it up
to the following
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
xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
I do not know if you can commit changes, but these worked for me, since the
old versions either do not exist or the references have been made updated.
Christian Gross
At 09:40 PM 02/10/2002 -0400, you wrote:
>You need to be using the HEAD version of digester. It should have been built
>in the directory specified by base.path. Double check that it was built
>correctly. I just recreated it in my depends directory, and the system built
>fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Compile Failure? was Re: Need some clarifications
Posted by Steve Downey <st...@netfolio.com>.
You need to be using the HEAD version of digester. It should have been built
in the directory specified by base.path. Double check that it was built
correctly. I just recreated it in my depends directory, and the system built
fine.
A number of the dependencies are unreleased at this point. 'ant download'
tries to grab the correct ones.
On Wednesday 02 October 2002 07:54 pm, Christian Gross wrote:
> Thanks for your answer. That helps quite a bit. Now I have another
> issue...
>
> build-catalina:
> [javac] Compiling 94 source files to
> D:\Instructor\Projects\jakarta-tomcat-c
> atalina\build\server\classes
> [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol
> [javac] symbol : method
> setEntityResolver (org.apache.catalina.util.Schema
> Resolver)
> [javac] location: class org.apache.commons.digester.Digester
> [javac] tldDigester.setEntityResolver(tldEntityResolver);
> [javac] ^
> [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol
> [javac] symbol : method
> setEntityResolver (org.apache.catalina.util.Schema
> Resolver)
> [javac] location: class org.apache.commons.digester.Digester
> [javac] webDigester.setEntityResolver(webEntityResolver);
> [javac] ^
> [javac]
> D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or
> g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol
> [javac] symbol : method setPublicId (java.lang.String)
> [javac] location: class org.apache.commons.digester.Digester
> [javac] digester.setPublicId(publicId);
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -deprecation for details.
> [javac] 3 errors
>
> BUILD FAILED
> file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801:
> Comp
> ile failed; see the compiler error output for details.
>
> I checked out digester 1.3 and 1.2 and there does not seem to be a method
> setEntityResolver. Or am I missing something?
>
> Christian Gross
>
> At 14:18 02/10/2002 -0400, you wrote:
> >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>
>
> Christian Gross
> Software Engineering Consultant
> http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.1166
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>