Jikes 1.18 JSP compiler support broken in TC 4.1.27

[Chris Brown]

Hi,

I tried switching to Jikes with Tomcat release 4.1.27 (LE-JDK1.4), and it
would appear that the version of "ant.jar" you use internally in Tomcat to
compile JSP pages is out of date with regards to the latest versions of
Jikes (which have been around for a while now).

The Javac Ant task is specifying an "-encoding" option for Jikes, which
Jikes is refusing.  I'm using "Jikes Compiler - Version 1.18 - 21 November
2002" (according to the "jikes -version" command) on Win2000.  See below for
Jasper's output.

I have no problem using Jikes standalone, or with Ant 1.5.3's Javac task
(outside of Tomcat).

I'm using Sun's JDK 1.4.2 on Win2000 SP4.

Hope this helps,
Chris B.



org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Compiling 1 source file
[javac] use: jikes [options] [EMAIL PROTECTED] file.java...
[javac] For more help, try -help or -version.
[javac] Error: The option "-encoding" is unsupported in this build.



 at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandle
r.java:130)
 at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:2
93)
 at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353)
 at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
 at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:4
73)
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:1
90)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)



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

JSP error with standard Javac (and a workaround) with Tomcat 4.1.27

[Chris Brown]

Hi,

I've just upgraded from Tomcat 4.1.24 to 4.1.27, and am using the default
out-of-the-box configuration (see below).  Tomcat now refuses to compile
JSPs with the default settings.  I need to modify conf/web.xml such that the
"fork" init-param for the JSP servlet is set to "true" (not "false", which
is the default)... and then it works.

Basically, without "fork=true", it complains that it can't resolve
JAVA_HOME.  When it forks, all goes well.  See the output below for more
information.

Here's my config:

- Win2000 SP4 (no other web servers running/installed)
- Sun's J2SE 1.4.2 SDK, installed in d:\java\jdk1.4.2
- JAVA_HOME is set as a system environment variable,
  pointing to d:\java\jdk1.4.2
- "tools.jar" is in the "lib" subdirectory of JAVA_HOME.
- Tomcat 4.1.27, downloaded as a binary release from main
  website http://jakarta.apache.org/tomcat/

Hope this helps iron out a wee problem!

- Chris B.


2003-08-07 15:29:24 Info: Compile:
javaFileName=D:\inetpub\tomcat\work\Standalone\localhost\open\/login_jsp.jav
a

classpath=/D:/inetpub/tomcat/webapps/open/WEB-INF/classes/;D:/inetpub/tomcat
/common/lib/ant.jar;D:/inetpub/tomcat/common/lib/commons-collections.jar;D:/
inetpub/tomcat/common/lib/commons-logging-api.jar;D:/inetpub/tomcat/common/l
ib/jasper-compiler.jar;D:/inetpub/tomcat/common/lib/jasper-runtime.jar;D:/in
etpub/tomcat/common/lib/naming-common.jar;D:/inetpub/tomcat/common/lib/namin
g-factory.jar;D:/inetpub/tomcat/common/lib/naming-resources.jar;D:/inetpub/t
omcat/common/lib/servlet.jar
 cp=D:\inetpub\tomcat\webapps\open\WEB-INF\classes
 cp=D:\inetpub\tomcat\common\lib\ant.jar
 cp=D:\inetpub\tomcat\common\lib\commons-collections.jar
 cp=D:\inetpub\tomcat\common\lib\commons-logging-api.jar
 cp=D:\inetpub\tomcat\common\lib\jasper-compiler.jar
 cp=D:\inetpub\tomcat\common\lib\jasper-runtime.jar
 cp=D:\inetpub\tomcat\common\lib\naming-common.jar
 cp=D:\inetpub\tomcat\common\lib\naming-factory.jar
 cp=D:\inetpub\tomcat\common\lib\naming-resources.jar
 cp=D:\inetpub\tomcat\common\lib\servlet.jar
 work dir=D:\inetpub\tomcat\work\Standalone\localhost\open
srcDir=D:\inetpub\tomcat\work\Standalone\localhost\open
include=login_jsp.java
Exception compiling Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

2003-08-07 15:29:24 Exception:
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
 at
org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(C
ompilerAdapterFactory.java:139)
 at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:835)
 at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
 at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:320)
 at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
 at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:4
73)
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:1
90)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)



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

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

[Chris Brown]

Hi Remy,

It might be worth COPYING the original web.xml at deployment time, to make a
runtime-web.xml, to do what you propose, leaving the original web.xml
untouched.  This way, you can add the declarations for compiled JSPs, and --
as a bonus -- allow clean modification of things like init-params for
servlets, filters, and the context itself.  Such modifications could be done
in the admin webapp.

If the application is redeployed, or at least if web.xml is modified, then a
new copy of web.xml can be made, merging in the modifications made to the
older (now obsolete) copy, and of course, the declarations for the compiled
JSPs.

I'm all for deploying applications as simply as possible, letting end-users
customise things from nice graphical interfaces without touching
configuration files directly.  Many less experienced individuals screw up
web.xml when attempting to modify stuff, and it implies unpacking WARs, and
looking through lots of "confusing" application structure (where's web.xml?
what's xml anyway?  why doesn't tomcat start now that I've typed an
apostrophie in the servlet's init-param...?)

- Chris

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 12:05 PM
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]

Suggestion for DefaultServlet (easier spidering by search engines)

[Chris Brown]

Hello,

Just a little suggestion to help search engines spider Tomcat websites
easier...

Could somebody add the following to the directory listings generated by
tomcat ?



Thanks,
Chris



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

Re: Why unpackWars=true default?

[Chris Brown]

To clarify, when I said I "consider" WARs as if they were EXEs, I mean that
in many cases I think it's good practice to have a WAR file that doesn't try
to modify itself internally (bit like having an EXE or whatever that
modifies its contents or self-modifying assembler code...).

Some webapps benefit from customisation, and are good candidates for
unpacking, others are best left as a single unit which store environment
settings externally.

My main gripe with the unpackWARs setting is that if WARs are unpacked, it
makes it more troublesome to upgrade, because a newer version of the WAR
file is ignored if any previous version has already been unpacked (until the
unpacked files are deleted).  If the WAR file is updated, it's *probably*
safe to assume that this was done voluntarily, and so any previous unpacked
version should be removed then replaced.

I don't really care if it's considered a deployment format or an executable
format ; whether it's unpacked on disk, in memory, or whatever is
irrelevant, as long as it works : it's up to the servlet engine to implement
this as it wants (given that JSPs need to be compiled, obviously something
needs to be created outside the WAR).

Having said that, if we're meant to deploy as unpacked files, why bother
with methods such as ServletContext.getResource() (when we could just use
getRealPath if we systematically unpacked these files) ?

- Chris

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 22, 2003 1:31 AM
Subject: Re: Why unpackWars=true default?


> On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote:
> > >consider the ".war" file like an ".exe" or executable JAR file.
> >
> > And I think this is where my interest comes from.  Your considerations
> > are exactly the opposite of Costin's (I think it was Costin anyways),
> > who considers the .war file a *deployment* format only, like an RPM or a
> > Windows Installer file, not to be run as an executable.
>
> I thought the raison d'etre of war's was acting like a single .exe.
>
> Or at least the default -- just as you're not expected to unpack jars.
>
> Matt



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

Re: Why unpackWars=true default?

[Chris Brown]

> Would it be better to remove unpackWARs from tomcat5 since there isn't
> that much of a concern for backwards compatibilty on major releases?
>
> -Tim

It should always be at least an option to deploy WAR files without unpacking
them.

Systematically unpacking WARs would cause problems: the unpacked version is
always used in preference to the packed version by Tomcat, so if
unpackWARs="true", then overwriting the original ".war" file has no effect
(because of the preference for using the directory if it exists), making
upgrade deployment of webapps very problematic, leading to lots of support
calls for us ("I replaced the WAR file, but nothing happens!").

It seems like a bad idea in many cases (obviously not all) to allow
modifications within the webapp itself on production deployments (small
sites and development releases of webapps are examples where this wouldn't
always apply).  All custom data in our apps is either stored in the
user.home directory, the preferences API, JNDI, or whatever.  We tend to
consider the ".war" file like an ".exe" or executable JAR file.

- Chris



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

Re: [5.0] Input optimization

[Chris Brown]

> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.

prepend() ?


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

Re: Tomcat and JSDK 1.4

[Chris Brown]

This is really a user question...

In answer to your question, I have tried it on Windows 2000 and Windows XP,
with Sun's JDK 1.4.0 (final, not the "_01" patch or 1.4.1 beta).  It crashes
quite often, i.e.: the JVM just dies, not a Tomcat exception.  It happened
frequently with Tomcat 4.0.x, but I didn't have time to track the bug
exactly.  I suspect a problem in the JDK however, as the I/O implementation
has changed a lot.  Hopefully the problem will have gone away in more recent
releases.

-Chris B

- Original Message -
From: "Bracken, William (Contractor)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 8:34 PM
Subject: Tomcat and JSDK 1.4


> Okay, "Tomcat 4 has been extensively tested with JDK 1.3.1, which is
> recommended."
> My question is, have any of you gurus out there worked with JSDK 1.4? If
so, on
> what platforms? Have any problems? Sorry to give a 'do my homework for me'
> question, but I have no time to do all those tests, and I'm sure quite a
few of
> you out there have larger projects that you've moved (or attempted to
move) to
> 1.4.
>
> Will
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
>



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

Re: [JK2] Trying 4.1.3 Beta + IIS

[Chris Brown]

See intermixed.

- Original Message -
From: "Ignacio J. Ortega" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, June 26, 2002 12:33 PM
Subject: RE: [JK2] Trying 4.1.3 Beta + IIS


> > De: Chris Brown [mailto:[EMAIL PROTECTED]]
> > Enviado el: 26 de junio de 2002 9:53
>
> > Should connectors to IIS and Apache behave differently
> > according to whether
> > a webapp is deployed as a WAR file or as an uncompressed set
> > of files on the
> > disk?  When the webapp is deployed "uncompressed", it should
> > be easy enough
> > to find the static files to server, but when it's an unpacked
> > WAR file, it's
> > unlikely IIS et al know how to read from the WAR file
> > directly, or locate
> > the temporary folder into which WAR file contents are
> > unpacked (so that it
> > can find static files).
>
> I dont know what could be done if you try to run your app directly from
> a war, but it seems to me that to do nothing is the way to go :), it is
> simply a tradeoff..

I was just wondering if the connectors were aware that sometimes they won't
find static contents using any "real" path, as they may be in a WAR file.
As long as the connectors know that sometimes they shouldn't serve static
content, they should just be a sort of proxy or man-in-the-middle.

> An given that, to get static content served natively by the webserver,
> it's a performance measure, it's seems that there is a little
> contradiction with the possibility of run the webapp directly from the
> war, isn't it?

I agree that for performance reasons, it's best to let the frontal server
handle static requests.  However, in some scenarios (particularly
development), it's useful to be able to overwrite previous versions in one
go, i.e.: replace one WAR file with another, instead of deleting files that
are no longer required, then adding all new files.  Where I work, we also
create webapps for other companies or organisations/associations, and it's
much easier for them to handle one single file than lots of separate files,
especially when they want to install an upgrade!

> Saludos ,
> Ignacio J. Ortega

Thanks,
-Chris B.



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

Re: 5.0 proposal

[Chris Brown]

I can't commit to developing this (I'd love to, I have some ideas, but I
don't have the time...), but hopefully it might interest someone and they
can develop it...

When deploying webapps as WAR files, especially generic webapps, it's not
always very practical to request that an administrator manually unpacks the
WAR file, locates the web.xml file, and updates context or servlet
parameters.

Perhaps the admin/manager webapp could list all context/servlet parameters
for a given webapp, and allow their values to be changed.  This isn't a way
to modify web.xml directly, more a way to store values to override
whatever's in web.xml.  That way, if a new copy of the webapp is installed
in the server, the overriding values would still be retained and can
override the updated web.xml, without requiring to be reentered.

It's by no means a critical feature, but it's nice to have.

- Chris B.



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

Re: [JK2] Trying 4.1.3 Beta + IIS

[Chris Brown]

Should connectors to IIS and Apache behave differently according to whether
a webapp is deployed as a WAR file or as an uncompressed set of files on the
disk?  When the webapp is deployed "uncompressed", it should be easy enough
to find the static files to server, but when it's an unpacked WAR file, it's
unlikely IIS et al know how to read from the WAR file directly, or locate
the temporary folder into which WAR file contents are unpacked (so that it
can find static files).

- Chris B.

- Original Message -
From: "Ignacio J. Ortega" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, June 26, 2002 12:48 AM
Subject: RE: [JK2] Trying 4.1.3 Beta + IIS


> > De: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> > Enviado el: 26 de junio de 2002 0:35
>
> >
> > I can't really answer like that. The static files aren't
> > supposed to get
> > served by IIS here ?
> >
>
> My setup is [uri:/examples/*]
>
> wk2.p file uri components, are Servlet spec compliant (more or less) so
> you can specify that only *.jsp or an absolute path it's served by tc,
> but you can too use it as webapp, how i used it.. dumping an entire url
> subtree to tomcat to manage..
>
> And remember they are mainly need in IIS, Apache can use JK2 directly,
> without using at all the JK2 mapper..
>
> > I can't think of anything funny the DefaultServlet would do over a
> > simpler servlet.
> >
>
> It isnt the DS, hmmm, but fail are repeatables, and most times , if you
> keep getting the same file it eventually fails too..
>
>
> Saludos ,
> Ignacio J. Ortega
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
>



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

Spec change: getting servlet context name / url prefix during init

[chris brown]

Hello,

I'm aware (or at least, I assume!) that some of the people on this list are
involved in developing the specs for the Servlet API.

It would be useful to be able to obtain information about the servlet
context's name (or specifically, it's URL prefix) during initialisation
(either in a servlet's init() method, or in session or context event
listeners), for example to know that all servlets in the context will be
prefixed with "/mycontext" for example.

It's useful for preparing resources in quite a few cases, but at present,
I can only obtain this info from the ServletRequest (and that's "too late",
or at least very tricky to handle or synchronise).

I know that there's a method on ServletContext called
"getServletContextName", but that returns the value of the 
element in the deployment descriptor, not the URI mapping.

Hopefully someone can put this idea forward for inclusion in Servlet2.4 (the
next one, isn't it?).

Thanks,
-Chris B.




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

Fw: request.getLocale() always returns "en_US" ..?!

[chris brown]

Hello,

I posted this on tomcat-user, without any reply.  It seems to be a bug, so I
hope it's relevant on this list.

-Chris

- Original Message -
From: "chris brown"
To: "tomcat-user"
Sent: Thursday, March 14, 2002 3:52 PM
Subject: request.getLocale() always returns "en_US" ..?!


> Hello,
>
> I'm trying to use the method "getLocale()" on HttpServletRequest
objects...
> however, it always seems to return "en_US"!  This is despite my browser
> sending "fr,en-gb;q=0.5" as the "accept-language" header! (I've checked
this
> last point by calling request.getHeader("Accept-Language"), including
> several variations (upper & lower case, for example).  I can always get
the
> correct value back, but Tomcat 4.0.1 always returns "en_US".
>
> Is this a bug?  Or am I missing something?
>
> For info., I've tried this on IE6.0 and Mozilla 0.9.8 .  Both with
> appropriate language settings, both get picked up as "en_US", despite
> correctly-specified values in the "accept-language" headers.
>
> - Chris B.




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

Add a new mime-type to web.xml

[chris brown]

Hi,

Would it be possible to add the following mime-mapping to the default
web.xml file for future releases of Tomcat?

  
htc
text/plain
  

It's for DHTML behaviors, which don't work without this mime type.  It's a
minor addition, and quite simple, so I hope someone can do this (maybe in
time for the release of 4.0.2 ?)

Thanks,
Chris Brown



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

Suggestion for directory listings generated by Tomcat

[chris brown]

Hi,

I'm setting up a search engine to index some sites running under Tomcat
(4.01 as it happens).  It redundantly indexes Tomcat's directory listing
pages as valid documents (albeit with little interest).  I can of course set
up URL filters for the search engine that force it to follow links without
indexing content when the URL ends with "/" (path separator).

It would maybe make life simpler for everyone in my situation if someone
could modify Tomcat's directory listing servlet to include the following
meta tag :



Hopefully someone has a few spare minutes to do that.

Many thanks in advance,
-Chris Brown


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