Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

[Steve Downey]

What about using external entities?

ie:



http://java.sun.com/dtd/web-app_2_3.dtd";
[

]
>

then, between the servlet and servlet mapping sections

&jspservlet;





-SMD
- Original Message - 
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 6:05 AM
Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs


> Hi,
> 
> It is not very convinient or easy to insert the declarations for 
> compiled JSPs into the webapp's web.xml file. It also has the 
> disadvantage of adding a lot of mess in the web.xml, which the user may 
> not like.
> 
> For that reason, I propose that Tomcat parses a new (optional) XML file, 
> with the same DTD as web.xml, which would contain declarations identical 
> to web.xml, and which would be used for declaring the compiled JSPs. I 
> propose naming that file compiledjsp.xml.
> 
> An additional advantage is that it would allow Tomcat to precompile 
> webapps as they are deployed (otherwise, nasty XML manipulation is 
> needed to do that, and I think overwriting the originial web.xml during 
> deployment is bad).
> 
> Maybe someone has a better solution for this problem. Any comments ?
> 
> Remy
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote:
> Glenn Nielsen wrote:
> > Remy Maucherat wrote:
> > [...]
> > I agree that JSPC needs to be simplified and that the webapp mode should
> > be retained.  But the webapp mode should allow for a war file to be
> > generated
> > which is self contained including the precompiled JSP classses.  And for
> > the
> > generated war to be able to run from the war file with no need to unpack
> > it.
>
> Why add this to JSPC? Isn't it already very easy to use external tools
> to create the WAR file (the jar command, ant's war task, etc)? I have
> no objections to cleaning up the JSPC code, but I would like it to
> stay focused on it's its main task: convert JSP source to servlet
> source. I have sometimes wished for automatic compilation of the servlet
> source to class files, but in the name of simplicity and separation of
> concerns, I think it's better handled by other tools.
>
In one way, it would be better to have the JSPC do the java compilation, 
because it can tell exactly what the environment is supposed to be. The 
libraries that are available, etc. It's reproduceable in ant, but it's not a 
terribly expensive option to maintain in jasper2, since it follows the same 
path as the runtime compiler.

> > Also I agree that this feature is a proprietary feature of Tomcat and we
> > should no longer try to generate a war that can be deployed in any
> > container.
>
> Why not? This works today (at least in TC 4.0.4) and I find it very
> handy to be able to create a JAR file for all my JSPs that I know I
> can deploy to any container along with the jasper-runtime.jar. If there
> are issues with this that I don't know about, please tell me. Otherwise
> I see no reason to remove this capability.
>
> If you can use JSPC to create the servlet source and web.xml fragments,
> it's easy to use other tools to compile the source and create a WAR with
> all other parts of the app (servlets, taglibs, web.xml, static stuff,
> etc.) and deploy it to Tomcat or any other container. As far as I can
> see, there's no need for a proprietary solution to get this to work.
>
>  > [...]
>
> Hans


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

It's better to look at it as a compiler. It's output happens to be java, but 
it acts a whole lot more like a compiler than a precompiler. Precompilers are 
usually more like macro preprocessors. 

On Friday 08 November 2002 07:05 am, John Trollinger wrote:
> I have to disagree with this, jspc is a pre compiler, not a webapp
> packager.
>
>
> John
>
> > I agree that JSPC needs to be simplified and that the webapp
> > mode should be retained.  But the webapp mode should allow
> > for a war file to be generated which is self contained
> > including the precompiled JSP classses.  And for the
> > generated war to be able to run from the war file with no
> > need to unpack it.
> >
> > Also I agree that this feature is a proprietary feature of
> > Tomcat and we should no longer try to generate a war that can
> > be deployed in any container.
> >
> > There may be a way to do this:
> >
> > Put the generated JSP class files in a /WEB-INF/jspwork/
> > directory.  This work directory would only be used by jasper
> > for loading jsp pages, the normal work directory would still
> > be used for all other things.
> >
> > Add the "jspwork" attribute to the DefaultContext and Context
> > config elements. This attribute would specify the directory
> > path within the war file to use for loading the JSP page
> > classes from by Jasper.
> >
> > This would allow JSPC to create a war file which was self
> > contained including the precompiled JSP page classes and be
> > runnable directly from the war or unpacked into a directory.
> >
> > +1 if we modify Tomcat & Jasper to support precompiled JSP
> > pages running
> > +from a
> > self contained war file.
> >
> > Regards,
> >
> > Glenn
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> >  [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

I dislike this option immensely. It's entirely contrary to what JSPC is for. 
It's a tool for generating servlets from JSP that do not require the entire 
JSP machinery. It produces a web.xml file that maps each jsp page to the 
generated servlet. The generated servlets are portable between servlet 
engines. They can be compiled by a normal java compiler. In short, they are 
very much unlike the output in the work directory.

What you are proposing is the same as the precompile option on the URL. 
Here's a script that will do it for all compliant JSP engines
find  . -name '*jsp' -printf "http://`echo $HOSTNAME`/%P?jsp_precompile\n" \
 | xargs -n 1 lynx -head -source


On Thursday 07 November 2002 04:23 am, Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
>
> 
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> 
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: mavenize tomcat

[Steve Downey]

On Thursday 24 October 2002 08:15 pm, Warner Onstine wrote:
> - Original Message -
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 24, 2002 4:50 PM
> Subject: Re: mavenize tomcat
>
>
> > FYI, tomcat5 does have a 'download' target that gets you all the
> > jars, and an 'update' that gets you all the cvs repositories that
> > you need. That's what I use, and it's not that bad ( even if slow )
>
> Interesting, sounds like it is duplicating what Maven can do as it stores
> all the jars in a common repository.
>
No it doesn't do that at all. It downloads the actual distributions, or CVS 
trees, of projects into an area specified. No external repository of jars or 
internal depot of jars. You get real distributions of the dependencies, 
including docs and licenses.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] building ?

[Steve Downey]

On Monday 14 October 2002 01:19 pm, Costin Manolache wrote:
> Remy Maucherat wrote:
> > No, but:
> > - my computer is relatively fast (P4m 1.6 these days)
> > - I'll get a new one a lot faster really soon :)
>
> Well, I prefer laptops - and I prefer light over fast.
> And those things are quite expensive.
>
> > But maybe we could work on your updated script (you said it was a lot
> > faster), and add the utility targets to it.
>
> It is faster, but it's only good to compile stuff ( well, it can also
> start tomcat, but that's still too experimental ).
>
> BTW, related - are the tests working ? What's the right script
> and order to run jsp and container tests ?
>
> I would like a target to run the tests ( and to get that into
> gump ).
>

watchdog works, and the small number of unit tests targeted by the test target 
works. Catalina's tester doesn't work. I've posted patches to make it work. I 
can repost, if it would be useful.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JSP 2.0's J2SE 1.4 Requirement

[Steve Downey]

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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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.dtd13 Aug 2002
> > 16:20:58 -  1.1.1.1
> > +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002
> > 20:42:30 -
> > @@ -304,6 +304,7 @@
> >   java.lang.String is default.
> >
> >  declare  Whether the variable is declared or not.
> > +
> >   True is the default.
> >
> >  scopeThe 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 :
>
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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.dtd13 Aug 2002 16:20:58 
-  1.1.1.1
+++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 
-
@@ -304,6 +304,7 @@
  java.lang.String is default.

 declare  Whether the variable is declared or not.
+
  True is the default.

 scopeThe scope of the scripting varaible



Something quite strange is going on.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: cvs commit: jakarta-tomcat-5 build.properties.default

[Steve Downey]

This causes all 181 Watchdog JSP tests to fail.

I don't know why yet, and it's probably something simple, but it's not a good 
sign.

On Thursday 03 October 2002 08:56 am, [EMAIL PROTECTED] wrote:
> remm2002/10/03 05:56:39
>
>   Modified:.build.properties.default
>   Log:
>   - New Xerces version.
>
>   Revision  ChangesPath
>   1.38  +3 -3  jakarta-tomcat-5/build.properties.default
>
>   Index: build.properties.default
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
>   retrieving revision 1.37
>   retrieving revision 1.38
>   diff -u -r1.37 -r1.38
>   --- build.properties.default18 Sep 2002 11:44:21 -  1.37
>   +++ build.properties.default3 Oct 2002 12:56:39 -   1.38
>   @@ -104,11 +104,11 @@
>
>
># - Xerces XML Parser, version 2.1.0 or later -
>   -xerces.home=${base.path}/xerces-2_1_0
>   +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.1.0.tar.gz
>   +xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
>
>
># --


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:[EMAIL PROTECTED]:/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:  
> >  For additional
> > commands, e-mail: 
>
> Christian Gross
> Software Engineering Consultant
> http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.

Re: Need some clarifications

[Steve Downey]

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:[EMAIL PROTECTED]:/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:   
For additional commands, e-mail: 

Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability

[Steve Downey]

On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote:
> on 2002/9/24 4:59 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> > A security vulnerability has been confirmed to exist in all Apache
> > Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which
> > allows to use a specially crafted URL to return the unprocessed source
> > of a JSP page, or, under special circumstances, a static resource which
> > would otherwise have been protected by security constraint, without the
> > need for being properly authenticated.
>
> Once again...JSP sucks and Velocity is the right way to go...you will never
> have to worry about your container spilling your beans (pun intended).
>
Perhaps you would prefer this exploit?

http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm

Horrors! Velocity is insecure! 

The DefaultServlet exploit is a general security problem in Tomcat. JSP may be 
somewhat more vulnerable, due to the (somewhat naieve) expectation that the 
source will be confidential, but it's not really JSP per se that is at fault.

I wonder what could be done with the CGIServlet, for example.

The root cause is the InvokerServlet. It's inherently insecure. It can be used 
not just to execute an arbitrary servlet, but to actually load any java 
class. And loading a class is not side-effect free. 
> Given that Tomcat gets around 100k+ downloads/week...imagine how many
> servers now need to be updated and how much money and time that will cost
> to do so?
>
> http://jakarta.apache.org/velocity/
>
> Wake up people. Velocity is faster and more secure than JSP will ever be.

As long as it's running on an insecure container, it's really no safer.

>
> -jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH]catalina-tester assumes that ServletExceptions are NOT unwrapped

[Steve Downey]

Per Servlet 2.3, if a servlet throws a wrapped exception, the error handler 
that receives it gets the underlying root cause as the exception. That is, if 
ServletException(new TesterException()) is thrown, the exception in the 
request under attribute "javax.servlet.error.exception" will be 
TesterException, not ServletException.

The test in catalina/tester assumes that the root cause will still be wrapped 
in a ServletException.


With this patch, plus the others I've posted, the tomcat-5 passes all of the 
catalina tester tests. If anyone is interested, I can post a rolled up set of 
patches.




? conf
Index: tester/org/apache/tester/ErrorPage04.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/ErrorPage04.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 ErrorPage04.java
--- tester/org/apache/tester/ErrorPage04.java	18 Jul 2002 16:47:26 -	1.1.1.1
+++ tester/org/apache/tester/ErrorPage04.java	23 Sep 2002 17:44:46 -
@@ -89,28 +89,19 @@
 value = request.getAttribute("javax.servlet.error.exception");
 if (value == null)
 sb.append(" exception is missing/");
-else if (!(value instanceof javax.servlet.ServletException)) {
+else if (!(value instanceof TesterException)) {
 sb.append(" exception class is ");
 sb.append(value.getClass().getName());
 sb.append("/");
 } else {
-exception = (ServletException) value;
-rootCause = exception.getRootCause();
-if (rootCause == null) {
-sb.append(" rootCause is missing/");
-} else if (!(rootCause instanceof TesterException)) {
-sb.append(" rootCause is ");
-sb.append(rootCause.getClass().getName());
-sb.append("/");
-} else {
-TesterException te = (TesterException) rootCause;
+TesterException te = (TesterException) value;
 if (!"ErrorPage03 Threw Exception".equals(te.getMessage())) {
 sb.append(" exception message is ");
 sb.append(te.getMessage());
 sb.append("/");
 }
 }
-}
+
 
 value = request.getAttribute("javax.servlet.error.exception_type");
 if (value == null)
@@ -121,7 +112,7 @@
 sb.append("/");
 } else {
 Class clazz = (Class) value;
-if (!"javax.servlet.ServletException".equals(clazz.getName())) {
+if (!"org.apache.tester.TesterException".equals(clazz.getName())) {
 sb.append(" exception_type class is ");
 sb.append(clazz.getName());
 sb.append("/");



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH]catalina/tester fix golden files for new request listener noise

[Steve Downey]

JSP includes now trigger request listeners with the attributes for dispatcher 
types and dispatcher request paths. This patch adds the output from the 
request listener to the golden files.



Index: JspInclude01a.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude01a.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspInclude01a.txt
--- JspInclude01a.txt	18 Jul 2002 16:47:25 -	1.1.1.1
+++ JspInclude01a.txt	23 Sep 2002 17:36:30 -
@@ -1,6 +1,8 @@
 This is before the include
 Include00a PASSEDSessionListener01: sessionCreated()
 SessionListener02: sessionCreated()
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8)
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude01.jsp)
 
 This is after the include
 
Index: JspInclude02a.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude02a.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspInclude02a.txt
--- JspInclude02a.txt	18 Jul 2002 16:47:25 -	1.1.1.1
+++ JspInclude02a.txt	23 Sep 2002 17:36:30 -
@@ -1,6 +1,8 @@
 This is before the include
 Include00a PASSEDSessionListener01: sessionCreated()
 SessionListener02: sessionCreated()
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8)
+RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude02.jsp)
 
 This is after the include
 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][5] Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java

[Steve Downey]

JDK 1.4's javac doesn't like this. It's complaining about casting Object to 
X509Certificate[].

On Saturday 21 September 2002 02:50 am, [EMAIL PROTECTED] wrote:
> billbarker2002/09/20 23:50:30
>
>   Modified:catalina/src/share/org/apache/catalina/authenticator
> SSLAuthenticator.java
>   Log:
>   Final level in replacing CertificatesValve under Coyote.
>
>   This is a little hackish, but is portable to 4.x without changing the
> API.  Here, it should probably change once Coyote is properly exposed to
> Catalina.
>
>   If there aren't any major complaints, I'll port to the 4.1 branch later.
>
>   Revision  ChangesPath
>   1.2   +7 -4 
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticato
>r/SSLAuthenticator.java
>
>   Index: SSLAuthenticator.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/au
>thenticator/SSLAuthenticator.java,v retrieving revision 1.1
>   retrieving revision 1.2
>   diff -u -r1.1 -r1.2
>   --- SSLAuthenticator.java   18 Jul 2002 16:48:02 -  1.1
>   +++ SSLAuthenticator.java   21 Sep 2002 06:50:30 -  1.2
>   @@ -150,6 +150,9 @@
>log(" Looking up certificates");
>X509Certificate certs[] = (X509Certificate[])
>   
> request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR); +   if ((certs
> == null) || (certs.length < 1)) {
>   +   certs =
> request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR); +}
>if ((certs == null) || (certs.length < 1)) {
>if (debug >= 1)
>log("  No certificates included with this request");


Index: SSLAuthenticator.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
retrieving revision 1.3
diff -u -r1.3 SSLAuthenticator.java
--- SSLAuthenticator.java	21 Sep 2002 07:25:21 -	1.3
+++ SSLAuthenticator.java	22 Sep 2002 19:46:43 -
@@ -151,7 +151,7 @@
 X509Certificate certs[] = (X509Certificate[])
 request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
 if ((certs == null) || (certs.length < 1)) {
-certs = request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR);
+certs =  (X509Certificate[])  request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR);
 }
 if ((certs == null) || (certs.length < 1)) {
 if (debug >= 1)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper 2 Question

[Steve Downey]

On Friday 20 September 2002 07:27 am, peter lin wrote:
> I would also like to see the comments in jasper1 ported over to
> jasper2.  Now if only I didn't need sleep, I'd do it myself and submit a
> patch. the code changed quite a bit between jasper1 and jasper2. the
> class responsible is in jasper/compiler/Generator in case you get the
> urge to port the comments over :)
>

Plus adding the end Mark in Node.Node. And classifying the Nodes in a similar 
manner to the old Generators. 

> peter
>
> John Trollinger wrote:
> > To answer your original question, I do not believe there is any
> > enhancements to add documentation back to the generated servelt code.
> > If you would like to see this enhancement you can allways suggest it to
> > the tomcat developers, or you could add the code in yourself and submit
> > a patch.
> >
> > And don't buy all the velocity hype... :-)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper 2 Question

[Steve Downey]

On Friday 20 September 2002 06:18 am, Pier Fumagalli wrote:
> Hm The original question was about line numbers on JSPs, when they
> are compiled, and when they are executed and throw exceptions, right?
> Yes, it was...
>
> I said "use some tea" because Tea, developed by Disney, goes exactly in
> that direction, not having "middle layer" .java files over which the
> line number get messed up, they simply compile a template straight into
> ".class" having both the advantage of compiled templates, and the
> advatage that line numbers, both at compilation and runtime, are
> preserved...
>

No, the original question was about the debugging capabilities that have been 
removed from jasper2. Jasper used to mark the begin and end points in the 
original source in the java translation as comments in the form:
// HTML // begin [file="/index.jsp";from=(0,0);to=(4,0)]

Restoring that ability would be somewhat difficult as the parser doesn't track 
the endpoints of the nodes, just the starts. 

Jasper2 is able to output data that might be compatible with JSR-45. No one's 
really sure, yet. 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper 2 Question

[Steve Downey]

Jasper2 is targeting JSR45, Debugging Support for Other Languages. 

On Thursday 19 September 2002 06:28 pm, Lenny Karpel wrote:
> ok .. now I am really confused .. here is the tomcat development group ..
> the 'Official Reference Implementation' for JSP .. and I am being told by
> people within this group .. to NOT use it ..
>
> this is truly amazing .. how can this possibly be ..
>
> my original question is about 'bugs' in jasper2 .. not about what tools I
> should use .. my question is not one of religion ..
>
> once again .. the quote from the intellij site ..
>
> "As for Tomcat 4.1.x support, I'm afraid we are out-of-luck here. Tomcat
> 4.0.4 used to generate useful comments in the servlet code, that allowed
> the integration plugin to map jsp line numbers to servlet line numbers. But
> from the new version of Tomcat (Jasper2 in particular), this functionality
> is missing. At least I haven't been able to find anything to enable comment
> generation, and nobody from Tomcat user-list answered my question about
> this."
>
> for myself .. all I want to know .. is if this 'situation' in jasper2 will
> be fixed .. if so .. when .. if not .. why ..
>
> we use JSP here .. as do quite a few others .. in quite a few places ..
>
> i did not post this question to find out that the developers of JSP
> (jasper) would rather I use something else ..
>
> could this possibly be how the 'managers' of this development effort feel
> ??
>
> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 19, 2002 3:25 PM
> To: Tomcat Dev List
> Subject: RE: Jasper 2 Question
>
> On Fri, 2002-09-20 at 04:30, Lenny Karpel wrote:
> > is it right that when I ask a serious question about jasper2 that I
> > get these totally ridiculous answers ?
>
> Well, Jon and Pier are known to throw in a curly one from time to time,
> which keeps all of us here on the list in good spirits  ;-)
>
> Anyway, there is a serious side to all this as JSP's are inherently evil.
> You'll find that creating true MVC applications in Velocity is almost
> trivial. I suggest you do read Jon's article. The fact that JSP's are
> "official", doesn't mean they are good.
>
> Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] catalina DateTool thread safety issue

[Steve Downey]

This patch mirrors that in connectors. DateTool in catalina util is largely 
obsolete, in any case. The patch cuts out unused code.



? share/org/apache/catalina/startup/CatalinaService.java.smd
Index: share/org/apache/catalina/util/CookieTools.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 CookieTools.java
--- share/org/apache/catalina/util/CookieTools.java	18 Jul 2002 16:47:45 -	1.1.1.1
+++ share/org/apache/catalina/util/CookieTools.java	18 Sep 2002 23:35:05 -
@@ -143,10 +143,10 @@
 if (version == 0) {
 buf.append (";Expires=");
 if (cookie.getMaxAge() == 0)
-DateTool.oldCookieFormat.format(new Date(1), buf,
+DateTool.formatOldCookie(new Date(1), buf,
 new FieldPosition(0));
 else
-DateTool.oldCookieFormat.format
+DateTool.formatOldCookie
 (new Date( System.currentTimeMillis() +
cookie.getMaxAge() *1000L), buf,
  new FieldPosition(0));
Index: share/org/apache/catalina/util/DateTool.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/DateTool.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 DateTool.java
--- share/org/apache/catalina/util/DateTool.java	18 Jul 2002 16:47:45 -	1.1.1.1
+++ share/org/apache/catalina/util/DateTool.java	18 Sep 2002 23:35:05 -
@@ -79,55 +79,34 @@
  */
 public class DateTool {
 
-private static StringManager sm =
-StringManager.getManager("org.apache.catalina.util");
-
 /** US locale - all HTTP dates are in english
  */
 public final static Locale LOCALE_US = Locale.US;
 
 /** GMT timezone - all HTTP dates are on GMT
  */
-public final static TimeZone GMT_ZONE = TimeZone.getTimeZone("GMT");
-
-/** format for RFC 1123 date string -- "Sun, 06 Nov 1994 08:49:37 GMT"
- */
-public final static String RFC1123_PATTERN =
-"EEE, dd MMM y HH:mm:ss z";
-
-// format for RFC 1036 date string -- "Sunday, 06-Nov-94 08:49:37 GMT"
-private final static String rfc1036Pattern =
-"E, dd-MMM-yy HH:mm:ss z";
-
-// format for C asctime() date string -- "Sun Nov  6 08:49:37 1994"
-private final static String asctimePattern =
-"EEE MMM d HH:mm:ss y";
+private final static TimeZone GMT_ZONE = TimeZone.getTimeZone("GMT");
 
 /** Pattern used for old cookies
  */
 public final static String OLD_COOKIE_PATTERN = "EEE, dd-MMM- HH:mm:ss z";
 
-/** DateFormat to be used to format dates
- */
-public final static DateFormat rfc1123Format =
-new SimpleDateFormat(RFC1123_PATTERN, LOCALE_US);
-
 /** DateFormat to be used to format old netscape cookies
  */
-public final static DateFormat oldCookieFormat =
+private final static DateFormat oldCookieFormat =
 new SimpleDateFormat(OLD_COOKIE_PATTERN, LOCALE_US);
 
-public final static DateFormat rfc1036Format =
-new SimpleDateFormat(rfc1036Pattern, LOCALE_US);
-
-public final static DateFormat asctimeFormat =
-new SimpleDateFormat(asctimePattern, LOCALE_US);
-
 static {
-rfc1123Format.setTimeZone(GMT_ZONE);
 oldCookieFormat.setTimeZone(GMT_ZONE);
-rfc1036Format.setTimeZone(GMT_ZONE);
-asctimeFormat.setTimeZone(GMT_ZONE);
+}
+
+public static StringBuffer formatOldCookie(
+  Date d,
+  StringBuffer buf,
+  FieldPosition fieldPosition) {
+  synchronized (oldCookieFormat) {
+return oldCookieFormat.format(d, buf, fieldPosition);
+  }
 }
 
 }



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

On Wednesday 18 September 2002 08:34 am, Henri Gomez wrote:
> > The upshot is that DateFormats need to be either thread local, or created
> > new each time.
>
> Created each time is exactly what we want to avoid ;)
Sacrificing correctness for speed isn't a great trade-off. After all, if it 
doesn't have to work, I can make it a LOT faster.

In this case, it looks like the problem with SimpleDateFormat is manageable 
with synchronization. SDF can leak some of its internal state with 
get/setCalendar. Since in the connectors DateTool, the formatter instance is 
private, and get/setCalendar is never called, syncing on the instance should 
be sufficient.

It looks like the same problem exists in catalina's DateTool.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

OK, ignore my last message.

But, it's not just less paranoid. It's more correct. If rfc1123Format were 
used elsewhere, the lock on Class.DateTool would not be sufficient. 

Actually, refreshing my memory on this bug, synchronization is insufficient.

http://developer.java.sun.com/developer/bugParade/bugs/4228335.html

The upshot is that DateFormats need to be either thread local, or created new 
each time.

On Wednesday 18 September 2002 12:20 am, [EMAIL PROTECTED] wrote:
> billbarker2002/09/17 21:20:24
>
>   Modified:util/java/org/apache/tomcat/util/buf DateTool.java
>   Log:
>   A little less paraniod than the last one, but functionally the same.
>
>   Revision  ChangesPath
>   1.7   +6 -2 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
>a
>
>   Index: DateTool.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
>teTool.java,v retrieving revision 1.6
>   retrieving revision 1.7
>   diff -u -r1.6 -r1.7
>   --- DateTool.java   18 Sep 2002 03:50:04 -  1.6
>   +++ DateTool.java   18 Sep 2002 04:20:24 -  1.7
>   @@ -141,8 +141,12 @@
>// Called from MessageBytes.setTime
>/**
> */
>   -public static synchronized String format1123( Date d ) {
>   -   return format1123(d, rfc1123Format);
>   +public static String format1123( Date d ) {
>   +   String dstr=null;
>   +   synchronized(rfc1123Format) {
>   +   dstr = format1123(d, rfc1123Format);
>   +   }
>   +   return dstr;
>}
>
>public static String format1123( Date d,DateFormat df ) {


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java

[Steve Downey]

I think that should probably be
   public static String format1123( Date d ) {
synchronized(rfc1123Format) {
return format1123(d, rfc1123Format);
}
   }

Synching on 'this' is overkill.

On Tuesday 17 September 2002 11:50 pm, [EMAIL PROTECTED] wrote:
> billbarker2002/09/17 20:50:05
>
>   Modified:util/java/org/apache/tomcat/util/buf DateTool.java
>   Log:
>   Fix thread-safe issue on date formatting.
>
>   Reported by: Hugh J. L. [EMAIL PROTECTED]
>
>   Revision  ChangesPath
>   1.6   +2 -7 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
>a
>
>   Index: DateTool.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
>teTool.java,v retrieving revision 1.5
>   retrieving revision 1.6
>   diff -u -r1.5 -r1.6
>   --- DateTool.java   22 Mar 2002 04:12:01 -  1.5
>   +++ DateTool.java   18 Sep 2002 03:50:04 -  1.6
>   @@ -141,13 +141,8 @@
>// Called from MessageBytes.setTime
>/**
> */
>   -public static String format1123( Date d ) {
>   -long dt = d.getTime() / 1000;
>   -if ((rfc1123DS != null) && (dt == rfc1123Sec))
>   -return rfc1123DS;
>   -rfc1123DS  = rfc1123Format.format( d );
>   -rfc1123Sec = dt;
>   -return rfc1123DS;
>   +public static synchronized String format1123( Date d ) {
>   +   return format1123(d, rfc1123Format);
>}
>
>public static String format1123( Date d,DateFormat df ) {


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: (tester failure) cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java

[Steve Downey]

The new attributes in the request are causing tester to fail on a number of include 
and forward tests. For example
   [tester] EXPECTED: ==
   [tester] This is before the include
   [tester] Include00a PASSEDSessionListener01: sessionCreated()
   [tester] SessionListener02: sessionCreated()

   [tester] This is after the include

   [tester] 
   [tester] RECEIVED: ==
   [tester] This is before the include
   [tester] Include00a PASSEDSessionListener01: sessionCreated()
   [tester] SessionListener02: sessionCreated()
   [tester] RequestListener01: 
attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8)
   [tester] RequestListener01: 
attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude01.jsp)

   [tester] This is after the include

   [tester] 
   [tester] FAIL [GET /tester/JspInclude01.jsp?path=/Include00a] Failed Golden File 
Comparison

It looks like handling the dispatcher type as a request element is reasonable,
so it seems the golden files need to be updated.


On Wednesday 11 September 2002 08:09 pm, [EMAIL PROTECTED] wrote:
> amyroh  2002/09/11 17:09:28
>
>   Modified:catalina/src/share/org/apache/catalina/core
> ApplicationDispatcher.java
> ApplicationFilterFactory.java
> StandardWrapperValve.java
>catalina/src/share/org/apache/catalina/deploy FilterMap.java
>catalina/src/share/org/apache/catalina/valves
> ErrorDispatcherValve.java
>   Log:
>   Fix RequestDispatcher for ERROR and INCLUDE - bugzilla bugs 12456 and
> 12457.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Contributing patches/enhancements?

[Steve Downey]

From my experience, it depends if it's a bug or an enhancement.
If it's a bug, Bugzilla is your friend. Someone will eventually have to deal 
with it before a release. Just posting to the mailing list means that it's 
likely to get lost. And patches for bugs tend to be fairly stable over time.

On the other hand, putting enhancements in Bugzilla isn't as effective. 
Bugzilla isn't very good for discussion. And enhancements often are more 
invasive to the code, so a patch isn't as likely to be effective later.

Just my $0.02

On Wednesday 11 September 2002 06:16 pm, Eddie Ruvinsky wrote:
> Hello, I have a process question about how I could contribute Tomcat source
> patches/enhancements?  Would I open a Bugzilla and attach a diff text file,
> then wait for an official Tomcat contributor to review it and add it into
> the source tree?
>
> Thanks,
> Eddie
>
>
>
> -
> Yahoo! - We Remember
> 9-11: A tribute to the more than 3,000 lives lost


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Catalina tester failure on JSP Document Parsing

[Steve Downey]

The tests for Tomcat4 are in jakarta-tomcat-4.0/tester, while the tests for 
tomcat 5 are in jakarta-tomcat-catalina/tester, so fixing them shouldn't be a 
problem in that sense.

Howver, since tomcat 4 is now shipping with jasper2, isn't it a problem for 
tomcat 4, also?

In any case, given the lack of depth in this test, I think the right answer is 
to change it to eliminate the empty tags. I think it's really trying just to 
see if JSP Document is there as a feature, not really checking the handling 
of XML.



On Wednesday 11 September 2002 06:21 pm, Kin-Man Chung wrote:
> I'd suggest that we remove this test.
>
> Jasper 2 and jasper produces different but correct XML view of the JSP
> document.  If the golden file is fixed to pass in TC5, it would then
> fail in TC4.0.
>
> > Date: Wed, 11 Sep 2002 18:10:59 -0400
> > From: Steve Downey <[EMAIL PROTECTED]>
> > Subject: Catalina tester failure on JSP Document Parsing
> > To: [EMAIL PROTECTED]
> >
> > I'm seeing the following error on catalina's tester app, running it under
> > Tomcat 5:
> >
> >[echo] - JSP Document Parsing -
> >[tester] EXPECTED: ==
> >[tester]
>
> texttexttexttext
>texttext
>
> >[tester] 
> >[tester] RECEIVED: ==
> >[tester]
>
> texttexttexttextte
>xt
> >text
> >[tester] 
> >[tester] FAIL [GET /tester/JspDoc01.jsp HTTP/1.0] Failed Golden File
> > Comparison
> >
> >
> > However, I'm not sure the test is actually correct. It's failing because
> > of the empty elements being converted from  to , and from
> >  to . But, under XML, those are identical ways of saying the
> > same thing.
> >
> > If my analysis is correct, then the golden text needs to be changed, and
> > here is a patch for it. Otherwise, there's a deeper problem.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Catalina tester failure on JSP Document Parsing

[Steve Downey]

I'm seeing the following error on catalina's tester app, running it under 
Tomcat 5:

   [echo] - JSP Document Parsing -
   [tester] EXPECTED: ==
   [tester] 
texttexttexttexttexttext
   [tester] 
   [tester] RECEIVED: ==
   [tester] 
texttexttexttexttexttext
   [tester] 
   [tester] FAIL [GET /tester/JspDoc01.jsp HTTP/1.0] Failed Golden File 
Comparison


However, I'm not sure the test is actually correct. It's failing because of 
the empty elements being converted from  to , and from  to 
. But, under XML, those are identical ways of saying the same thing.

If my analysis is correct, then the golden text needs to be changed, and here 
is a patch for it. Otherwise, there's a deeper problem.


Index: golden/JspDoc01.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspDoc01.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 JspDoc01.txt
--- golden/JspDoc01.txt	18 Jul 2002 16:47:25 -	1.1.1.1
+++ golden/JspDoc01.txt	11 Sep 2002 22:10:51 -
@@ -1 +1 @@
-texttexttexttexttexttext
+texttexttexttexttexttext
\ No newline at end of file



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH] Enable manager app in catalina/tester deployment

[Steve Downey]

The tester app needs to unload and reload the tester webapp, but, of course, 
the manager app is not enabled by default.  This adds a tomcat-users.xml so 
that it can be deployed and run automatically. 

Now there are only a few failures left that I'm seeing.

The tomcat-users.xml should go into a new directory conf, under src. i.e.
jakarta-tomcat-catalina/tester/src/conf. 



Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/build.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 build.xml
--- build.xml	18 Jul 2002 16:47:24 -	1.1.1.1
+++ build.xml	11 Sep 2002 03:50:23 -
@@ -8,19 +8,20 @@
   
 
   
-  
+  
   
   
   
 
   
   
-  
+  
 
   
   
 
 
+
 
 
   
@@ -30,7 +31,6 @@
   
 
 
-
 
   
 
@@ -38,8 +38,11 @@
 
 
 
+
+  
+
+
 
-
 
 
 
@@ -56,7 +59,7 @@
 
 
 
 
@@ -87,7 +90,7 @@
 tofile="${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked05.txt"/>
 
 
-
+
 
 
 
@@ -132,6 +135,7 @@
   
 
 
+
   
 
 
@@ -145,6 +149,10 @@
 
 
 
+
+
+  
+
 
 
 




  




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH] catalina/tester fix some false positive and false negative tests

[Steve Downey]

On Tuesday 10 September 2002 10:56 pm, Steve Downey wrote:
> This patch builds tester against the servletapi-5 classes and repairs the
> URLs in the JSP examples used by tester. These were causing some false
> positve and false negative test results.


Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/build.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 build.xml
--- build.xml	18 Jul 2002 16:47:24 -	1.1.1.1
+++ build.xml	11 Sep 2002 02:54:01 -
@@ -8,14 +8,14 @@
   
 
   
-  
+  
   
   
   
 
   
   
-  
+  
 
   
   
@@ -56,7 +56,7 @@
 
 
 
 
@@ -87,7 +87,7 @@
 tofile="${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked05.txt"/>
 
 
-
+
 
 
 
Index: src/bin/tester.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/src/bin/tester.xml,v
retrieving revision 1.2
diff -u -w -r1.2 tester.xml
--- src/bin/tester.xml	9 Aug 2002 02:12:13 -	1.2
+++ src/bin/tester.xml	11 Sep 2002 02:54:01 -
@@ -8,11 +8,15 @@
 

   
-  
+  
   
   
   
-  
+  
+
+  
+
+  
 
 
   
@@ -110,33 +114,23 @@
   status="404"/>
 
 
-
 
 
 
-
 
 
 
-
 
 
 
-
 
-
-
-
-
 
 
@@ -203,7 +197,7 @@
 
 
 
 
   
@@ -1386,12 +1380,12 @@
 
 
 
 
 
 
   



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[5][PATCH] catalina/tester fix some false positive and false negative tests

[Steve Downey]

This patch builds tester against the servletapi-5 classes and repairs the URLs 
in the JSP examples used by tester. These were causing some false positve and 
false negative test results. 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java

[Steve Downey]

Broken build, please revert this. Log has no log method. 
(Second time today. Bound to happen once in while.)


On Tuesday 10 September 2002 03:40 pm, [EMAIL PROTECTED] wrote:
> jfarcand2002/09/10 12:40:25
>
>   Modified:catalina/src/share/org/apache/catalina/startup
> ContextConfig.java
>   Log:
>   Change the logging levelo from Info to Log when performance information
> are displayed.CVS:
> --


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina build.xml gump.xml

[Steve Downey]

Perhaps you could also change 
>
back to target="deploy", since you deleted the catalina.target property?

On Tuesday 10 September 2002 01:26 pm, [EMAIL PROTECTED] wrote:
> bobh2002/09/10 10:26:17
>
>   Modified:.build.xml gump.xml
>   Log:
>   - Larry Isaacs suggests that using an additional target is more
>   typical way to handle this situation (different build paths for gump
>   vs other build.xml)
>
>   Revision  ChangesPath
>   1.7   +10 -3 jakarta-tomcat-catalina/build.xml
>
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-catalina/build.xml,v
>   retrieving revision 1.6
>   retrieving revision 1.7
>   diff -u -r1.6 -r1.7
>   --- build.xml   10 Sep 2002 15:53:38 -  1.6
>   +++ build.xml   10 Sep 2002 17:26:17 -  1.7
>   @@ -11,9 +11,6 @@
>  
>  
>
>   -  
>   -  
>   -
>  
> value="${basedir}/../jakarta-servletapi-5"/>
>   @@ -46,6 +43,16 @@
>   description="Build and deploy all components">
>Target: Catalina - Deploy ...
>
>   +Target: Webapps - Deploy ...
>   +
>   +  
>   +
>   +   +   +   depends="deploy-static"
>   +   description="Build and deploy all components">
>   +Target: Catalina - Deploy ...
>   +
>Target: Webapps - Deploy ...
>
>  
>
>
>
>   1.8   +1 -2  jakarta-tomcat-catalina/gump.xml
>
>   Index: gump.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-catalina/gump.xml,v
>   retrieving revision 1.7
>   retrieving revision 1.8
>   diff -u -r1.7 -r1.8
>   --- gump.xml10 Sep 2002 16:16:54 -  1.7
>   +++ gump.xml10 Sep 2002 17:26:17 -  1.8
>   @@ -10,8 +10,7 @@
>  
>org.apache.catalina
>
>   -
>   -  
>   +
>  reference="home"/>
>  mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

[5][PATCH]JSP examples now at different URI

[Steve Downey]

Rather than being under /examples/jsp/, they're now under /jsp-examples/. The 
plugin needs to be aware of the full URI, but everything else is context 
relative. 


? .classpath
? .cvsignore
? .project
Index: jsr152/examples/WEB-INF/web.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 web.xml
--- jsr152/examples/WEB-INF/web.xml	27 Aug 2002 13:16:52 -	1.1.1.1
+++ jsr152/examples/WEB-INF/web.xml	6 Sep 2002 18:41:11 -
@@ -198,7 +198,7 @@
   
  Protected Area
 	 
- /jsp/security/protected/*
+ /security/protected/*
 	 
 	 DELETE
  GET
@@ -217,8 +217,8 @@
   FORM
   Example Form-Based Authentication Area
   
-/jsp/security/protected/login.jsp
-/jsp/security/protected/error.jsp
+/security/protected/login.jsp
+/security/protected/error.jsp
   
 
 
Index: jsr152/examples/WEB-INF/classes/servletToJsp.java
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/WEB-INF/classes/servletToJsp.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 servletToJsp.java
--- jsr152/examples/WEB-INF/classes/servletToJsp.java	27 Aug 2002 13:16:53 -	1.1.1.1
+++ jsr152/examples/WEB-INF/classes/servletToJsp.java	6 Sep 2002 18:41:11 -
@@ -9,7 +9,7 @@
 	try {
 	// Set the attribute and Forward to hello.jsp
 	request.setAttribute ("servletName", "servletToJsp");
-	getServletConfig().getServletContext().getRequestDispatcher("/jsp/jsptoserv/hello.jsp").forward(request, response);
+	getServletConfig().getServletContext().getRequestDispatcher("/jsptoserv/hello.jsp").forward(request, response);
 	} catch (Exception ex) {
 	ex.printStackTrace ();
 	}
Index: jsr152/examples/error/err.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/error/err.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 err.jsp
--- jsr152/examples/error/err.jsp	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/error/err.jsp	6 Sep 2002 18:41:11 -
@@ -12,7 +12,7 @@
 
 		if (request.getParameter("name") == null) {
 	%>
-	<%@ include file="/jsp/error/error.html" %>
+	<%@ include file="/error/error.html" %>
 	<%
 		} else {
 		  foo.setName(request.getParameter("name"));
Index: jsr152/examples/error/err.txt
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/error/err.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 err.txt
--- jsr152/examples/error/err.txt	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/error/err.txt	6 Sep 2002 18:41:11 -
@@ -12,7 +12,7 @@
 
 		if (request.getParameter("name") == null) {
 	%>
-	<%@ include file="/jsp/error/error.html" %>
+	<%@ include file="/error/error.html" %>
 	<%
 		} else {
 		  foo.setName(request.getParameter("name"));
Index: jsr152/examples/forward/forward.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/forward/forward.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 forward.jsp
--- jsr152/examples/forward/forward.jsp	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/forward/forward.jsp	6 Sep 2002 18:41:11 -
@@ -11,7 +11,7 @@
if (percent < 0.5) { 
 %>
 
-
+
 
 <% } else { %>
 
Index: jsr152/examples/forward/forward.txt
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/forward/forward.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 forward.txt
--- jsr152/examples/forward/forward.txt	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/forward/forward.txt	6 Sep 2002 18:41:11 -
@@ -11,7 +11,7 @@
if (percent < 0.5) { 
 %>
 
-
+
 
 <% } else { %>
 
Index: jsr152/examples/include/include.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/include/include.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 include.jsp
--- jsr152/examples/include/include.jsp	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/include/include.jsp	6 Sep 2002 18:41:11 -
@@ -14,7 +14,7 @@
 
 <%@ include file="foo.jsp" %>
 
-  by including the output of another JSP:
+  by including the output of another JSP:
 
 
 
Index: jsr152/examples/include/include.txt
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/include/include.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 include.txt
--- jsr152/examples/include/include.txt	27 Aug 2002 13:16:51 -	1.1.1.1
+++ jsr152/examples/include/include.txt	6 Sep 2002 18:41:11 -
@@ -14,7 +14,7 @@
 
 <%@ in

[5][PATCH]o.a.j.runtime.* import in gen'd JSP

[Steve Downey]

Generated JSP classes import org.apache.jasper.runtime.*. According to the JSP 
spec the default imports should be java.lang.*, javax.servlet.*, 
javax.servlet.jsp.* and javax.servlet.http.*.

The classes from o.a.j.runtime should be fully qualified, rather than 
imported. As far as I can tell, this is restricted to HttpJspBase and 
JspRuntimeLibrary. 



Index: Constants.java
===
RCS file: /home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.7
diff -u -w -r1.7 Constants.java
--- Constants.java	21 Aug 2002 16:21:56 -	1.7
+++ Constants.java	6 Sep 2002 04:46:08 -
@@ -74,7 +74,7 @@
 /**
  * The base class of the generated servlets. 
  */
-public static final String JSP_SERVLET_BASE = "HttpJspBase";
+public static final String JSP_SERVLET_BASE = "org.apache.jasper.runtime.HttpJspBase";
 
 /**
  * _jspService is the name of the method that is called by 
@@ -96,7 +96,6 @@
 	"javax.servlet.*", 
 	"javax.servlet.http.*", 
 	"javax.servlet.jsp.*", 
-	"org.apache.jasper.runtime.*", 
 };
 
 /**
 
Index: compiler/Generator.java
===
RCS file: /home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.91
diff -u -w -r1.91 Generator.java
--- compiler/Generator.java	6 Sep 2002 00:15:32 -	1.91
+++ compiler/Generator.java	6 Sep 2002 04:46:10 -
@@ -866,7 +866,7 @@
 		prepareParams(n);
 	}
 
-out.printin("JspRuntimeLibrary.include(request, response, " +
+out.printin("org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, " +
 pageParam );
 	printParams(n, pageParam, page.isLiteral());
 	out.println(", out, " + isFlush + ");");
@@ -986,15 +986,15 @@
 		java.lang.reflect.Method meth =
 		JspRuntimeLibrary.getReadMethod(bean, property);
 		String methodName = meth.getName();
-		out.printil("out.write(JspRuntimeLibrary.toString(" +
+		out.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString(" +
 			"(((" + beanName + ")pageContext.findAttribute(" +
 			"\"" + name + "\"))." + methodName + "(;");
 	} else {
 		// The object could be a custom action with an associated
 		// VariableInfo entry for this name.
 		// Get the class name and then introspect at runtime.
-		out.printil("out.write(JspRuntimeLibrary.toString" +
-			"(JspRuntimeLibrary.handleGetProperty" +
+		out.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString" +
+			"(org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty" +
 			"(pageContext.findAttribute(\"" +
 			name + "\"), \"" + property + "\")));");
 }
@@ -1011,18 +1011,18 @@
 	n.setBeginJavaLine(out.getJavaLine());
 
 	if ("*".equals(property)){
-		out.printil("JspRuntimeLibrary.introspect(" +
+		out.printil("org.apache.jasper.runtime.JspRuntimeLibrary.introspect(" +
 			"pageContext.findAttribute(" +
 			"\"" + name + "\"), request);");
 	} else if (value == null) {
 		if (param == null)
 		param = property;	// default to same as property
-		out.printil("JspRuntimeLibrary.introspecthelper(" +
+		out.printil("org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(" +
 			"pageContext.findAttribute(\"" + name + "\"), \"" +
 			property + "\", request.getParameter(\"" + param +
 			"\"), " + "request, \"" + param + "\", false);");
 	} else if (value.isExpression()) {
-		out.printil("JspRuntimeLibrary.handleSetProperty(" + 
+		out.printil("org.apache.jasper.runtime.JspRuntimeLibrary.handleSetProperty(" + 
 			"pageContext.findAttribute(\""  + name + "\"), \""
 			+ property + "\","); 
 		out.print(attributeValue(value, false, null, "null"));
@@ -1035,7 +1035,7 @@
 // optimize the case where the bean is exposed with
 // , much as the code here does for
 // getProperty.)
-out.printil("JspRuntimeLibrary.handleSetPropertyExpression(" +
+out.printil("org.apache.jasper.runtime.JspRuntimeLibrary.handleSetPropertyExpression(" +
 "pageContext.findAttribute(\""  + name + "\"), \""
 + property + "\", "
 + quote(value.getValue()) + ", "
@@ -1050,13 +1050,13 @@
 // that body.
 String valueVarName = generateNamedAttributeValue(
 value.getNamedAttributeNode() );
-out.printil("JspRuntimeLibrary.introspecthelper(" +
+out.printil("org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(" +
 "pageContext.findAttribute(\""  + name + "\"), \""
 + property + "\", "
 			+ valueVarName
 			+ ", null, null, false);");
 	} else 

Re: [4.1.10] New test milestone released

[Steve Downey]

There's a tester application in Catalina. Watchdog is the basis for the 
official test kit for the servlet and JSP specs. It's portable and generic.

Tester, on the other hand, is Tomcat specific. So putting Tomcat regression 
tests in it is very appropriate.


On Monday 02 September 2002 09:30 am, Ignacio J. Ortega wrote:
> > De: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> > Enviado el: 2 de septiembre de 2002 11:35
> >
> >
> > Thanks for the test case.
> > (maybe we could add all your nasty tests in the tester)
>
> tester? you are talking about watchdog ?
>
>
> Saludos ,
> Ignacio J. Ortega


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH] Build and run the catalina tester webapp against tomcat5

[Steve Downey]

This patch builds the catalina tester app in the context of tomcat-5, 
and installs and runs in the tmp directory, the same way that watchdog 
is run. I had to change a couple of the build variables in tester, to 
match some of the new ones. Also the examples web app is not expanded by 
default, so the 'touch' tasks had to be removed. Since the tomcat.base 
is rebuilt every run, the touches are redundant.

Unfortunately, many of the tester tests are failing. I don't know, yet, 
if they are bugs in tester or bugs in tomcat. But at least there's a 
baseline for comparison.

--
Steve Downey


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[Steve Downey]

I think you're missing the virtual server angle. There is NOT a 1-1 mapping
from ip address to DNS name. It's N-M. Even from the standpoint of a single
machine which received the request, there are many possible names for the IP
address.
So, given a request like:

   GET /pub/WWW/TheProject.html HTTP/1.1
   Host: www.w3.org

The only way to know which host the client intended is the Host header.

So, yes, this is spoofable, and should not be used as a security mechanism.
It was never designed to be one.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 2:50 PM
> To: Tomcat Developers List
> Subject: RE: Spec question: RE BUG 12052
>
>
> On Fri, 30 Aug 2002, Ignacio J. Ortega wrote:
>
> > > It may very well be a security issue ( and quite a big one !
> > > ). There are
> > > sites using all kinds of firewalls and settings in httpd.conf to
> > > restrict access to some hosts or ports ( say from internal network ).
> > > If Host: info is used for security checkings - it would be trivial to
> > > bypass some of this security.
> > >
> > > In particular - people may have servlets that check getServerName() to
> > > find if 'localhost' was used - the spec change will leave them with
> > > a huge hole ( any request with forged Host: localhost will pass ).
> > >
> > >
> >
> > Good Comment..
> >
> > In the particular case you have pointed, it's a user problem, a request
> > with Host: Localhost can be only be issued by someone with Remote
> > Ip=localhost..
>
> 'localhost' is just an example.
>
> The server may have 2 ip addresses, one visible from outside and one
> restricted by firewalls to only internal users ( and used for example
> for content updates ).
>
> In servlet 2.2 and 2.3, it is perfectly valid to use getServerName()
> and get the address that received the request. Since the servlet
> spec doesn't provide any 'declarative' support for this kind of
> access control - I think this is a valid solution. A firewall or
> routing can protect the internal address ( say 10.0.0.1 - on a network
> card connected only to the internal net, and a firewall restricting
> outside access to this IP ). In 2.4 this will fail ( opening potential
> holes ) and in addition this kind of check will be impossible to
> implement - since the address where the request was received will
> no longer be available.
>
>
> > So one can take some security measures to check the correctness of the
> > request..
>
> For example ?
>
>
> > All other use case i can imagine fall within the users problems, if the
> > correct VS has received the request, it's the Remote IP appropiate for
> > that VS? matchs port where the request has been received the port where
> > is suppoussed that the VS is?
>
> If by 'user' you mean the servlet author - I disagree. Such checks are
> prefectly reasonable and correct IMO.
>
>
> > But By far in the Journey we have learned something, never trust a Host
> > Header without first trust the Remote IP, at least for ultra-secure
> > apps..
>
> Well, the remoteIP is much more difficult to test - if you're a big
> organization you may have dozens of internal IPs. And most people do trust
> their firewalls to restrict access to a particular IP, I've seen this
> kind of setup in several cases ( where you use a special interface
> for internal users ).
>
>
> > And another thing, i wonder if it would be appropiate to check if a
> > request came from the (at least) correct port before dispatching it to
> > the VS.. at least within TC, and check if Apache2 is taking any measures
> > to be certain of this fact..
>
> The comment in apache sugest that Host shouldn't be trusted. If they
> started to trust it sudenly - they should at least modify the comment
> and explain how is this trust justified.
>
> Host is sent by the user - it is trivial to forge. The port and host that
> actually receives the request are pretty safe and difficult to trick,
> especially if a firewall is used in front.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: HTTP Host Request header and TC Connectors

[Steve Downey]

My understanding is that this is really a client issue, rather than server. By 
the time a connector gets it, it's too late to do much about it.

A little bit of research indicates that the user agents I have about will put 
the IP address in the Host header if the URI is specified by IP. That seems 
the only reasonable thing to do. The name of the host in that case is the IP 
address. 

I suppose that if you were doing something bizzare like HTTP over a unix 
domain socket you wouldn't have a host name of any kind. But that's pretty 
far out there. 

But, on the TC side, I don't think the connector should rewrite the header if 
it's empty.

On Wednesday 28 August 2002 12:26 pm, Ryan Lubke wrote:
> Hi,
>
> Looking for a little input from the HTTP gurus here.
>
> Given the following:
>
>"If the requested URI does not include an Internet host
> name for the service being requested, then the Host header
> field MUST be given with an empty value."
>
> So, I'm looking for other interpretations of what the above means.
>
> My interpretation at this point is the serviced targeted by the
> request URI is identified via an IP address vs a host name, that
> the Host request header will be sent but with an empty value.
>
> Does anyone agree/disagree?
>
> The reason I ask is that if an empty Host header is sent to Tomcat, and
> a redirect is sent back, the value of the Location header is useless,
> i.e.  http:///index.jsp.
>
> I'm trying to determine if this is a problem with the client
> implementation's interpretation of the spec, or a problem with Tomcat.
>
> Thanks,
>
> -rl


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jasper 2 class files

[Steve Downey]

However, in the context of JspC, it's a problem to map them to the same
package and class name. The custom URLClassLoader works within the JSP
engine, but the general servlet class loader doesn't know about those rules.
So when it sees those entries in web.xml, it will map all hello.jsp files,
no matter where they reside, to org.apache.jsp.hello_jsp.



> -Original Message-
> From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 21, 2002 7:54 PM
> To: Tomcat Developers List
> Subject: Re: Jasper 2 class files
>
>
> Yes, you can have two JSP pages with the same name but in
> different directories
> and everything will work fine even though they have the same
> package and class name.
> This is because a custom URLClassLoader is created for each
> individual JSP page.
> That class loader only loads the one java class for that one JSP page.
>
> For example:
>
> /myapp/this/hello.jsp
> /muapp/that/hello.jsp
>
> The class files will end up in:
>
> $CATALINA_BASE/work/Standalone/localhost/myapp/this/hello.class
> $CATALINA_BASE/work/Standalone/localhost/myapp/that/hello.class
>
> Since two different URLClassLoaders are used Jasper can
> load each of the above two classes even though they have
> the same package and class name.
>
> The old methods Jasper used for loading java classes generated for JSP
> pages was very inefficient.  The above change simplified Jasper and
> improved its performance by 25%.
>
> Regards,
>
> Glenn
>
> John Trollinger wrote:
> > Greg,
> >
> > I took this off of the bug tracking because it is not a bug and I
> > thought there are people a lot smarter than me in this mailing list that
> > could help answer you questions.
> >
> > I do not know how jasper differentiates between hello.jsp and
> > /anydir/hello.jsp when the both compile to a class
> > org.jasper.jsp.hello_jsp but it does work...
> >
> > My hello.jsp in the root dir prints hello Jasper world and my hello.jsp
> > in the subdir prints hello john world.  It works without a hitch..
> > (notice that I have removed the .java files for the 2 hello world files
> > and it did not regenerate them)
> >
> > Here is my file list
> >
> > Directory of C:\appserver\Tomcat\jspcache
> >
> > 08/21/2002  02:19 PM  .
> > 08/21/2002  02:19 PM  ..
> > 08/21/2002  11:47 AM 3,496 date_jsp.java
> > 08/21/2002  11:52 AM 2,975 hello_jsp.class
> > 08/21/2002  11:51 AM 2,883 index_jsp.class
> > 08/21/2002  11:51 AM 1,863 index_jsp.java
> > 08/21/2002  01:27 PM  subdir
> >4 File(s) 11,217 bytes
> >
> >  Directory of C:\appserver\Tomcat\jspcache\subdir
> >
> > 08/21/2002  01:27 PM  .
> > 08/21/2002  01:27 PM  ..
> > 08/21/2002  11:47 AM 3,334 date2_jsp.java
> > 08/21/2002  11:52 AM 2,970 hello_jsp.class
> >
> > Here is my jsp.xml
> >
> > 
> >
> > 
> > org.apache.jsp.date_jsp
> > org.apache.jsp.date_jsp
> > 
> >
> > 
> > org.apache.jsp.hello_jsp
> > org.apache.jsp.hello_jsp
> > 
> >
> > 
> > org.apache.jsp.date2_jsp
> > org.apache.jsp.date2_jsp
> > 
> >
> > 
> > org.apache.jsp.hello_jsp
> > org.apache.jsp.hello_jsp
> > 
> >
> > 
> > org.apache.jsp.date_jsp
> > /date.jsp
> > 
> >
> > 
> > org.apache.jsp.hello_jsp
> > /hello.jsp
> > 
> >
> > 
> > org.apache.jsp.date2_jsp
> > /subdir/date2.jsp
> > 
> >
> > 
> > org.apache.jsp.hello_jsp
> > /subdir/hello.jsp
> > 
> >
> > 
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
>
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jasper 2 class files

[Steve Downey]

Bingo! It can't!

{BTW, it shouldn't be org.jasper.x, as that's Paul Jasper's site,
whoever he is}

What should be happening with JspC [and in the JspServlet IMO] is:
/hello.jsp => org.apache.jsp.hello_jsp in {output}/hello_jsp.java
/subdir/hello.jsp => org.apache.jsp.subdir.hello_jsp in
{output}/subdir/hello_jsp.java

with the resultant web.xml fragment:


org.apache.jsp.hello_jsp
org.apache.jsp.hello_jsp


org.apache.jsp.subdir.hello_jsp
org.apache.jsp.subdir.hello_jsp


org.apache.jsp.hello_jsp
/hello.jsp


org.apache.jsp.subdir.hello_jsp
/subdir/hello.jsp


Then they can be compiled by an ordinary  ant task, and warred and
deployed in any servlet container.

Now, why might you want to do this?

The resultant WAR file can be put into a container that doesn't have JSP or
tools.jar support. It's great for embedded applications. Much lower
overhead, and more predictable response. It's also great for QA. You test
exactly the bits that get shipped.


> -Original Message-
> From: John Trollinger [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 21, 2002 3:16 PM
> To: 'Tomcat Developers List'
> Subject: RE: Jasper 2 class files
>
>
> If you take the generated class files and war them up and just call them
> as servlets how does the classloader differentiate
> /org.jasper.jsp.hello_jsp from /subdir/org.jasper.jsp.hello_jsp.  I can
> see how it does it when a JSP file exists but if you just move the
> generated files over I don't see how the classloader could figure this
> out?
>
> If this is in your web.xml how does it know one hello_jsp from the other
> without the jsp pages there and without going through jasper?
>
>   
>   org.apache.jsp.hello_jsp
>   org.apache.jsp.hello_jsp
>   
>
>   
>   org.apache.jsp.hello_jsp
>   /subdir/hello.jsp
>   
>
> -Original Message-
> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 21, 2002 2:56 PM
> To: Tomcat Developers List
> Subject: Re: Jasper 2 class files
>
> Is jspcache the place that Tomcat is looking for generated classes? If
> so,
> then the custom JSP classloader is doing its magic.
>
> The java and class files produced by the JspC command line compiler
> should be
> able to be jared up and placed into the WEB-INF directory, like any
> other
> servlet.  And the web.xml then maps the jsp URIs to servlets.
>
> Jasper 1 could do this, I provided some of the patches to make it work.
>
> The real test is to take all of the output from JspC and create a WAR
> file
> from it. Without the base jsp files. This WAR should operate in ANY
> servlet
> container.
>
>
> On Wednesday 21 August 2002 02:22 pm, John Trollinger wrote:
> > Greg,
> >
> > I took this off of the bug tracking because it is not a bug and I
> > thought there are people a lot smarter than me in this mailing list
> that
> > could help answer you questions.
> >
> > I do not know how jasper differentiates between hello.jsp and
> > /anydir/hello.jsp when the both compile to a class
> > org.jasper.jsp.hello_jsp but it does work...
> >
> > My hello.jsp in the root dir prints hello Jasper world and my
> hello.jsp
> > in the subdir prints hello john world.  It works without a hitch..
> > (notice that I have removed the .java files for the 2 hello world
> files
> > and it did not regenerate them)
> >
> > Here is my file list
> >
> > Directory of C:\appserver\Tomcat\jspcache
> >
> > 08/21/2002  02:19 PM  .
> > 08/21/2002  02:19 PM  ..
> > 08/21/2002  11:47 AM 3,496 date_jsp.java
> > 08/21/2002  11:52 AM 2,975 hello_jsp.class
> > 08/21/2002  11:51 AM 2,883 index_jsp.class
> > 08/21/2002  11:51 AM 1,863 index_jsp.java
> > 08/21/2002  01:27 PM  subdir
> >4 File(s) 11,217 bytes
> >
> >  Directory of C:\appserver\Tomcat\jspcache\subdir
> >
> > 08/21/2002  01:27 PM  .
> > 08/21/2002  01:27 PM  ..
> > 08/21/2002  11:47 AM 3,334 date2_jsp.java
> > 08/21/2002  11:52 AM 2,970 hello_jsp.class
> >
> > Here is my jsp.xml
> >
> > 
> >
> > 
> > org.apache.jsp.date_jsp
> > org.apache.jsp.date_jsp
> > 
> >
> > 
> > org.apache.jsp.hello_jsp
> > org.apache.jsp.hello_jsp
> > 
> >
> > 
> > org.apache.

Re: Jasper 2 class files

[Steve Downey]

Is jspcache the place that Tomcat is looking for generated classes? If so, 
then the custom JSP classloader is doing its magic.

The java and class files produced by the JspC command line compiler should be 
able to be jared up and placed into the WEB-INF directory, like any other 
servlet.  And the web.xml then maps the jsp URIs to servlets.

Jasper 1 could do this, I provided some of the patches to make it work.

The real test is to take all of the output from JspC and create a WAR file 
from it. Without the base jsp files. This WAR should operate in ANY servlet 
container. 


On Wednesday 21 August 2002 02:22 pm, John Trollinger wrote:
> Greg,
>
> I took this off of the bug tracking because it is not a bug and I
> thought there are people a lot smarter than me in this mailing list that
> could help answer you questions.
>
> I do not know how jasper differentiates between hello.jsp and
> /anydir/hello.jsp when the both compile to a class
> org.jasper.jsp.hello_jsp but it does work...
>
> My hello.jsp in the root dir prints hello Jasper world and my hello.jsp
> in the subdir prints hello john world.  It works without a hitch..
> (notice that I have removed the .java files for the 2 hello world files
> and it did not regenerate them)
>
> Here is my file list
>
> Directory of C:\appserver\Tomcat\jspcache
>
> 08/21/2002  02:19 PM  .
> 08/21/2002  02:19 PM  ..
> 08/21/2002  11:47 AM 3,496 date_jsp.java
> 08/21/2002  11:52 AM 2,975 hello_jsp.class
> 08/21/2002  11:51 AM 2,883 index_jsp.class
> 08/21/2002  11:51 AM 1,863 index_jsp.java
> 08/21/2002  01:27 PM  subdir
>4 File(s) 11,217 bytes
>
>  Directory of C:\appserver\Tomcat\jspcache\subdir
>
> 08/21/2002  01:27 PM  .
> 08/21/2002  01:27 PM  ..
> 08/21/2002  11:47 AM 3,334 date2_jsp.java
> 08/21/2002  11:52 AM 2,970 hello_jsp.class
>
> Here is my jsp.xml
>
> 
>
>   
>   org.apache.jsp.date_jsp
>   org.apache.jsp.date_jsp
>   
>
>   
>   org.apache.jsp.hello_jsp
>   org.apache.jsp.hello_jsp
>   
>
>   
>   org.apache.jsp.date2_jsp
>   org.apache.jsp.date2_jsp
>   
>
>   
>   org.apache.jsp.hello_jsp
>   org.apache.jsp.hello_jsp
>   
>
>   
>   org.apache.jsp.date_jsp
>   /date.jsp
>   
>
>   
>   org.apache.jsp.hello_jsp
>   /hello.jsp
>   
>
>   
>   org.apache.jsp.date2_jsp
>   /subdir/date2.jsp
>   
>
>   
>   org.apache.jsp.hello_jsp
>   /subdir/hello.jsp
>   
>
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: jasper package

[Steve Downey]

The compiler driver and classloader used by tomcat does a lot of magic to
get it to work. All jsp files named, for example, index.jsp, will be
compiled to a class named org.apache.jsp.index$jsp.java. It will be in a
directory with the same name as the directory of the jsp file, but that's
not represented in the package name.

The classloader knows where the class file will reside, and then strips out
everything but the filename part of the URI, prepends org.apache.jsp to it,
and loads that class.

The base VM classloader CAN NOT load the generated class files. So debugging
with an IDE that doesn't have special hacks is a bit difficult. Even if you
can convince it to load servlets and debug that code, convincing it to set a
breakpoint in some class named org.apache.jsp.index$jsp, and leaving it to
figure out which one, is usually impossible.

Unless things have changed recently, then go ahead and ignore all this. I
know this applied for 4.0.3.

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 1:28 AM
> To: Tomcat Developers List
> Subject: Re: jasper package
> 
> 
> 
> 
> On Tue, 20 Aug 2002, [gb2312] Yunfeng Hou wrote:
> 
> > Date: Tue, 20 Aug 2002 13:13:14 +0800 (CST)
> > From: "[gb2312] Yunfeng Hou" <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: jasper package
> >
> > > A desire to do this in the first place probably
> > > comes from wanting to use
> > > unpackaged classes without importing them -- which
> > > is both against the JSP
> > > spec and is also frowned on in general by the Java
> > > compiler in JDK 1.4 and
> > > later.  You're MUCH better off putting your classes
> >
> > No, I want this because I need it to debug my
> > generated class file at runtime. Currently, jasper
> > will always generate class in org.apache.jsp. For
> > example, /abc/test.jsp will have class in
> > $scratchDir/abc, and /abc/def/test.jsp will be
> > generated in $scratchDir/abc/def, with the same
> > package - org.apache.jsp! I can not even compile these
> > classes, do you think it a good design?
> >
> > Or, what I need is compile and debug, I do not need
> > that flexibility to specify package name, at least, I
> > think jasper should support this: these jsps will have
> > package name org.apache.jsp.abc and
> > org.apache.jsp.abc.def respectively.
> >
> 
> The Java compiler used by Tomcat doesn't have any problems compiling the
> sources that are currently being generated.  What compiler are you trying
> to use that has problems with it?  That's where your problem really
> appears to lie.
> 
> >
> > Yunfeng Hou
> >
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 
> 

<>
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: jasper package

[Steve Downey]

For the command line compiler, I've found it very useful. It specifies the
base package for the compiled jsp pages. By matching that with the directory
that the pages are output into, I can then point an ant javac task at them
and validate that everything compiles correctly, as part of an automated
build.

That is, /index.jsp would go into
${output}/com/netfolio/compiled_jsp/index.java, and /dir/index.jsp would go
into ${output}/com/netfolio/compiled_jsp/dir/index.java. So compiling them
is just a matter of a plain compile of the ${output} directory.

When JspC is working, that is. Haven't checked recently, but it's been
broken as often as not.

The runtime jsp compiler produces, or used to produce, java files that
aren't suitable for compiling as a batch. The package didn't match up with
the directory name. It simplified class reloading, IIRC, though.


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 6:11 PM
> To: Tomcat Developers List
> Subject: Re: jasper package
>
>
>
>
> On Mon, 19 Aug 2002, [gb2312] Yunfeng Hou wrote:
>
> > Date: Mon, 19 Aug 2002 11:35:17 +0800 (CST)
> > From: "[gb2312] Yunfeng Hou" <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: jasper package
> >
> > Jasper has command line option to set package name,
> > but not true for JspServlet, I made some change to
> > give user a chance to set the packageName in the
> > servlet init parameter.
> >
>
> Personally, I think supporting this at all is a *really* bad idea ... the
> JSP spec is very clear that the container is free to put the generated
> classes in whatever package it wants to (even different ones for different
> pages), so it seems very counter-productive to allow a user to tie
> themselves to a particular version of the JSP page compiler on a
> particular container that happens to implement this kind of option.
>
> A desire to do this in the first place probably comes from wanting to use
> unpackaged classes without importing them -- which is both against the JSP
> spec and is also frowned on in general by the Java compiler in JDK 1.4 and
> later.  You're MUCH better off putting your classes into packages and
> explicitly importing them.
>
> Craig McClanahan
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote:
> My understanding - the HTTP spec doesn't ( and can't ) define a complete
> list of headers supporting multiple values. That's impossible given that
> additional headers are supported.
>

The spec does exactly that. It enumerates the processing for the headers it 
defines. In section 5.3, "Unrecognized header fields are treated as 
entity-header fields." [section 5.3]  

In section 7.1, Entity Header Fields
   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient and MUST be forwarded by
   transparent proxies.

extension-header field-value is not defined as being a comma separated list, 
so it shouldn't be treated as such.

The on point case would be a webdav server running inside a servlet container. 
The webdav protocol actually does define a header that contains a list of 
values,  the DAV header. So should the webdav servlet expect the 
extension-header to be parsed for it? It might be nice, but I can't see that 
it's required.

> If the servlet spec requires getHeader() to return the 'concatenated value
> for multi-headers' - then the spec can't be implemented.
> If it requires getHeaders() to split headers that are multi-value and
> were sent concatenated - it can't be implemented ( and it's an API bug )
> It can be done only for the list of headers defined in the spec.
>
Can't be implemented is a little strong. After all, Tomcat used to pass this 
test. The old connector used to parse out the Accept-Languages header, so as 
to get the correct locale. I'd bet anything that the fact that this was 
visible via getHeaders() is why the test is written the way it is. Tomcat was 
actually used as a reference. 

But, API bug is what I was arguing for originally. With getHeader and 
getHeaders as speced, an application has no way of getting at the headers as 
sent.  The key is the 'list of headers defined in the spec'. The HTTP spec is 
affirmative on which headers cant contain values separated by commas. 

see list at end


> Returning whatever was found in the original request is IMO the only
> reasonable solution. I doesn't think apache ( or other servers )
> are spliting/merging received headers either.
>
I'm looking at httpd. It looks like it does merge received headers. That is, 
Accept-Language:A, Accept-Language:B gets combined into Accept-Language:A,B.  
Then ap_table_get() returns a single string, with all of the values. There is 
no API equivalent to getHeaders().

> The user application should use getHeaders() and split each header ( or
> merge them ) if it knows a header is multi-value.
>
> Well, there is a trick that can be used in deciding to split/merge:
> if the user calls getHeader("Foo"), and we have multiple Foo headers,
> then we can concatenate them and return the result.
>

That seems to be, effectively, what httpd does.

> If the user calls getHeaders("Foo") and we have headers with ',', then
> we split them. ( if he would call getHeaders("Date") - it would be
> his error ).
>
> However that's a bad solutuion - many apps call getHeaders() for
> all headers ( like request dump, etc ).
>
> Costin

Headers which can have a list of values, according to RFC 2616:
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Accept-Ranges
Allow
Cache-Control
Connection
Content-Encoding
Content-Language
Expect
If-Match
If-None-Match
Pragma
Proxy-Authenticate
TE
Trailer
Transfer-Encoding
Upgrade
Vary
Via
Warning
WWW-Authenticate

Accept-Ranges, Vary and WWW-Authenticate are response headers, and should not 
be part of a request.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Sunday 18 August 2002 08:39 am, Remy Maucherat wrote:
> Steve Downey wrote:
> > On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
> >>Steve Downey wrote:
> >
> > 
> >
> >>>The real problem, for the servlet spec implementation, is that not just
> >>>getHeaders() is affected. getHeader() must be also. getHeader, if there
> >>>are multiple values, needs to return the same thing as the first value
> >>>returned by getHeaders(), not the whole header from the first of
> >>> multiple headers.
> >>
> >>Sorry, but no. The opposite statement doesn't work.
> >>getHeader MUST return the first header line, unless in the case there
> >>are multiple headers with the same name in the client message, in which
> >>case you would know that they can be parsed/combined at will.
> >>
> >>Since it is too complex and inefficient to implement that, I'd leave it
> >>at that, and let the application handle the cases where the client is
> >>having some fun.
> >>
> >>Remy
> >
> > Given:
> > H:A,B
> > H:C
> >
> > getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'',
> > as it does now, can't be right. It introduces semantic differences
> > between multiple headers and comma-separated lists where their must be
> > none.
>
> Yes, it is right.
>
> Consider:
> H: A, B
>
> In that case, getHeader() has to return "A, B" since it is not known if
> this header is comma separated, as per the spec definition.
>

Ah. That's where we're going in separate directions. I'm assuming that it is 
known. The HTTP spec defines which headers are comma separated. So it's just 
a matter of checking against that list in order to know how to treat multiple 
values. According to the current servlet spec we have to, since we need to 
parse out the values for headers that are comma separated lists. 
getHeaders("Date") should not break apart the date into two values.

> In the case:
> H: A, B
> H: C
>
> Well, you have multiple choices, all of which are valid.
> - you may want to return the same thing as above, which means you return
> "A, B"
> - you can also return "A"
>
> Returning "A, B, C" is incorrect, as you have to return the first value
> of the header.
> Since implementing the first option is easier, I'd leave the current
> behavior.
>
> getHeaders indicate that the header is comma separated, so it should be
> parsed. This is not currently done, but indeed it should be done.
> Hacking MimeHeaders can result in a correct *and* efficient implementation.
>

getHeaders() by itself doesn't tell you that the header is comma separated. 
getHeaders("Date") should give you "Wed, 15 Nov 1995 06:25:24 GMT", not 
{"Wed", "15 Nov 1995 06:25:24 GMT"}. 



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
> Steve Downey wrote:

> >
> > The real problem, for the servlet spec implementation, is that not just
> > getHeaders() is affected. getHeader() must be also. getHeader, if there
> > are multiple values, needs to return the same thing as the first value
> > returned by getHeaders(), not the whole header from the first of multiple
> > headers.
>
> Sorry, but no. The opposite statement doesn't work.
> getHeader MUST return the first header line, unless in the case there
> are multiple headers with the same name in the client message, in which
> case you would know that they can be parsed/combined at will.
>
> Since it is too complex and inefficient to implement that, I'd leave it
> at that, and let the application handle the cases where the client is
> having some fun.
>
> Remy
Given:
H:A,B
H:C

getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'', as it 
does now, can't be right. It introduces semantic differences between multiple 
headers and comma-separated lists where their must be none. 

The problem is that the client has no way of telling if it's supposed to use 
getHeader or getHeaders. Other than saying that if it's possible for there to 
be multiple values, you have to use getHeaders.

IAC, why must getHeader return the first header line? It's documented to 
return 'the first head  in the request', or 'a String containing the 
value of the requested header'.  If getHeaders() returns 'all the values of 
the specified request header', and returns ``A'' rather than ``A,B'', then 
it's inconsistent for getHeader to return ``A, B''.

If a servlet really wants to do the parsing itself, then getHeader only gets 
it part of the headers, and it has no way of getting all of the header lines, 
since getHeaders() doesn't do that, according to the interpretation of the 
spec embodied in Watchdog, the basis for the TCK. 

Complex and inefficient might be a reason for _changing_ the spec. It's a bad 
reason for not implementing the spec. Also, I don't think it's that bad. The 
cases where multiple values are allowed is denumerable. So it comes down to 
creating an enumerator that can run seamlessly over the values in distinct 
header lines. 

Now, I'll admit this is all a bit on the language-lawyerish 
angels-dancing-on-pins side. But this is the reference implementation, and it 
is currently failing the servlet test suite.  

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote:
> Steve Downey wrote:
> > On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> >>Patrick Luby wrote:
> >>>Steve,
> >>>
> >>>Your assessment is correct: an aggregate header like:
> >>>
> >>>  header1: val1, val2
> >>>
> >>>should be converted to this for the HttpRequest:
> >>>
> >>>  header1: val1
> >>>  header1: val2
> >>
> >>No, this is not correct.
> >>
> >>You are allowed to do that only if the application knows it makes sense
> >>to do so (ie, only when it call getHeaders).
> >
> > If it is to be done, it should be done based on what the HTTP/1.1 spec
> > defines. The application needs to expect the possibility of multiple
> > values for all of the headers that allow them. Or just ask for the first
> > one. Parsing the header line into values probably shouldn't be left to
> > the application, although it is at the moment.
>
> I gave you the HTTP/1.1 answer.
>
> For Header H: A,B
> If A,B
> is semantically equivalent to:
> H: A
> H: B
> then you can parse for the comma.
>
> So since you can't know what the application considers to be
> semantically equivalent, the fact that it calls getHeaders is a big
> hint, and you can do the comma parsing.
>
> Please read the HTTP specification.
>

I keep a copy handy, for just such an occasion. However, my reading is someone 
different from yours. I think this is the relevant section  [RFC 2616, 
section 4.2], that describes what happens when multiple headers are sent:

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

So it's saying the opposite:
H:A
H:B

MUST be semantically equivalent to
H:A,B

as long as H is defined to have be a comma separated list. If it doesn't, it 
seems the result is undefined.

Now, the spec refers to not changing the semantics, but the MUST means that it 
is a requirement for the implementation. In other words, if combining the two 
headers into one comma separated list, for headers with a #(values) content 
model, changes the semantics, the implementation is non-conformant. The 
specification does not require that the implementation guess at the semantics 
an application believes apply, the specification defines the semantics that 
will apply.

The real problem, for the servlet spec implementation, is that not just 
getHeaders() is affected. getHeader() must be also. getHeader, if there are 
multiple values, needs to return the same thing as the first value returned 
by getHeaders(), not the whole header from the first of multiple headers.

 
 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote:
> Remy,
>
> Remy Maucherat wrote:
> > No, this is not correct.
> >
> > You are allowed to do that only if the application knows it makes sense
> > to do so (ie, only when it call getHeaders).
> >
> > Some code to do that should be added in the adapter.
>
> This makes more sense than my original thoughts since the Watchdog
> failures are only happening in tests that invoke the getHeaders() method.
>

I suspect that the tests are not strong enough. There are other cases that 
aren't handled correctly, but aren't being tested for. Let's take the 'worst' 
case:

AcceptLanguage: en-us, ga-us;q=0.7
AcceptLanguage: x-redneck:q=0.01

getHeader("AcceptLanguage") ought to return "en-us", and three values ought to 
be returned through the enumerator getHeaders("AcceptLanguage"), {"en-us, 
"ga-us;q=0.7", "x-redneck:q=0.01"}.

This is sort of an oddball corner case, as any real client would likely send 
either one header or three. But it is an allowable case.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> Patrick Luby wrote:
> > Steve,
> >
> > Your assessment is correct: an aggregate header like:
> >
> >   header1: val1, val2
> >
> > should be converted to this for the HttpRequest:
> >
> >   header1: val1
> >   header1: val2
>
> No, this is not correct.
>
> You are allowed to do that only if the application knows it makes sense
> to do so (ie, only when it call getHeaders).
>

If it is to be done, it should be done based on what the HTTP/1.1 spec 
defines. The application needs to expect the possibility of multiple values 
for all of the headers that allow them. Or just ask for the first one. 
Parsing the header line into values probably shouldn't be left to the 
application, although it is at the moment.

> Some code to do that should be added in the adapter.
>

Do you mean in the implementation of HttpServletRequest? I was thinking of 
doing the work in MimeHeaders. Perhaps subclassing MimeHeaders into 
Http11Headers, in order to allow other RFCHeaders? Certainly 
Http11Protocol knows what kind of headers it's parsing. 

> > Tomcat 4 used to do this conversion correctly but then it stopped doing
> > the conversion a few months ago.
> >
> > This should be fixed as it is Servlet spec non-compliance. However, I am
> > not sure where the parsing of headers is now performed in Tomcat?
> >
> > Can anyone point Steve to where this header parsing of the ServerSocket
> > input stream is being done?
>
> No, this musn't be done there, as it would screw up many headers. Please
> read the chapter on multivalued headers in the HTTP/1.1 spec.
>

Right, at the lowest level, headers are being handled generically. Something 
needs to be aware of the semantics of HTTP/1.1 headers.

> Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Friday 16 August 2002 09:43 pm, Patrick Luby wrote:

> Tomcat 4 used to do this conversion correctly but then it stopped doing
> the conversion a few months ago.
>
I'll bet dollars to donuts that it was exactly when Coyote was brought in as 
the connector, replacing the older o.a.c.connector.http.HttpProcessor.
Looking at it, it does a lot more detailed parsing of the HTTP headers while 
receiving the request. Coyote does a lot more lazy evaluation, holding 
everything in MessageBytes for as long as possible. This saves on unnecessary 
object creation and GC. 

> This should be fixed as it is Servlet spec non-compliance. However, I am
> not sure where the parsing of headers is now performed in Tomcat?
>

This shouldn't be handled as part of parsing headers off the wire. I think it 
should probably be handled in org.apache.tomcat.util.http.MimeHeaders, when 
the value, or values, is/are actually requested. 

Header names can be mapped to different content models. This might improve 
performace in getIntHeader and getDateHeader.X-headers and unknown headers 
should probably get mapped to TEXT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

Are you sure? Well, of course you're sure. What I mean is, is this a 
good interpretation of the spec?

The spec is not crystal clear on this point [SRV.4.3], as it discusses 
multiple headers with the same name, and multiple values for headers, 
but that seems to be within context of multiple headers. And in the API 
description [SRV.15.1.3], it discusses the contrary case, where a header 
such as Accept-Language may be sent multiple times, rather than being 
sent as a comma separated list.

The problem is, I don't see a good way of disambiguating, for example, a 
date header and a multiple value header. Not without being aware of the 
content models for all of the spec'd http headers. Or possibly just the 
list that allows for multiple values.

The underlying implementation is o.a.t.util.MimeHeader. It parses, in a 
fairly generic way, RFC822 style headers from MessageBytes. The results 
are passed through untouched in the various wrappers and facades. Unless 
I missed something.

If Tomcat 4 did this until a few months ago, I'll take a look at the old 
code.

Patrick Luby wrote:

> Steve,
>
> Your assessment is correct: an aggregate header like:
>
>   header1: val1, val2
>
> should be converted to this for the HttpRequest:
>
>   header1: val1
>   header1: val2
>
> Tomcat 4 used to do this conversion correctly but then it stopped 
> doing the conversion a few months ago.
>
> This should be fixed as it is Servlet spec non-compliance. However, I 
> am not sure where the parsing of headers is now performed in Tomcat?
>
> Can anyone point Steve to where this header parsing of the 
> ServerSocket input stream is being done?
>
> Patrick
>
> Steve Downey wrote:
>
>> Watchdog now merges headers, by design. ie (from the checking message)
>> Modified logic to send duplicate headers as one aggregated header vs. 
>> two headers:
>>
>>   header1: val1
>>   header1: val2
>>
>>-will now be-
>>
>>   header1: val1, val2
>>
>> Due to this, it looks like a couple of tests are failing. 
>> GetHeadersTest and HttpServletRequestWrapperGetHeadersTest.
>> GetHeadersTest looks for two Accept-Language headers, en-us and 
>> ga-us. It does work if they are sent as
>> Accept-Language:en-us
>> Accept-Language:ga-us
>>
>> But, being sent as:
>> Accept-Language:en-us, ga-us
>>
>> it is presented to the servlet as ONE header, with the value "en-us, 
>> ga-us"
>>
>> However, I'm not sure that it shouldn't be. Parsing a multivalued 
>> header is not only diffcult, it seems to depend on which header is 
>> being parsed. Certainly full interpretation is very dependent on the 
>> header, e.g.
>> Accept-Language: da, en-gb;q=0.8, en;q=0.7
>> Date: Wed, 15 Nov 1995 06:25:24 GMT
>>
>> The first has three values, the second has one. Interpretation 
>> depends on the name of the header. I don't believe the 
>> Request.getHeaders() mechanism should try and interpret the values 
>> after the :.
>>
>>
>>
>>
>> -- 
>> To unsubscribe, e-mail:   
>> <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: 
>> <mailto:[EMAIL PROTECTED]>
>
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Watchdog aggregation of headers may be incorrect

[Steve Downey]

Watchdog now merges headers, by design. ie (from the checking message)
Modified logic to send duplicate headers as one aggregated header vs. two 
headers:

  header1: val1
  header1: val2

   -will now be-

  header1: val1, val2

Due to this, it looks like a couple of tests are failing. GetHeadersTest and 
HttpServletRequestWrapperGetHeadersTest. 

GetHeadersTest looks for two Accept-Language headers, en-us and ga-us. It does 
work if they are sent as
Accept-Language:en-us
Accept-Language:ga-us

But, being sent as:
Accept-Language:en-us, ga-us

it is presented to the servlet as ONE header, with the value "en-us, ga-us"

However, I'm not sure that it shouldn't be. Parsing a multivalued header is 
not only diffcult, it seems to depend on which header is being parsed. 
Certainly full interpretation is very dependent on the header, e.g.
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Date: Wed, 15 Nov 1995 06:25:24 GMT

The first has three values, the second has one. Interpretation depends on the 
name of the header. I don't believe the Request.getHeaders() mechanism should 
try and interpret the values after the :.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH] Fix the JUnit tests in Catalina

[Steve Downey]

Steve Downey wrote:

>This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. 
>Now 'ant test' succeeds.
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>




Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.17
diff -u -r1.17 build.xml
--- catalina/build.xml  15 Aug 2002 13:56:31 -  1.17
+++ catalina/build.xml  16 Aug 2002 17:50:09 -
@@ -15,7 +15,7 @@
   
   
   
-  
+  
   
 
   
Index: catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 BaseDirContextTestCase.java
--- catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java   18 Jul 
2002 16:47:31 -  1.1.1.1
+++ catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java   16 Aug 
+2002 17:50:10 -
@@ -139,8 +139,7 @@
  * directory context.
  */
 protected static final String topLevelNames[] =
-{ "images", "jsp", "servlets", "META-INF", "WEB-INF" };
-
+{ "index.jsp", "jakarta-banner.gif", "tomcat.gif", "tomcat-power.gif", 
+"META-INF", "WEB-INF" };
 
 /**
  * The set of names that should be present in the WEB-INF
@@ -247,7 +246,7 @@
 // Look up the WEB-INF entry
 Object webInfEntry = context.lookup("WEB-INF");
 assertNotNull("Found WEB-INF entry", webInfEntry);
-assert("WEB-INF entry is a DirContext",
+assertTrue("WEB-INF entry is a DirContext",
webInfEntry instanceof DirContext);
 DirContext webInfContext = (DirContext) webInfEntry;
 
@@ -303,7 +302,7 @@
 // Look up the WEB-INF entry
 Object webInfEntry = context.lookup("WEB-INF");
 assertNotNull("Found WEB-INF entry", webInfEntry);
-assert("WEB-INF entry is a DirContext",
+assertTrue("WEB-INF entry is a DirContext",
webInfEntry instanceof DirContext);
 DirContext webInfContext = (DirContext) webInfEntry;
 
@@ -353,20 +352,20 @@
 while (ne.hasMore()) {
 
 Object next = ne.next();
-assert("list() returns NameClassPair instances",
+assertTrue("list() returns NameClassPair instances",
next instanceof NameClassPair);
 NameClassPair ncp = (NameClassPair) next;
 
-assert("Name '" + ncp.getName() + "' is expected",
+assertTrue("Name '" + ncp.getName() + "' is expected",
isListed(ncp.getName(), list));
 
 if (isDirContext(ncp.getName())) {
-assert("Class '" + ncp.getClassName() + "' is '" +
+assertTrue("Class '" + ncp.getClassName() + "' is '" +
contextClassName + "'",
contextClassName.equals(ncp.getClassName()));
 }
 
-assert("Relative is 'true'", ncp.isRelative());
+assertTrue("Relative is 'true'", ncp.isRelative());
 
 }
 
@@ -391,30 +390,30 @@
 while (ne.hasMore()) {
 
 Object next = ne.next();
-assert("listBindings() returns Binding instances",
+assertTrue("listBindings() returns Binding instances",
next instanceof Binding);
 Binding b = (Binding) next;
 
-assert("Name '" + b.getName() + "' is expected",
+assertTrue("Name '" + b.getName() + "' is expected",
isListed(b.getName(), list));
 
 if (isDirContext(b.getName())) {
-assert("Class '" + b.getClassName() + "' is '" +
+assertTrue("Class '" + b.getClassName() + "' is '" +
contextClassName + "'",
contextClassName.equals(b.getClassName()));
 }
 
-assert("Relative is 'true'", b.isRelative());
+assertTrue("Relative is 'true'", b.isRelative());
 

[5][PATCH] Fix the JUnit tests in Catalina

[Steve Downey]

This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. 
Now 'ant test' succeeds.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] Config

[Steve Downey]

>
>
>> 
>>
>> What do you think ? 
>
>
> I love it :)
>
> This really seems to pick the best APIs for the job.
> It's a good idea to use JNDI for configuration storing indeed, as it 
> allows enterprise scale deployments, and seems generally better suited 
> than JMX.
>
> Remy
>
>
To the extent that JNDI and JMX do the jobs they were designed for, it 
makes perfect sense. JNDI is all about locating and retrieving data by 
name.  JMX is mostly a runtime mechanism for component management.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml

[Steve Downey]

(jta.present == true) and (full.dist=true or tyrex.present)

If I'm reading this correctly, this won't build the Tyrex dependant components 
if jta is not present, EVEN IF full.dist is requested. That means you can set 
full.dist on and NOT get a full dist.

If full.dist is set true, then the build should fail if some component is 
missing. At least it's that way for all other components.

On Wednesday 14 August 2002 05:39 pm, [EMAIL PROTECTED] wrote:
> bobh2002/08/14 14:39:42
>
>   Modified:catalina build.xml
>   Log:
>   make Tyrex only compile if JTA is present (this was breaking my build.)
>
>   Revision  ChangesPath
>   1.16  +7 -4  jakarta-tomcat-catalina/catalina/build.xml
>
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
>   retrieving revision 1.15
>   retrieving revision 1.16
>   diff -u -r1.15 -r1.16
>   --- build.xml   13 Aug 2002 16:26:11 -  1.15
>   +++ build.xml   14 Aug 2002 21:39:42 -  1.16
>   @@ -348,10 +348,13 @@
>
>
>
>   -  
>   -
>   -
>   -  
>   +  
>   +
>   +
>   +   
>   +   
>   +
>   +  
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Steve Downey]

[EMAIL PROTECTED] wrote:

>
>
>
>Well, CatalinaService is not 'completed' - just started :-)
>
>What we do in 3.3 is have 2 setters, and at execute check if:
>- if only one is set, the other takes this value
>- if none is set, use discovery ( locate the base from the CLASSPATH )
>- if both are set, use that.
>
>If you want to implement this - great, if not I'll do it when I find 
>time ( or I need it ).
>
See attached patch. I added a method setHomeAndBase() and a couple of 
booleans to see if they were set via setters.

>
>>The next problem was that the task runs in VM. Ant's xercesImpl chokes 
>>on parsing the schemas. This is the known dependency on Xerces 2.0.1. 
>>Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly 
>>requirement.
>>
>
>Well... As I said, it is a major problem if we can't use any JAXP but 
>require a specific parser and version...
>
>One solution is to remove schema validation ( and validation in general )
>from tomcat runtime, and have a separate validation program that
>can be run on a webapp _before_ it is deployed on tomcat. 
>
>There are many other solutions - but requiring anyone using tomcat5
>to use Xerces2.0.1 and subjecting every user to hugely expensive
>and redundant validation is the worse.
>
With any luck, by the time Tomcat5 is released, XML parsers with good 
schema support will be more common, so it won't be such an issue. It is 
unfortunate that the current release of Xerces is broken.

Removing validation from the servlet container reference implementation 
somehow seems, well, wrong. I agree that doing validation at deployment 
is reasonable, rather than for each startup. Something like what the jsp 
compiler does.

>
>
>
 will run it in process, which gives problems with 
the shared environment. In particular I get:
 [java] INFO: Digester for server.xml created 587
 [java] java.lang.LinkageError: loader constraints violated when 
linking org/xml/sax/XMLReader class

 will run it out of process, but the next task won't 
execute until tomcat finishes. Not good either.

I think the right answer is either Launcher, which uses [daemon] to 
start a background process, or Cactus, which introduces another 
dependency, and may still have some issues with the ant environment 
leaking through.

>
>
>Regarding output redirection, I think Patrick mentioned adding some
>methods in the startup code to redirect programmatically.
>
>Costin
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




Index: catalina/src/share/org/apache/catalina/startup/CatalinaService.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v
retrieving revision 1.2
diff -u -w -r1.2 CatalinaService.java
--- catalina/src/share/org/apache/catalina/startup/CatalinaService.java 10 Aug 2002 
16:54:15 -  1.2
+++ catalina/src/share/org/apache/catalina/startup/CatalinaService.java 14 Aug 2002 
+21:39:39 -
@@ -158,11 +158,34 @@
 
 }
 
+private boolean homeSet = false;
+private boolean baseSet = false;
+  
 public void setHome( String s ) {
 System.setProperty("catalina.home", s );
+homeSet = true;
+}
+  
+public void setBase( String s ) {
 System.setProperty("catalina.base", s );
+baseSet = true;
 }
 
+
+protected void setupBaseAndHome() {
+if (homeSet && baseSet) return;
+if (!homeSet && !baseSet) return;
+if (homeSet && !baseSet) {
+System.setProperty("catalina.base", System.getProperty("catalina.home"));
+return;
+}
+if (!homeSet && baseSet) {
+System.setProperty("catalina.home", System.getProperty("catalina.base"));
+return;
+}
+}
+  
+
 public void setUseNaming( boolean b ) {
 useNaming=b;
 }
@@ -196,6 +219,7 @@
 // make sure the thread loader is set
 log.info("Running tomcat5");
 Thread.currentThread().setContextClassLoader( 
this.getClass().getClassLoader());
+setupBaseAndHome();
 if (starting) {
 load();
 start();



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Steve Downey]

Jean-francois Arcand wrote:

>
>
> Steve Downey wrote:
>
>> Thanks for pointing the tomcat5 task out. I'm trying to reimplement 
>> with that, and have run into a couple of snags.
>>
>> First is that o.a.c.startup.CatalinaService doesn't distinguish 
>> between catalina.home and catalina.base. setHome() actually sets both 
>> of them. Adding a setBase() is trivial, but it affects the semantics 
>> of initialization. Any current client expects both to be set by a 
>> call to setHome(),  and just moving the setProperty to setBase() 
>> breaks that. Of course if the setProperty("catalina.base",s) is left 
>> in setHome(), then initialization is order dependent. For now, and I 
>> just added a setBase() and ignored the problem.
>>
>> The next problem was that the task runs in VM. Ant's xercesImpl 
>> chokes on parsing the schemas. This is the known dependency on Xerces 
>> 2.0.1. Replacing the xercesImpl.jar in Ant fixed that, but that seems 
>> an ugly requirement. 
>
>
> The problem should occurs only with Xerces 2.0.2. Is 2.0.2 bundle with 
> ANT 1.5? If you try with the current Xerces nightly build, it should 
> work. This is a big paint because Xerces 2.0.2 seems to be used 
> everywhereThe only solution will be to set the schema validation 
> off, or detect the Xerces version and throw an exception before 
> starting parsing a file.
>
Yes, it's Xerces 2.0.2. At least that's what the README claims. From 
what I understand it's not sufficient to turn schema validation off, 
although I haven't verified that.  Is there a good way of detecting 
which version of Xerces is present?




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Steve Downey]

Thanks for pointing the tomcat5 task out. I'm trying to reimplement with 
that, and have run into a couple of snags.

First is that o.a.c.startup.CatalinaService doesn't distinguish between 
catalina.home and catalina.base. setHome() actually sets both of them. 
Adding a setBase() is trivial, but it affects the semantics of 
initialization. Any current client expects both to be set by a call to 
setHome(),  and just moving the setProperty to setBase() breaks that. Of 
course if the setProperty("catalina.base",s) is left in setHome(), then 
initialization is order dependent. For now, and I just added a setBase() 
and ignored the problem.

The next problem was that the task runs in VM. Ant's xercesImpl chokes 
on parsing the schemas. This is the known dependency on Xerces 2.0.1. 
Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly 
requirement.

In any case, after doing that, Catalina service starts up, but doesn't 
seem to be able to find the servlet apis to compile JSP pages. As an 
added irritation, stdout isn't redirected to catalina.out, and it is 
quite noisy.

So, my current patch may not be the best possible, but it does have the 
advantage of working.

I think it will make more sense to use the launcher as the basis for a 
task to run tomcat. Running it in process leads to a lot of state 
leaking over. For testing I think it's safer to run it as much as 
possible in its own environment.

This is what I was using for the tomcat5 task:


  
  
  

  
  

  
  
 
  
  
 
  

   




[EMAIL PROTECTED] wrote:

>On Wed, 14 Aug 2002, Steve Downey wrote:
>
>>This patch starts up a copy of tomcat with the watchdog war files, runs 
>>watchdog against it, and shuts down tomcat afterwards. It uses the Launcher 
>>to run tomcat in the background, and puts the webapps, work, logs and conf 
>>directories in a tmp dir so as not to muck up the build.
>>
>>The only part I really don't like is that there isn't a good way to know that 
>>tomcat is up and running, so for now there's a sleep between launching tomcat 
>>and starting the watchdog tests.
>>
>
>For tomcat5 ? Well, it is - if you use the task ( take a look at 
>build2.xml ). The task will start tomcat inprocess, and will return 
>after all the startup is done ( and continue with the next task ).
>
>( unless you have wait="true" )
>
>Costin
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Steve Downey]

This patch starts up a copy of tomcat with the watchdog war files, runs 
watchdog against it, and shuts down tomcat afterwards. It uses the Launcher 
to run tomcat in the background, and puts the webapps, work, logs and conf 
directories in a tmp dir so as not to muck up the build.

The only part I really don't like is that there isn't a good way to know that 
tomcat is up and running, so for now there's a sleep between launching tomcat 
and starting the watchdog tests.



Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.26
diff -u -w -r1.26 build.xml
--- build.xml	13 Aug 2002 16:59:12 -	1.26
+++ build.xml	14 Aug 2002 05:05:42 -
@@ -29,6 +29,8 @@
value="${basedir}/../jakarta-tomcat-jasper/jasper2"/>
   
+  
 
   
   
@@ -51,6 +53,7 @@
 
 
 
+
 
 
 
@@ -151,6 +154,66 @@
 
   
 
+  
+  
+
+  
+  
+
+
+
+
+  
+
+
+   
+
+
+   
+
+
+   
+
+
+  
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+
+	
+  
+
+
+
+
+
+   
+
+  
+  
+  
+  
+  
+  
+  
+  
+
+	
+  
+
+
+  
+
 
   
   



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] examples webapp and catalina unit tests

[Steve Downey]

The catalina unit tests depend on the examples webapp, which isn't part of the 
jakarta-tomcat-catalina repository. I believe Remy had suggested making the 
examples part of the servlet-api repo, but that isn't done.

Should the examples webapp be brought into the jakarta-tomcat-catalina repo, 
or should the testcase be rewritten, perhaps using the admin webapp?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH] Patch to BUILDING.txt to identify dependencies for optional components

[Steve Downey]

This patch to BUILDING.txt documents what the optional components enable in 
Tomcat, and where the build process expects to find things. 

? .project
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.17
diff -u -r1.17 BUILDING.txt
--- BUILDING.txt	13 Aug 2002 18:05:09 -	1.17
+++ BUILDING.txt	13 Aug 2002 18:39:02 -
@@ -81,8 +81,9 @@
   that you unpack "ldap.jar" and "jaas.jar" into the "lib" subdirectory of
   the JNDI directory, parallel to "jndi.jar".
 
-* This is optional with JDK 1.3 or later.
-
+* This is optional with JDK 1.3 or later. It is required for building
+  with full.dist=on. The build process expects this to be in
+  {base.path}/jndi-1.2.1. 
 
 (4) Download and Install the Xerces 2 Distribution
 
@@ -280,8 +281,11 @@
 
 http://java.sun.com/products/jdbc/download.html
 
-* Place the jar in a convenient location.
+* Place the jar in a convenient location. The build process expects it
+  in ${base.path}/jdbc2_0-stdext.
 
+* No Tomcat class depends on JDBC directly. Tyrex and commons-dbcp
+  depend on it, and it is distributed with a full distribution.
 
 (14) Download and Install an implementation of the JMX 1.0 specification. This
  can be either MX4J (http://mx4j.sourceforge.net) or Sun JMX 1.0 Reference 
@@ -311,7 +315,10 @@
 http://java.sun.com/products/javabeans/glasgow/jaf.html
 
 * Unpack the package into a convenient location so that it
-  resides in its own subdirectory.
+  resides in its own subdirectory. The build process expects this by
+  default to be in ${base.path}/jaf-1.0.1 
+
+* The Java Activation Framework is used by the JavaMail optional package.
 
 
 (16) Download and Install JavaMail 1.2
@@ -321,7 +328,10 @@
 http://java.sun.com/products/javamail/index.html
 
 * Unpack the package into a convenient location so that
-  it resides in its own subdirectory.
+  it resides in its own subdirectory. The build process expects this
+  by default to be in ${base.path}/javamail-1.2
+
+* JavaMail is used to provide JNDI named mail sessions.
 
 
 (17) Download and Install the JSSE 1.0.2 Reference Implementation
@@ -332,17 +342,25 @@
 http://java.sun.com/products/jsse/
 
 * Unpack the reference implementation into a convenient location so that
-  it resides in its own subdirectory.
+  it resides in its own subdirectory. The build expects this to be in
+  ${base.path}/jsse-1.0.2.
+
+* This is optional with JDK 1.4 and later.
+
+* Used to provide SSL and Certificate support in Catalina and in Connectors.
 
 
 (18) Download and Install the Java Transaction APIs
 
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
 
 http://java.sun.com/products/jta/
 
 * Unpack the package into a convenient location so that it resides in its
-  own subdirectory.
+  own subdirectory. By default, the Tomcat build expects this to be
+  {base.path}/jta-1_0_1a/
+
+* Used to provide JNDI named transaction factories.
 
 
 (19) Download and Install the Struts Binary Distribution
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.27
diff -u -r1.27 build.properties.default
--- build.properties.default	13 Aug 2002 16:52:19 -	1.27
+++ build.properties.default	13 Aug 2002 18:39:02 -
@@ -193,9 +193,9 @@
 
 
 # - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+jta.home=${base.path}/jta-1_0_1a
 jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
 
 
 # - JUnit Unit Test Suite, version 3.7 or later -



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Release numbering scheme and test releases

[Steve Downey]

  Milestones imply a series of goals to be met, not just when we feel 
like it, or every Tuesday. To be a milestone, there need to some 
objective criteria that everyone can agree have been met.

Don't get me wrong, I like frequent builds, I just hate to see a useful 
release engineering term get debased.


Remy Maucherat wrote:

> Hi,
>
> First, a simple vote about the version numbering scheme for Tomcat 5.0.
> I think the method used for Tomcat 4.1.x is working well and promotes 
> quality, although it certainly delayed the apprition of a stable build 
> of Tomcat 4.1.
> I propose keeping it for Tomcat 5.0.
>
> 
> +1 [ ] Tomcat 5 should use Tomcat 4.1 version numbering scheme and 
> release management
> -1 [ ] Tomcat 5 should use something else (to be decided later)
> 
>
> Although Tomcat 5 is still far from being feature complete (and won't 
> be in stable form until the servlet & JSP specs ship, at the 
> earliest), it could make sense to start releasing test milestones. The 
> build process works, and the binary works (to some extent; of course, 
> many features are missing and many refactorings still need to be made).
>
> The milestones will have a 5.0.x number, similar to the current 4.1.x 
> releases.
>
> 
> +1 [ ] Start releasing milestones for Tomcat 5.0 on a regular basis soon
> -1 [ ] No, later
> 
>
> Remy
>
>
> -- 
> To unsubscribe, e-mail: 
> 
> For additional commands, e-mail: 
> 
>
>





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Build notes

[Steve Downey]

The only snag is that 'ant download' doesn't download optional 
components. And some of them are optional the same way that brakes on a 
go-cart are optional. It'll work, just not quite the way you expect it to.

More importantly, any developer building Tomcat needs to build a full 
version, otherwise you run the risk of breaking parts of the build that 
you happen not to be building because you don't have the optional 
component that it depends on. And the build process is fairly quiet 
about those missing pieces.

Automating the download of optional components, however, is a bit 
tricky, as many of the optional components are behind Sun's license page.


Bob Herrmann wrote:

>Yea, I liked your script, this one builds Tomcat 5.
>
>BUILDING.TXT could almost just say "All you need is JDK1.4 and Ant1.5
>then just type 'ant' and a working Tomcat 5 development tree is built.
>(If you are behind a firewall, you may need to adjust proxy settings.)"
>
>This should be cross platform (haven't tested it on Win32.)
>
>Cheers,
>-bob
>
>
>
>
>
>
>
>
>   value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
>
>
>
>
>
> 
> 
>
>
>
>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>cvsRoot="${cvsroot}"
>dest="${apache.dir}"
>/>
>
>
>
>
>
> file="${base.path}/LICENSE" />
>
> target="download" />
>
> target="dist" />
>
>
>
>   
>
>On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
>
>>On August 6, 2002 01:01 pm, you wrote:
>>
>>>The main thing missing is a target which sets up the CVS repositories,
>>>so it's quite close to what we have now. Problem is, I'm not too happy
>>>at the idea of doing that automatically.
>>>
>>Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
>>it's well documented what it's doing, people should be OK with it.
>>
>>Ian
>>
>>
>>
>>  
>>
>>  
>>  
>>  >  value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
>>
>>  
>>  
>>   
>>  
>>
>>  
>>
>>  >  cvsRoot="${cvs.root}"
>>  dest="${apache.dir}"
>>  />
>>  >  cvsRoot="${cvs.root}"
>>  dest="${apache.dir}"
>>  />
>>  >  cvsRoot="${cvs.root}"
>>  dest="${apache.dir}"
>>  />
>>  
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

[Steve Downey]

On Monday 12 August 2002 03:22 pm, you wrote:

> After this patch, the build is slightly broken if Tyrex isn't available. It
> appears that compilation of  org/apache/naming/factory/TyrexFactory.java
> and TyrexResourceFactory are conditioned only on JTA. Patch to follow.

Patch is NOT to have full.dist=on in ~/build.properties. 

~/build.properties is nice when you're only building a group of related 
projects with the same environment. With unrelated projects, it's a source of 
much strangeness.

I worked with one guy who argued for an /etc/build.properties. Fortunately 
coworkers kept me for strangling him.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

[Steve Downey]

With patch actually attached ...

On Monday 12 August 2002 03:22 pm, you wrote:
> BUILDING.txt and the default build properties refer to an older version of
> the Java Transaction API. The current version is 1.0.1a, where the old
> version was 1.0.1. The are semantically the same, just documentation
> changes. The current version of the jta jar file is named jta.jar, rather
> than
> jta-spec1_0_1.jar
>
> I'm trying to get the Tomcat 5 build to be as smooth as possible out of the
> box. 'ant download' makes most of it very straightforward. For optional
> components, it's a little tougher, as many of them are behind license
> screens.
>
> Several of the APIs that Sun provides also don't define a directory for
> themselves, such as JNDI and JTA. For these I've always placed them in a
> directory with the same name as the zip file, sans .zip.
>
> After this patch, the build is slightly broken if Tyrex isn't available. It
> appears that compilation of  org/apache/naming/factory/TyrexFactory.java
> and TyrexResourceFactory are conditioned only on JTA. Patch to follow.


Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.14
diff -u -r1.14 BUILDING.txt
--- BUILDING.txt	7 Aug 2002 14:14:03 -	1.14
+++ BUILDING.txt	12 Aug 2002 19:11:06 -
@@ -337,12 +337,13 @@
 
 (18) Download and Install the Java Transaction APIs
 
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
 
 http://java.sun.com/products/jta/
 
 * Unpack the package into a convenient location so that it resides in its
-  own subdirectory.
+  own subdirectory. By default, the Tomcat build expects this to be
+  {base.path}/jta-1_0_1a/
 
 
 (19) Download and Install the Struts Binary Distribution
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.18
diff -u -r1.18 build.properties.default
--- build.properties.default	8 Aug 2002 05:47:01 -	1.18
+++ build.properties.default	12 Aug 2002 19:11:06 -
@@ -197,9 +197,9 @@
 
 
 # - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+jta.home=${base.path}/jta-1_0_1a
 jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
 
 
 # - JUnit Unit Test Suite, version 3.7 or later -



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version

[Steve Downey]

BUILDING.txt and the default build properties refer to an older version of the 
Java Transaction API. The current version is 1.0.1a, where the old version 
was 1.0.1. The are semantically the same, just documentation changes. The 
current version of the jta jar file is named jta.jar, rather than 
jta-spec1_0_1.jar 

I'm trying to get the Tomcat 5 build to be as smooth as possible out of the 
box. 'ant download' makes most of it very straightforward. For optional 
components, it's a little tougher, as many of them are behind license 
screens.

Several of the APIs that Sun provides also don't define a directory for 
themselves, such as JNDI and JTA. For these I've always placed them in a 
directory with the same name as the zip file, sans .zip.

After this patch, the build is slightly broken if Tyrex isn't available. It 
appears that compilation of  org/apache/naming/factory/TyrexFactory.java and 
TyrexResourceFactory are conditioned only on JTA. Patch to follow. 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH]commons-logging built without log4j/LogKit

[Steve Downey]

If you follow the directions in BUILDING.txt, it's not necessary to download 
log4j or LogKit.  BUILDING.txt asks for a nightly build of commons-logging, 
which would have been built against log4j and LogKit. If they aren't present 
at runtime, they won't be used as the implementation of commons-logging. But 
if they aren't present at build time, they can't be used. 

It's basically the same as, say, the JSSE for a Tomcat build. You need it to 
build SSL support, but if not present at runtime it just means that Tomcat 
can't do SSL.



On Thursday 08 August 2002 01:46 am, Patrick Luby wrote:
> Steve,
>
> Thanks for the patch. I just committed it.
>
> I assume that log4j and LogKit are required dependencies. Any chance
> that you could add those items to BUILDING.txt?
>
> Thanks,
>
> Patrick
>
> Steve Downey wrote:
> > The commons-logging package built by 'ant download' doesn't have support
> > for log4j or LogKit in it, unless the properties happen to be set outside
> > of jakarta-tomcat-5. This patch adds downloads for the released versions
> > of log4j and logkit.
> >
> >
> >
> > 
> >
> > ? .project
> > Index: build.properties.default
> > ===
> > RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
> > retrieving revision 1.17
> > diff -u -r1.17 build.properties.default
> > --- build.properties.default7 Aug 2002 14:14:03 -   1.17
> > +++ build.properties.default8 Aug 2002 04:54:58 -
> > @@ -122,8 +122,17 @@
> >  activation.jar=${activation.lib}/activation.jar
> >
> >  # - Log4j -
> > -log4j.home=${base.path}/log4j
> > -log4j.jar=${log4j.home}/log4j.jar
> > +log4j.home=${base.path}/jakarta-log4j-1.2.6
> > +log4j.lib=${log4j.home}
> > +log4j.jar=${log4j.lib}/dist/lib/log4j-1.2.6.jar
> > +log4j.loc=http://jakarta.apache.org/log4j/jakarta-log4j-1.2.6.tar.gz
> > +
> > +# - LogKit -
> > +logkit.home=${base.path}/LogKit-1.0.1
> > +logkit.lib=${logkit.home}
> > +logkit.jar=${logkit.lib}/logkit-1.0.1.jar
> > +logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logki
> >t/latest/LogKit-1.0.1-bin.tar.gz +
> >
> >  # - Jaxen ( required by taglibs/standard required by jasper ) -
> >  jaxen.home=${base.path}/jaxen-1.0-FCS
> > Index: build.xml
> > ===
> > RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
> > retrieving revision 1.18
> > diff -u -r1.18 build.xml
> > --- build.xml   7 Aug 2002 14:14:03 -   1.18
> > +++ build.xml   8 Aug 2002 04:54:59 -
> > @@ -492,6 +492,16 @@
> >  
> >  -->
> >  +
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +  
> > +
> > +
> >  
> >
> >
> >
> >
> > 
> >
> > --
> > To unsubscribe, e-mail:  
> > <mailto:[EMAIL PROTECTED]> For additional
> > commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [5][PATCH]commons-logging built without log4j/LogKit

[Steve Downey]

It's headed in the right direction, I think. But depending on CVS versions
of other projects _by_default_ is a bit on the scary side.



> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 08, 2002 1:32 AM
> To: Tomcat Developers List
> Subject: Re: [5][PATCH]commons-logging built without log4j/LogKit
>
>
> Now, like Costin, I'm starting to think that the 5.0 build is scary.
>
>
> - Original Message -
> From: "Steve Downey" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 07, 2002 10:00 PM
> Subject: [5][PATCH]commons-logging built without log4j/LogKit
>
>
> The commons-logging package built by 'ant download' doesn't have
> support for
> log4j or LogKit in it, unless the properties happen to be set outside of
> jakarta-tomcat-5. This patch adds downloads for the released versions of
> log4j and logkit.
>
>
>
>
> --
> --
> 
>
>
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [PATCH] JspC package names

[Steve Downey]

I think this has been fixed with the patch to correct bug 5471. That changes
how package names are generated in CommandLineContext. 

I'm glad to see someone else is using jspc. It's been broken so often, I
thought I was the only one.


> -Original Message-
> From: Mike Schrag [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] JspC package names
> 
> 
> In 4.0.1, JspC commandline tool is not making package names 
> that correspond to subdirectories in my context directory (i.e. I need
> "/help/testhelp.jsp" to become "help/testhelp.java" and be 
> "package help;").  There is a setOutputInDirs method on the
> CommandLineContext that seems like it should toggle this 
> feature.  I think I'm patching this in the right place... I 
> don't know for
> sure that setOutputInDirs is the correct attribute to "piggy 
> back" on, but regardless I think other people may find this capability
> useful.
> 
> Thanks a lot
> Mike Schrag
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [4.0.2] Bug list

[Steve Downey]

If 5644 is going to be fixed, then 5471 should be too. Right now, given
/index.jsp and /subdir/index.jsp, jspc will overwrite the first index.java
with the second. It also conflates them in web.xml. I've submitted a patch
to the list before. I've also just attached it to the bug report.

I also just noticed that jspc.sh doesn't use the value of JAVA_HOME to find
java. It expects it on the PATH, apparently. bug 6108.



> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 28, 2002 3:43 PM
> To: [EMAIL PROTECTED]
> Subject: [4.0.2] Bug list
> 
> 
> Hi,
> 
> I've just committed a text file in the 4.0 branch listing the 
> bugs that
> should be addressed before 4.0.2 Final is released.
> 
> I'll cut & paste it here, for people who may not want to check out the
> branch.
> 
> Remy
> 
> 
> Tomcat 4.0.2 Final bug status
> -
> 
> This document lists bug that should be addressed before 4.0.2 Final is
> released. None of these bugs are regression problems, so it should be
> acceptable to delay their resolution.
> 
> 
> 5647jk AJP13 connector will not pass 
> authentication requests
> 4793webapp mod_webapp connector doesn´t work
> 4930webapp java.io.StreamCorruptedException: Type 
> code out of range,
>is 0 with Apache WebApp module
> 5040webaap EOFException when talking from applet to servlet
>via mod_webapp
> 5201catalina   Persistent sessions & EJB Statefull
> 5402webapp WarpConnection raise IOException
> 5483jk I18N fails using AJP 1.3 with Tomcat 4.01
>final / Apache 1.3.22
> 5644jasper JspC produces badly formed classnames if first char
>is a digit
> 5735catalina   HTTP connector running out of processors 
> under heavy load
> 5752docs   Documentation: Resources link invalid on page
>http://jakarta.apache.org/tomcat/tomcat-4.0-doc
>/config/context.html
> 5760docs   Doc-bug: Inexact documented jars in "Class 
> Loader INFO"
> 5795catalina   Catalina Shutdown relies on localhost 
> causing problems
>in a Clustered Solaris environment
> 5820docs   Undocumented restriction on inoking manager webapp
> 5827catalina   DataInputStream.readInt returns wrong values
> 5899servlets   HTTP POST parameters ignored in CGIServlet.java
> 5905jasper JSP Document not correctly processed
> 6036webapp Problems with URI mapping
> 3509webapp Apache 1.3.20 & mod_webapp & Tomcat 4b7 
> HANGS under Win
> 5704servlets   CgiServlet corrupting images?
> 4518jasper load-on-startup is not working with jsp page
> 5759servlets   CGI servlet mapping by extension *.cgi 
> does not work
> 5988jasper Jasper Null Pointer Exception Error
> 
> 
> 
> FIXED? - 5330catalina   JNDI ENC context problem
> LATER - 5396installer  Tomcat start shortcut fails when 
> HTTPS is set
> FIXED - 5876catalina   HttpResponseBase broken
> FIXED - 5908catalina   java.lang.IllegalStateException: 
> zip file closed
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Bug 5471 - JspC broken when compiling webapps

[Steve Downey]

You may want this one, also. Turns out that jasper.sh is mildly broken on
HEAD. It doesn't grab the libraries in shared/lib or the classes in
shared/classes. 

I'm guessing that JspC isn't the most heavily exercised part of the system.


Index: jasper.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v
retrieving revision 1.5
diff -u -r1.5 jasper.sh
--- jasper.sh   2001/09/13 15:22:45 1.5
+++ jasper.sh   2001/12/19 00:10:39
@@ -35,7 +35,7 @@
   done

   JASPER_HOME_1=`dirname "$PRG"`/..
-  echo "Guessing JASPER_HOME from catalina.sh to ${JASPER_HOME_1}"
+  echo "Guessing JASPER_HOME from jasper.sh to ${JASPER_HOME_1}"
 if [ -d ${JASPER_HOME_1}/conf ] ; then
JASPER_HOME=${JASPER_HOME_1}
echo "Setting JASPER_HOME to $JASPER_HOME"
@@ -80,6 +80,10 @@
 done
 CP=$CP:"$JASPER_HOME/common/classes"
 for i in $JASPER_HOME/common/lib/*.jar ; do
+  CP=$CP:"$i"
+done
+CP=$CP:"$JASPER_HOME/shared/classes"
+for i in $JASPER_HOME/shared/lib/*.jar ; do
   CP=$CP:"$i"
 done


> -Original Message-
> From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 18, 2001 5:12 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
> 
> 
> I responsed in haste, without reading your patch carefully.  :(  My
> apologies.
> 
> I'll get the patch in, later.  Thanks.
> 
> 
> > Date: Tue, 18 Dec 2001 16:44:42 -0500
> > From: Steve Downey <[EMAIL PROTECTED]>
> > Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
> > To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> > MIME-version: 1.0
> > Delivered-to: mailing list [EMAIL PROTECTED]
> > Mailing-List: contact [EMAIL PROTECTED]; 
> run by ezmlm
> > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> > List-Post: <mailto:[EMAIL PROTECTED]>
> > List-Subscribe: <mailto:[EMAIL PROTECTED]>
> > List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> > List-Help: <mailto:[EMAIL PROTECTED]>
> > List-Id: "Tomcat Developers List" 
> > 
> > The patch doesn't mangle the class file name, just the 
> package name, so that
> > the resulting java file is put in a directory that matches 
> the path of the
> > jsp file. Just putting the java file in a subdirectory is 
> insufficient,
> > though. Unless the packages are different, there isn't a 
> way to disambiguate
> > the servlets that result from two index.jsp's in the web.xml file.
> > 
> > Example:
> > input
> > /index.jsp
> > /subdir/index.jsp
> > 
> > result
> > /index.java - contains class index
> > /subdir/index.java - contains class subdir.index
> > 
> > If the -p option is used, eg -p com.netfolio.jspservlets
> > /com/netfolio/jspservlets/index.java - contains class
> > com.netfolio.jspservlets.index
> > /com/netfolio/jspservlets//subdir/index.java - contains class
> > com.netfolio.jspservlets.subdir.index
> > 
> > 
> > 
> > > -Original Message-
> > > From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, December 18, 2001 4:37 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
> > > 
> > > 
> > > Believe or not, Jasper once mangled the file names in a way 
> > > similar to what
> > > is in the patch.  It was modified in response to a bug 
> > > (Bugzilla is currently
> > > unavailable, so I can't look up the bug number).  The filer 
> > > complained that
> > > for a file with deeply nested path, the resultant file name 
> > > is too long to
> > > work in Window, since there is a 250(?) character file name 
> > > limit there.
> > > 
> > > I think a better fix is not to mangle the path into the 
> file name, but
> > > to put the .java (and .class) files in a directory structure 
> > > that mirrors
> > > the .jsp structure.  This is how it work currently, for the 
> > > non -webapps
> > > case.
> > > 
> > > 
> > > > Date: Tue, 18 Dec 2001 15:47:25 -0500
> > > > From: Steve Downey <[EMAIL PROTECTED]>
> > > > Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps
> > > > To: "[EMAIL PROTECTED] (E-mail)" 
> > > <[EMAIL PROTECTED]>
> > > > MIME-version: 1.0
> > > > Delivered-to: mailing list [EMAIL PRO

RE: [PATCH] Bug 5471 - JspC broken when compiling webapps

[Steve Downey]

The patch doesn't mangle the class file name, just the package name, so that
the resulting java file is put in a directory that matches the path of the
jsp file. Just putting the java file in a subdirectory is insufficient,
though. Unless the packages are different, there isn't a way to disambiguate
the servlets that result from two index.jsp's in the web.xml file.

Example:
input
/index.jsp
/subdir/index.jsp

result
/index.java - contains class index
/subdir/index.java - contains class subdir.index

If the -p option is used, eg -p com.netfolio.jspservlets
/com/netfolio/jspservlets/index.java - contains class
com.netfolio.jspservlets.index
/com/netfolio/jspservlets//subdir/index.java - contains class
com.netfolio.jspservlets.subdir.index



> -Original Message-
> From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 18, 2001 4:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
> 
> 
> Believe or not, Jasper once mangled the file names in a way 
> similar to what
> is in the patch.  It was modified in response to a bug 
> (Bugzilla is currently
> unavailable, so I can't look up the bug number).  The filer 
> complained that
> for a file with deeply nested path, the resultant file name 
> is too long to
> work in Window, since there is a 250(?) character file name 
> limit there.
> 
> I think a better fix is not to mangle the path into the file name, but
> to put the .java (and .class) files in a directory structure 
> that mirrors
> the .jsp structure.  This is how it work currently, for the 
> non -webapps
> case.
> 
> 
> > Date: Tue, 18 Dec 2001 15:47:25 -0500
> > From: Steve Downey <[EMAIL PROTECTED]>
> > Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps
> > To: "[EMAIL PROTECTED] (E-mail)" 
> <[EMAIL PROTECTED]>
> > MIME-version: 1.0
> > Delivered-to: mailing list [EMAIL PROTECTED]
> > Mailing-List: contact [EMAIL PROTECTED]; 
> run by ezmlm
> > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> > List-Post: <mailto:[EMAIL PROTECTED]>
> > List-Subscribe: <mailto:[EMAIL PROTECTED]>
> > List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> > List-Help: <mailto:[EMAIL PROTECTED]>
> > List-Id: "Tomcat Developers List" 
> > 
> > This patch changes 
> CommandLineContext.getServletPackageName() to return a
> > package name based on the path to the JSP as well as the 
> package name
> > supplied on the command line.
> > 
> > Without a change like this, a webapp that has files with 
> the same name, such
> > as index.jsp, in more than one place is compiled 
> incorrectly, with both JSP
> > files being mapped to the same servlet.
> > 
> > With this patch, the java files are placed in the correct 
> directories, and
> > generation of web.xml works.
> > 
> > 
> > <><><><><><><><><><><><><><><><><><><><><>This electronic 
> mail transmission
> > may contain confidential information and is intended only 
> for the person(s)
> > named.  Any use, copying or disclosure by any other person 
> is strictly
> > prohibited.  If you have received this transmission in 
> error, please notify
> > the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
> >   
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[PATCH] Bug 5471 - JspC broken when compiling webapps

[Steve Downey]

This patch changes CommandLineContext.getServletPackageName() to return a
package name based on the path to the JSP as well as the package name
supplied on the command line.

Without a change like this, a webapp that has files with the same name, such
as index.jsp, in more than one place is compiled incorrectly, with both JSP
files being mapped to the same servlet.

With this patch, the java files are placed in the correct directories, and
generation of web.xml works.


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
  




bug5471.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 4545] New: - Webapp connector seg faults u nder an SSL connection

[Steve Downey]

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 02, 2001 9:29 AM
> To: Tomcat Developers List
> Cc: [EMAIL PROTECTED]
> Subject: RE: DO NOT REPLY [Bug 4545] New: - Webapp connector 
> seg faults
> u nder an SSL connection
> 
> 
> >> Environment is httpd 1.3.22, built with mod_ssl 2.8.5. The 
> >only changes to
> >> httpd.conf were to make the WebApp connection and 
> >WebAppDeploy of examples.
> >> 
> >> It looks like it's seg faulting on trying to get the ssl 
> key size in
> >> mod_webapp.c, at rec->ssld->size = atoi(ssl_tmp). I suspect that
> >> SSL_CIPHER_USEKEYSIZE isn't in the environment, which is 
> >where ssl_temp has
> >> just been read from.
> >
> >I will have a look to it... Has it is my bad...
> 
> Normal, you need to have the SSLVars exported by mod_ssl.
> 
> From :
> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ssl-howto.html
> 
> When using mod_jk with Apache & mod_ssl, it is essential to specify 
> "SSLOptions +StdEnvVars +ExportCertData" in the httpd.conf file. 
> 
> Otherwise, mod_ssl will not produce the neccessary 
> environment variables for
> mod_jk. 
> from (Tilo Christ <[EMAIL PROTECTED]>). 
> 

Requiring StdEnvVars is NOT a good thing, though. It adds a fair bit of
overhead to the SSL connection, which is why it was made an option. Most
httpd.confs will only turn it on for cgi and shtml. Tomcat wants it turned
on for everything.

For Apache 2.0, it should be possible to avoid this all. With mod_ssl a
standard component, it should be possible to use ap_table_get for
everything. Any other ssl implementation should support the same interface. 

<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Steve Downey]

"Train the user not to do that" is a cop out. If an application doesn't work
the way users expect, it's a problem with the application, not the user.
That's usability 101. 

If the user shouldn't bookmark the login page, they shouldn't ever be
exposed to the URI for the login page. That makes it impossible to bookmark.
The only URI that the user should see is the URI for the protected resource.



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 03, 2001 6:23 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839
> 
> Problem bookmarking login page
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> --
> --
>  Status|REOPENED|RESOLVED
>  Resolution||WONTFIX
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  
> 2001-10-03 15:23 ---
> The fact that you hd the same problems under WebLogic also 
> should have given you
> a hint that you might be mis-using this functionality :-).
> 
> Although the form login page (and form error page) are 
> physically contained in
> your web application archive, they should not be hyperlinked 
> to by any of your
> app's pages.  Most particularly, it should *not* be your welcome page.
> 
> If you (temporarily) switch your app to use BASIC 
> authentication instead, it
> should still work correctly - and there is no possibility to 
> bookmark the login
> page because there is no such thing.  If your app doesn't 
> work in this scenario,
> then you should modify it so that it can.
> 
> If you don't, then you're going to be dependent on 
> non-portable behavior of
> whatever container vendor happens to allow this technique to 
> work - the spec 
> doesn't require it.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: SCRIPT_NAME and PATH_INFO with extension mapping

[Steve Downey]

As far as I can tell, the HTTP and HTML specs are completely silent on this.
The CGI spec talks about PATH_INFO et al, but doesn't seem to address
extension mapping. 

As another datapoint, static content with Apache doesn't work if you append
path info to an HTML page, i.e.  http://www.foo.com/index.html/foo/bar,
doesn't deliver index.html.




> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 30, 2001 6:50 PM
> To: tomcat-dev
> Subject: SCRIPT_NAME and PATH_INFO with extension mapping
> 
> 
> on 9/30/01 5:47 PM, "[EMAIL PROTECTED]" 
> <[EMAIL PROTECTED]> wrote:
> 
> > the conclusion was that the HTTP spec is wrong and we should
> > follow the Servlet spec.
> 
> That is complete BS. The servlet spec shouldn't 'override' 
> what is defined
> in the HTTP spec unless absolutely necessary. This is definitely not a
> necessary case, but instead an act of stupidity.
> 
> > Workaround - declare each page with exact mappings in web.xml.
> 
> Making me specify each and every page in my webapp in the 
> web.xml is just
> plain BS.
> 
> I bet that a URL like this works:
> 
> http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar
> 
> I *know* that this URL works:
> 
> http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar
> 
> Essentially, what you are doing by removing this capability 
> is preventing
> the SCRIPT_NAME from having PATH_INFO and that is not right 
> according to the
> HTTP spec. I don't think that a Servlet container can 
> override the behavior
> of the HTTP spec and still claim HTTP compliance.
> 
> -jon
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Tomcat before Apache

[Steve Downey]

> -Original Message-
> From: Christopher Cain [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 17, 2001 2:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat before Apache
> 
> 
> 
> 
> "Pier P. Fumagalli" wrote:
> > 
> > Christopher Cain at [EMAIL PROTECTED] wrote:
> > >
> > >> I'm attaching a little C script that degradates the 
> process to a specified
> > >> user before execuing it. To compile do "gcc -O2 
> safexec.c -o safexec" and to
> > >> run, (for example catalina) do:
> > >>
> > >> safexec username $CATALINA_HOME/bin/catalina.sh start
> > >>
> > >> It's written for Solaris, but it should work also on 
> Linux (maybe some
> > >> compilation warning of some kind)... DO NOT INSTALL IT 
> W/ SUID PRIVILEGES,
> > >> otherwise anyone will be able to break into your machine 
> _easily_... 'K?
> > >
> > > My startup script (Linux) simply does this:
> > >
> > >  daemon --user nobody $CATALINA_HOME/bin/catalina.sh start
> > 
> > This is I believe Bergstein's daemontools?
> 
> To be honest, I'm not sure. It's how alot of the standard 
> init.d scripts
> are coded in Linux, so that's how I've also done mine. Whatever it is,
> it's installed by default on every Linux distro I've ever 
> used. Perhaps
> I could throw a small patch into RUNNING.txt with a one-liner for *nix
> users that the above is a safe way to put TC startup in a script file?
> Does Solaris include this "daemontools" by default as well?
> 
On Redhat, at least, daemon is a shell function that's sourced into the
init.d scripts. It does a few things, but in the end either executes the
daemon or does a 'su - $user -c $*', execing the daemon as the specified
user.

It also will nice the daemon if it's given a nice level.


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: FORM-based authentication idea

[Steve Downey]

> -Original Message-
> From: Michael Jennings [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 11:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: FORM-based authentication idea
> 
> 
> > The best way to think about form-based login is like this:
> >
> > * The login page is (in essence) part of the container,
> >   not the application.  Therefore, ...
> >
> > * The login page should *never* be referenced directly by any
> >   other application page, and ...
> >
> > * The login page should *never* be requested directly by the
> >   user.
> 
> How do you enforce that a particular URL should never be 
> asked for by a
> user?
Installing it under WEB-INF is one way. The container will then enforce the
prohibition. However, in general, not publishing the URL anywhere is
probably sufficient. It's not as though with form based login that the user
ever has to see the URL of the login form.

-SMD
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: [jtc] tabs policy??

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 24, 2001 7:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [jtc] tabs policy??
> 
> 
> On Sun, 24 Jun 2001, Justin Erenkrantz wrote:
> 
> > That just leads to formatting problems because people don't 
> understand
> > that.  If you must have tabs, they should be the same as 
> the indention 
> > level, not some factor of the indention level.  This 
> doesn't have to be 
> > complicated.  One tab == one indention level.
> 
> I'm not sure I understand how you reached that conclusion, but this is
> what causes all the curent problems ( and the reason for people to
> consider tabs as "evil" ).
> 
> Tab size is 8 - or at least used to be before the idea that you can
> "configure" this. What's "evil" is the fact that some editors 
> allow you to 
> change the size of the tab.
> 
> In a text you can have multiple indentation levels, and it's 
> true that on
> some typewriters you can use the TAB key to move to the next 
> indentation
> level 

On real typewriters, the TAB key (used for TABles) moved to the next TAB
stop, which could be anywhere on the line. It would make a nice thumping
noise when the carriage hit the stop, too. The notion that tabs == some
number of spaces is a modern aberration stemming from DECWriters having tab
stops every 8 spaces. They also, perversely, would execute a carriage return
when issued a newline.



<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Ways of Debugging tomcat itself..

[Steve Downey]

With netbeans, in particular, an important trick is to disable the inclusion
of its embedded tomcat in the executor and debugger. With 3.2, I think
that's the {library} keyword. It changed between 3.1 and 3.2, I believe.

Otherwise you're debugging the IDE, not the instance of Tomcat you're
building. 

Other than that, it's really straightforward. Add all the different source
trees to the filesystem, set up a cross compiler pointing to the build
directory, which needs to be mounted also, and the do builds as normal, or
by using Ant. 

Use org.apache.tomcat.startup.Main as the main class. Look at tomcat.sh for
the system defines to add also.


> -Original Message-
> From: Martin van den Bemt [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 14, 2001 6:40 PM
> To: jakarta-tomcat-dev
> Subject: Ways of Debugging tomcat itself..
> 
> 
> Hi,
> 
> Maby this question has been asked before, but I'm looking for 
> a good way to
> debug tomcat itself (not taling about servlets in specific). 
> The environment
> i'm using now is netbeans 3.2.
> Does anyone have tips on how to debug tomcat (except for 
> logging to the
> console, that one I know..).
> I would love to have an opinion / your experience with this. 
> Doesn't matter
> which environment you use or how you debug, it may be 
> interesting to put
> this in a document. If there is already some nice info on 
> this, please also
> let me know..
> 
> Mvgr,
> Martin van den Bemt
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Jasper34: Manglers

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 12:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Jasper34: Manglers
> 
> 
> On Sun, 10 Jun 2001, Glenn Nielsen wrote:
> 
> > Another advantage of jasper40 using a URLClassLoader for 
> each individual
> > JSP page is that you don't accumulate outdated classes in 
> the classloader 
> > that eat up JVM memory when a JSP is recompiled.  I haven't 
> looked at
> > jasper33, so please let me know if that is not a problem with it.
> 
> It is.
> 
> On a production site it isn't a big factor - there are not too many
> reloads. 
> 

Depends. I've done some content publishing work where JSPs are replaced
quite often while the engine is running. Of course, there are other ways of
accomplishing the same effect, for example including HTML fragments. But it
would turn out, often enough, that we'd need to inject some code into the
text. Usually something trivial, like a link to the secure side of the same
server, or iterating over a dynamic list. 

I think we'd end up with hundreds, maybe low Ks, of dead classes in memory.




<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: virus warnings and

[Steve Downey]

Mine, unfortunately for this list, isn't configured to be silent. It sends a
warning back to the sender. I'm trying to see if we can get it to not do
that for 'Precedence: Bulk' mail. 

It doesn't help that we've got about several developers following this list
and the users list.

Mea culpa, and I'm trying to get it fixed.

> -Original Message-
> From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: virus warnings and
> 
> 
> "Pier P. Fumagalli" wrote:
> > 
> > Jay Doggett at [EMAIL PROTECTED] wrote:
> > 
> > > Ok, good call. I had multiple mail rules for this list.
> > > I still think that virus posters should get expunged.
> > 
> > I didn't get any virus...
> > 
> > Pier
> 
> I also didn't get any virus, but our company mail servers may 
> filter silently
> these things, but that also means we (the ones that tell no 
> virus) cannot send
> these virus! 
> 
> Jean-frederic
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Jasper performance

[Steve Downey]

Given any reasonably timeframe for delivery on a new Jasper to production,
jdk 1.1 is likely to be three cycles behind. Supporting legacy systems can
only go so far. 

> -Original Message-
> From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 5:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Jasper performance
> 
> 
> I would like to propose that the new Jasper require jdk 1.2.
> The current version of jasper can be used by those who have jdk 1.1.x.
> Then we don't have to worry about jumping through hoops trying to
> get the new jasper to run both in 1.1 and 1.2, plus we can optimize
> for 1.2.  In addition JSP 1.2 will require jdk 1.2 or greater.
> 
> Regards,
> 
> Glenn
> 
> [EMAIL PROTECTED] wrote:
> > 
> > > Jasper performance has already been identified as an area needing
> > > improvement.
> > >
> > > Discussions and work on this has already started in the 
> main tomcat
> > > branch in CVS jakarta-tomcat/proposals/jasper34, but this may be
> > > moving to the CVS repository jakarta-tomcat-jasper.
> > >
> > > This work just started recently, I don't know when it 
> will be ready.
> > 
> > It will take few months - it's not that easy.
> > 
> > We already added tag pooling in tomcat3.3, and that have a 
> significant
> > effect on performance if you are using tags - but that's just the
> > beginning.
> > 
> > The first step is to reorganize the code. Then we'll try to 
> make the code
> > generator more customizable ( probably by using XSLT for some of the
> > operations ). The real performance enhancement will come 
> when we start
> > tunning the generated code - there are many ideas around, 
> but we need the
> > refactoring first.
> > 
> > BTW, jasper will share most of the code for the 1.1 and 1.2 
> APIs, so all
> > enhancements will be available in both 3.x and 4.x ( and 
> other containers
> > as well ).
> > 
> > If you have ideas, code or opinions - please get involved, 
> we need you :-)
> > 
> > Costin
> > 
> > >
> > > Rickard Öberg wrote:
> > > >
> > > > Hi!
> > > >
> > > > We are using Tomcat/JBoss and are pleased with the 
> actual functionality.
> > > > What is killing us right now is the performance of the 
> code generated by
> > > > Jasper, especially when using taglibs in complex ways. 
> The generated
> > > > code is way too unoptimized.
> > > >
> > > > So, if this has not been asked before (in which case a 
> RTFA is ok,
> > > > although I've looked already), my question is:
> > > > When will Jasper be rewritten?
> > > > Are there any such projects underway now?
> > > > Have there been any discussions about this yet?
> > > > Am I the only one seeing this problem, or are more 
> people concernced
> > > > about it?
> > > >
> > > > Thanks,
> > > >   Rickard
> > > >
> > > > --
> > > > Rickard Öberg
> > > > Software Development Specialist
> > > > xlurc - Xpedio Linköping Ubiquitous Research Center
> > > > Author of "Mastering RMI"
> > > > Email: [EMAIL PROTECTED]
> > >
> > >
> 
> -- 
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: JNDI/LDAP realm

[Steve Downey]

As I understand it, you can rebind with different credentials, but you can't
have more than one set of credentials on the same connection. That means
either synchronizing on the ldap connection, and serializing login, or
having multiple connections and parallelizing login.

Now, this isn't a terrible issue if the code cleans up promptly when done
authenticating, but it is a resource contention issue. 

If the code doesn't clean up promptly, and relies on finalization, then it
will only fail under load. Usually in some horrible manner that will be
difficult to trace back to the root cause.


> -Original Message-
> From: John Holman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 14, 2001 5:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JNDI/LDAP realm 
> 
> 
> 
> ----- Original Message -
> From: "Steve Downey" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 14, 2001 5:39 PM
> Subject: RE: JNDI/LDAP realm
> 
> 
> > The downside to binding with the supplied credentials is 
> that it chews up
> a
> > file descriptor. For light loads, it's not an issue. For 
> heavy loads, it
> can
> > be a big issue. If the app server binds administratively, 
> you can get by
> > with two connections, one for reading and one for writing. 
> Or even one, if
> > you're not replicating LDAP.
> 
> According to the JNDI tutorial at least, Suns's provider for 
> LDAP v3 is
> supposed to allow rebinding with a different principal.and 
> credentials while
> keeping the same directory context and underlying network connection.
> (Although  in practice it doesn't always seem to work quite 
> like that). So
> it might be possible not to need additional file descriptors. 
> Also, note
> that the LDAP connection is only needed for a brief period at 
> the beginning
> of a session when the user first authenticates. Not that the 
> present code
> attempts to be efficient about reusing directory contexts etc.
> 
> But perhaps I misunderstand what you are saying.
> 
> > All in all, making it configurable is probably a good idea.
> 
> Agreed.
> 
> >
> > > -Original Message-
> > > From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
> > > Sent: Sunday, May 13, 2001 12:58 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: JNDI/LDAP realm
> > >
> > >
> > > I preferred binding to the directory with supplied
> > > credentials because it
> > > allows the realm implementation to use an anonymous password
> > > for the rest of
> > > what it needs.
> > >
> > > To allow for DN's in the directory that may not be composed
> > > of the same
> > > attributes as other DN's, one thing I was thinking about
> > > doing to the one I
> > > submitted was to configure what the login attribute is (cn,
> > > uid, etc.) and
> > > search for it (with anonymous login) to get the dn, then 
> bind to the
> > > directory with the resultant DN and the user-entered password to
> > > authenticate.  This might be a little less efficient than
> > > just searching and
> > > getting the password as well, but is more secure than 
> having the root
> > > password to the ldap server where it might be accessible 
> by someone.
> > >
> > >
> > > - Original Message -
> > > From: "John Holman" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Sunday, May 13, 2001 5:02 AM
> > > Subject: JNDI/LDAP realm
> > >
> > >
> > > > The current JNDI realm implementation in Tomcat 4 is 
> based on code I
> > > > submitted, which was subsequently modified and 
> committed by Craig.
> > > >
> > > > Two significant changes he made are:
> > > >
> > > > - the original code found the DN of the user by searching
> > > the directory.
> > > The
> > > > current implementation, like Ellen Lockhart's recent submission,
> > > determines
> > > > the DN by substituting the username into a string.
> > > >
> > > > - the original code supported a mode in which the user is
> > > authenticated by
> > > > binding to the directory with the supplied credentials (as
> > > does Ellen's).
> > > > The code for this was removed, with a comment in the commit
> > > log that this
> > > > mode should be supported probably in a separate
> > > im

RE: Trying New Connectors Build Stuff

[Steve Downey]

With cygwin, it should build using ./configure && make && make check && make
install. It's just another flavour for autoconf. Although it didn't used to
be true, recently I am more surprised when a package does _not_ build using
cygtools. 

However, the unix emulation layer is nowhere near as efficient as win32
native at such important tasks as disk and socket I/O.

It's a wonderful user level tool. I use it everyday for many things. But
deploying production systems isn't one of the things I'd do.

However, since I just recently sold management on linux/apache/tomcat as our
next gen platform, and I can put that on my desktop as well, it's not much
skin off my nose if the connectors are suboptimal on NT. 



> -Original Message-
> From: kevin seguin [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 10:00 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Trying New Connectors Build Stuff
> 
> 
> > 
> > So we have 2 cygwin (amy+jon) and 1 msvc (kevin)... I hoped 
> to have more
> > feedback... I'll start with cygwin (since I can get it for free)
> > 
> 
> does it really matter much?  it should build with both cygwin 
> and msvc,
> right?  you might just have different makefiles for the two.
> 
> -kevin.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Trying New Connectors Build Stuff

[Steve Downey]

Cygwin can add significant overhead in it's emulation layer. If you can do
it with gcc -mno-cygwin, that might be a reasonable compromise.


> -Original Message-
> From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 2:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Trying New Connectors Build Stuff
> 
> 
> kevin seguin at [EMAIL PROTECTED] wrote:
> > 
> >> Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which 
> is the module I'm
> >> writing right now...
> > 
> > so... iis is next, right ;-)
> 
> Yes, IIS is next, I just need to install Win2K on my only 
> Intel box I have.
> It's a very old Pentium 366 and I hope I'll be able to get it 
> working with
> MSVC or CygWin (BTW, which one do you prefer, guys?)
> 
> Pier
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: JNDI/LDAP realm

[Steve Downey]

The downside to binding with the supplied credentials is that it chews up a
file descriptor. For light loads, it's not an issue. For heavy loads, it can
be a big issue. If the app server binds administratively, you can get by
with two connections, one for reading and one for writing. Or even one, if
you're not replicating LDAP.

All in all, making it configurable is probably a good idea.

> -Original Message-
> From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 12:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JNDI/LDAP realm 
> 
> 
> I preferred binding to the directory with supplied 
> credentials because it
> allows the realm implementation to use an anonymous password 
> for the rest of
> what it needs.
> 
> To allow for DN's in the directory that may not be composed 
> of the same
> attributes as other DN's, one thing I was thinking about 
> doing to the one I
> submitted was to configure what the login attribute is (cn, 
> uid, etc.) and
> search for it (with anonymous login) to get the dn, then bind to the
> directory with the resultant DN and the user-entered password to
> authenticate.  This might be a little less efficient than 
> just searching and
> getting the password as well, but is more secure than having the root
> password to the ldap server where it might be accessible by someone.
> 
> 
> - Original Message -
> From: "John Holman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, May 13, 2001 5:02 AM
> Subject: JNDI/LDAP realm
> 
> 
> > The current JNDI realm implementation in Tomcat 4 is based on code I
> > submitted, which was subsequently modified and committed by Craig.
> >
> > Two significant changes he made are:
> >
> > - the original code found the DN of the user by searching 
> the directory.
> The
> > current implementation, like Ellen Lockhart's recent submission,
> determines
> > the DN by substituting the username into a string.
> >
> > - the original code supported a mode in which the user is 
> authenticated by
> > binding to the directory with the supplied credentials (as 
> does Ellen's).
> > The code for this was removed, with a comment in the commit 
> log that this
> > mode should be supported probably in a separate 
> implementation class.
> >
> > I did comment on this in an earlier message, but got no 
> response - so I'm
> > trying again now there is another little wave of interest :)
> >
> > Determining the DN. The pattern substitution method in the current
> > implementation is obviously more efficient when applicable 
> but the search
> > method is more general. For example, unlike the current 
> implementation,
> > search can handle the following common use cases:
> >
> > - users are stored within multiple nodes in the directory 
> (e.g. they may
> be
> > held under different
> > organisational units)
> >
> > - the attribute used in distinguished names is not the same 
> as that the
> user
> > enters into the basic authentication dialog box (e.g. the 
> user might enter
> > mail address as the username rather than uid; the directory 
> might use
> > commonName as a component of distinguished names rather than uid).
> >
> > So there are really two orthogonal issues for user 
> authentication each
> with
> > two options:
> >
> > - how the dn for the user is determined (configuration template vs
> directory
> > search)
> > - how authentication is done (system login vs binding as the user)
> >
> > I think it's important that Tomcat supports the missing 
> combinations of
> > options. In fact, the most common strategy when using a 
> directory for
> > authentication is probably "search then bind", neither 
> component of which
> is
> > supported by the current implementation.  For example, this is the
> strategy
> > taken by pam_ldap and by the auth_ldap Apache module.
> >
> > I'd be happy to have a go at adding the missing 
> functionality, but would
> > like some feedback first as to whether people think this is 
> a good idea.
> > Also opinions as to whether we should have one, two or even 
> four classes
> to
> > implement the different combinations (with multiple classes 
> maybe derived
> > from a base JNDIRealm class). We should take into account 
> which variation
> is
> > likely to lead to the simplest and clearest configuration 
> documentation
> ...
> >
> > John.
> >
> >
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

[PATCH] bugs 412 and 112 for TC3.3

[Steve Downey]

112 is really simple. Just a check if the TOMCAT_HOME should be '..' after
checking for '.'

412 is almost as straightforward. It's a bug in JspC, where
CommandLineContext is handed a URI with '\' s in the jspFile. Defensively,
I've added a replace in CommandLineContext's constructor. Alternatively, it
could be done by the caller. Arguably, it would make more sense in the
caller, as a URI should never have a separator other than '/'. 

In the course of these, I had to deal with a couple other regressions in
JspC. Firstly, it won't run, out of the box. JspC doesn't set up any
classloaders, and hence does not know about any of the jars other than the
boostrap ones. Adding the classloaders to JspC is a bunch of work, so I just
added a CLASSPATH for the JSPC target in tomcat.bat. 

I also added setlocal at the top of the batch file, to keep the environment
variables from leaking out when the script crashed. Also an endlocal so that
"tomcat env" would still work.

JspC also wasn't logging anything. I added some code to set up the
JASPER_LOG logger. 



<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
  


 bug412.patch

RE: Jasper34: sandboxing/Priviledged

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 27, 2001 8:37 PM
> To: [EMAIL PROTECTED]
> Subject: Jasper34: sandboxing/Priviledged
> 
> 



> 
> The other concern is that in one use case for jasper34 it may create
> problems. We would like JspC-generated pages to work in any 

Read for 'We would like', 'The JSP Specification requires'. 

There's an unfortunate use of the word 'may' in the spec around this point,
but it looks to me as though the intent is that the developer 'may', the
implementation 'SHALL'.

> container -
> that means the runtime and generated code must be included in 
> the WAR (
> since not all containers are using jasper - yet ). In that case the 
> runtime will run without priviledges ( well, in general it's better to
> keep the permissions low ).
> 
> 
> Costin
> 
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: Jasper34: diffs between 1.1 and 1.2

[Steve Downey]

The only downside I see is that the security manager triggers the use of
URLClassloader on a per JSP page basis. As I understand it, this class is
broken w.r.t. Java 1.1. 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 7:12 PM
To: [EMAIL PROTECTED]
Subject: Jasper34: diffs between 1.1 and 1.2


Hi,

There are few diffs between the runtime for 1.1 and 1.2.

Some of them are obviously due to API changes ( additions mostly,
only one change that I could identify - JspInclude ).

Most are due to changes/fixes that went only in one branch ( various
optimizations for 3.3, security manager for 4.0 ).

We'll need to sync ( not very urgent ). There are few issues:

- various optimizations - that's easy, but we need to take care in 1.2 
as some objects are created and need pooling 
( Note: the runtime is critical for performance - as oposed with the
generator. Need to keep garbage close to 0 )

- It would be possible ( given the small diffs ) to use a single codebase,
the 1.2, and compile using jsp1.1 to generate a 1.1 runtime.
The extra methods will be ignored.

The big problem is the change in jsp:include default. One simple way is 
to use a flag. 

That would be the best solution for maintainance ( that may not work for a
jsp1.3, but for what we have right now the changes are finite and small).

What do you think ?

Costin


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: [GUMP] Build Failure - Tomcat 3.x

[Steve Downey]

Index: ErrorHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/generator
s/ErrorHandler.java,v
retrieving revision 1.10
diff -u -r1.10 ErrorHandler.java
--- ErrorHandler.java   2001/04/23 01:21:58 1.10
+++ ErrorHandler.java   2001/04/24 14:40:58
@@ -173,7 +173,9 @@
errorServlet=getHandlerForPath( cm, ctx, errorPath );

String cpath=ctx.getPath();
-   if( cpath="/")  cpath="";
+if( cpath.equals("/") ) {
+cpath="";
+}

// Make sure Jsps will work - needed if the error page is a jsp
if ( null!=errorPath && errorPath.startsWith("/") ) {
@@ -290,7 +292,9 @@
errorServlet=getHandlerForPath( cm, ctx, errorPath );

String cpath=ctx.getPath();
-   if( cpath="/")  cpath="";
+if( cpath.equals("/") ) {
+cpath="";
+}

// Make sure Jsps will work - needed if the error page is a jsp
if ( null!=errorPath && errorPath.startsWith("/") ) {

-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 8:45 AM
To: [EMAIL PROTECTED]
Subject: [GUMP] Build Failure - Tomcat 3.x



This email is autogenerated from the output from:



Buildfile: build.xml

detect:

msg.jdk12:
 [echo] Detected JDK1.2

msg.jsse:
 [echo] Detected JSSE

init:

prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/native
 [copy] Copying 10 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
 [copy] Copying 19 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf
 [copy] Copying 42 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc
 [copy] Copying 89 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/native
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat
 [copy] Copying 7 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
 [copy] Could not find file
/home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy.
 [copy] Could not find file
/home/rubys/jakarta/jakarta-ant/dist/lib/parser.jar to copy.
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common
 [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common

tomcat_util:
[javac] Compiling 83 source files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
  [jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/core_util.jar
  [jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_util.ja
r

tomcat.jar:
[javac] Compiling 1 source file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
  [jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/tomcat.jar

stop-tomcat.jar:
[javac] Compiling 1 source file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
 [copy] Copying 4 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/tomcat/re
sources
  [jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/stop-tomcat.jar

tomcat_core:
[javac] Compiling 10 source files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/clas

RE: Bugs <500

[Steve Downey]

360 and 412 look like they might cause me some headaches. Are you -1 on
fixing them, or -0? That is, should I bother or not?


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 22, 2001 2:25 PM
To: [EMAIL PROTECTED]
Subject: Bugs <500


Hi,

I finished reviewing bugs marked as LATER with ID<500. 

There are 5 bugs that we should fix for 3.3:

345 - Date header
348 - Security roles 
375 - // security checking - revert to paranoid path checks
454 - mod_jk spawning (hunged ) apache processes when tomcat is down 
 ( maybe later - tomcat should be running or be restart )
486 - rusian in jsp @include

There are 8 jasper bugs I think we should leave open, I wouldn't change
jasper before refactoring:

75 - translation time attrs
105 - custom tag attrs
143 - tag handlers
360 - jsp:include expressions
366 - doAfterBody if no body
376 - Jsp error messages in some cases ( no setter )
387 - special tokens in tag name ( extend to jsp files )
412 - JSPC and \ paths ( it may be easy to fix )

4 bugs are fixed in 3.3, we should close them:

149 - log, fixed
295 - config generation, fixed
296 - "can't happen", fixed
485 - cookies, fixed

Also, 4 bugs I don't think we'll cover in 3.3:
166 - spaces on nt ( has workarounds )
962 - redirect sys out, err; config in server.xml, rotate ( RFE )
471 - mod_jk and spaces in dir name on windows ( has workarounds )
112 - BAT script on windows - bin/ as default 

Costin
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.

[Steve Downey]

> -Original Message-
> From: Mel Martinez [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 10, 2001 2:56 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [jetty-discuss] Re: Jasper JSP maintainer required for
> Jetty project.
> 
> 
> other servlet engines.  Further,  it is not clear that
> the JspC implementation of Jasper even NEEDS web.xml
> information.  Thus, it is clear that another useful

Taglib map in web.xml is why JspC needs web.xml. Otherwise the compiler
can't find the java classes that implement the tag. 

Now, you don't need that for JSP->Java, but remember that step is an
implementation detail. It's actually JSP->class. 

I'd like to be able to use JspC as part of a web application packaging tool,
and for that, it should be able to generate classes, not just java source.

<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

It's one of the alternate names for Abstract Factory, from the GoF book. AKA
toolkit. 

The idea is that you have a an abstract class with methods such as
createThing1 and createThing2, which return abstract Thing1s and Thing2s. A
concrete implementation of the factory, xFactory,  returns an xThing1 and an
xThing2, and a yFactory returns yThing1 and yThing2.

A classic example is GUI widgets, where you might have MotifButton,
MotifScrollbar, MotifWindow, ..., or Win32Button, Win32Scrollbar,
Win32Window, ..., or GtkButton, GtkScrollbar, GtkWindow, ...

Here we have CommandLineMangler, CommmandLineContext, CommandLineCompiler,
and JspMangler, JspEngineContext, JspCompiler, ...

They don't seem to be pure mix and match. That is, it doesn't necessarily
make sense to use an XCompiler with an XContext, although it might. So the
overhead of having to create a new Factory implementation for a new
combination or style isn't that excessive.





> -Original Message-
> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 2:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> 
> 
> Hi Steve!
> 
> Steve Downey wrote:
> > Perhaps a Kit pattern is in order?
> 
> Wow, a Kit pattern. I never heard of that one (or never got 
> that far in
> the Patterns books :)
> 
> Is it a standard one? If so, I'll check it out later at home.
> 
> Un saludo,
> 
> Alex.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 29, 2001 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> 
> 
> On Thu, 29 Mar 2001, Mel Martinez wrote:
> 
> > activities that should be orthogonal.  The only
> > dependency should be that the Compiler is a consumer
> > of the products of the Mangler.
> 
> +1

If we treat the embedded implementation of Mangler as a separate class,
which I think is a good idea, each style of JSP compilation works with a
triad of somewhat dependant classes. An X-Compiler, an X-Context and an
X-Mangler. If we're playing games with the name of the generated class, like
decorating it with a version number, then some other part of the system
needs to understand the Mangling scheme as well. ClassName does some of this
work now, finding out what the 'real' name of the class is.

Perhaps a Kit pattern is in order?

Refactoring Mangler is highly desireable from my day job point of view, too,
since the current mangling scheme can cause problems on Windows. Although we
might be able to move to Linux for developers desktops soon. 

[BTW, I have to thank you for the performance work on Tomcat 3.3. We're
starting a new strategic cycle, and evaluating what platforms and
technologies to persue in the next 12 months. We were preparing arguments
about the value access to source of open software, the recruiting value of
working with 'cool' technology, career development, and so forth. But just
to be thorough, I took our worst behaved JSP page, which happens to be our
home page, and benchmarked it under several engines. TC33 blew the doors off
the competition, up to levels of 177 concurrent connections, at which point
the benchmark tool starting melting down.] 

> 
> > I think the problem starts with the idea to make a
> > JspLoader that 'loads JSP files just as if they were
> 
> JspLoader is a special thing - it's a great idea ( well, the 
> new model used by JspInterceptor does the same thing
> in a much cleaner way ).
> 
> But in any case, should be independent of everything 
> else - just a component that may be used by the 
> "container adapter" classes.
> 
> Costin

DIP, the dependencies should be on interfaces, not on classes.


-SMD
--
Someone else added this stuff :


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

> -Original Message-
> From: Mel Martinez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 6:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> 
> 
> Wow! I go away for a day and there is some great
> discussion on this thread!
> 
> I've saved everybody's comments and will incorporate
> them into the proposal, which I will be working on
> tonight to formalize.  When I've got it ready for
> review, I will put a proposal doc and any related
> files in html form into
> .../jakarta-tomcat/proposals/tomcat33/
> 

doing some static analysis, based on class use of other classes, it looks
like this constellation of classes could easily be factored out into their
own package:

org.apache.jasper.compiler.Compiler
org.apache.jasper.compiler.Mangler
org.apache.jasper.compiler.CommandLineCompiler
org.apache.jasper.compiler.JspCompiler
org.apache.jasper.compiler.JavaCompiler
org.apache.jasper.compiler.JikesJavaCompiler
org.apache.jasper.compiler.SunJavaCompiler
org.apache.jasper.compiler.JspCompilationContext
org.apache.jasper.JspEngineContext
org.apache.jasper.CommandLineContext
org.apache.jasper.JasperEngineContext

Based on actual use, it looks to me like Mangler and Compiler should be
merged. There are no instances of Compiler that do not implement the Mangler
interface. 

The classes that implement JspCompilationContext look to me like they don't
all belong in the same package, unless everything here is in the same
package. They are interface classes between the Jasper compiler and the
outside invoker of the compiler. 
 

Here are the classes I'm talking about

http://www.panix.com/~sdowney/compilers.gif

and the entire compiler package

http://www.panix.com/~sdowney/org.apache.jasper.compiler.gif

(courtesy Together J)



<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 3:46 PM
> To: [EMAIL PROTECTED]
> Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> 
> 
> On Wed, 28 Mar 2001, Steve Downey wrote:
> 
> > The second most common cause of bugs in Jasper is confusion 
> over when to use
> > File.separator and when to use '/'. It's hard to keep track 
> of, since Jasper
> > does deal with both files and URIs. And the File methods are used to
> > regularize some URIs. 
> > 
> > Another reason to refactor.
> 
> I would say this is also part of interfacing the jasper with the
> container, and not core to the jsp parser and jsp->java 
> convertor ( which 
> in my opinion represents the "core" of jasper ).
> 
> There is the problem of importing jsps ( and few other cases 
> where files
> are needed), but again that's related with the API that is 
> needed to plug 
> jasper into a ( cooperating ) container.
> 


 ... importing jsp text, determining the file to write java to, finding tag
library descriptors, finding the directory to direct the java compiler to
write class files to...

Files are inherent, at least as long as javac insists on having files. I
would love to be able to compile a stream, or array of streams, but that's
not happening near term. 

Almost everything else uses URI's to refer to things. So, for the most part,
jasper should not be looking at, or using, files. Streams, yes, as in
getResourceAsStream, but mostly not Files. Most current uses of File are
wrong, and other parts of Jasper try to compensate.

Actually, I don't think that importing needs Files. It should be able to use
getResourceAsStream. That may need to work with Files, but that's something
that the container deals with, not Jasper. 


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>