Re: Re: New repository org
The person you are trying to contact is no longer available at this email address. Please update your contact info to reflect this. For all things Chopping Block business please contact: Dan Schutzsmith dan at choppingblock.com New Business Manager or for all technical/project questions including Web Photo Gallery or flash embed questions: Matthew Richmond matthew at choppingblock.com Principal/Designer thank you, /choppingblock --- The Chopping Block, Inc. http://www.choppingblock.com World Domination Through Graphic Design mailto:[EMAIL PROTECTED] --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r307071 - /tomcat/build/tc5.5.x/build.properties.default
The person you are trying to contact is no longer available at this email address. Please update your contact info to reflect this. For all things Chopping Block business please contact: Dan Schutzsmith dan at choppingblock.com New Business Manager or for all technical/project questions including Web Photo Gallery or flash embed questions: Matthew Richmond matthew at choppingblock.com Principal/Designer thank you, /choppingblock --- The Chopping Block, Inc. http://www.choppingblock.com World Domination Through Graphic Design mailto:[EMAIL PROTECTED] --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: virtual host doesn't load database content
The person you are trying to contact is no longer available at this email address. Please update your contact info to reflect this. For all things Chopping Block business please contact: Dan Schutzsmith dan at choppingblock.com New Business Manager or for all technical/project questions including Web Photo Gallery or flash embed questions: Matthew Richmond matthew at choppingblock.com Principal/Designer thank you, /choppingblock --- The Chopping Block, Inc. http://www.choppingblock.com World Domination Through Graphic Design mailto:[EMAIL PROTECTED] --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC4 base dir
Craig R. McClanahan [EMAIL PROTECTED] wrote:
No, Tomcat 4 doesn't currently have a thing like home -- patches are
welcome! But, my point is you don't *need* home to accomplish the
goals you have articulated:
while we are on a related topic, how about (re) considering this patch?
geoff
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 19, 2001 1:36 PM
Subject: [t4] [patch] for inconvenient -config current dir
Hi there,
As I've been twiddling with T4 again recently this problem has resurfaced.
In T3, I was able to specify the -config option relative to my current
directory. T4 has changed this so that a relative path used with -config
is
resolved relative to CATALINA_HOME.
I find this annoying because I like to store my server.xml files into our
version control system, and it means that relative paths from my VCS work
dir to the server.xml don't work any more. I have to use something like
/vcs work dir/tomcat4/server.xml. Now, if you use an IDE to debug your
servlet in Tomcat, you need to enter this path into the config. And that
means that every time you create a new work dir, you need to update your
IDE
project file.
So, can we please change back to -config relative to the CWD the way
Tomcat 3 worked? Or perhaps at least get it to check for it relative to
CWD
before checking relative to CATALINA_HOME?
All thats required is to remove/change the absolute path stuff in the
configFile() method of Catalina.java like so:
protected File configFile() {
File file = new File(configFile);
/*
NOTE: alternatively use !file.exists() here for fallback
from CWD to CATALINA_HOME
if (!file.isAbsolute())
file = new File(System.getProperty(catalina.home) +
File.separator + configFile);
*/
return (file);
}
Geoff
Re: TC4 base dir
Craig R. McClanahan [EMAIL PROTECTED] wrote: The patch below deals with only one of 33 places that the catalina.home system property is referenced in the Catalina source code -- I think we'd want to consider them all :-). Yeah, I know, I was just scratching the itch that I had at the time. ;-) In order to support the idea of one install of Tomcat 4 being used for more than one configuration, we have to decide which subdirectories of $CATALINA_HOME should be made relative to some new location (specified by a command line option or a different environment variable). Here's my proposed breakdown: Sounds good to me! Cheers Geoff
[tomcat 4] Jasper Status
Hi, I've been considering embedding Jasper in another app. I've been looking at the code and, while is it is *mucky*, it seems this is probably possible (although I can see it's going to severely try my patience ;-). The thing is, I found this document Proposal for Development of Jasper in Tomcat 4.0 in the jasper/doc/dev directory which seems to indicate that the whole thing is up for a major refactoring. This means that if I spend the time to embed it now, based on the current interfaces, all that work could go up in smoke when it gets refactored. Thus, I'm wondering, how far along is Jasper towards a 4.0 release? Is it going to be refactored before release or are we intending to release it largely as is? Thanks, Geoff -- I hate to advocate weird chemicals, alcohol, violence or insanity to anyone... but they've always worked for me. - Hunter S. Thompson
Re: [repost] [T4] servlet including jsp causes jsp to flush buffer?
Sorry, my fault.
This was actually our code calling stream.flush() which ends up calling
response.flushBuffer() (fairly reasonable, really :-).
So, looks like the T4 code is beyond reproach, again.
Geoff
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 14, 2001 1:12 PM
Subject: [repost] [T4] servlet including jsp causes jsp to flush buffer?
come on guys, I know you're listening ... :-)
is this really a bug or am I missing something obvious? (I'm not really up
to speed on Jasper...)
If it is I can enter it into bugzilla...
geoff
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 4:14 PM
Subject: [T4] servlet including jsp causes jsp to flush buffer?
Hi,
I've got a servlet which includes a JSP page, and it appears that the
JSP
engine in Tomcat 4.0 calls response.flushBuffer() when the include
finishes.
IMHO this behaviour is incorrect, as it should be up to the topmost
servlet to control what is happening with the buffering as much as
possible.
Currently this behaviour is preventing my servlet from controlling the
buffering as it would like to.
I looked though the list and noticed that v3.x has many flushing
problems
but I was kinda hoping they'd be fixed in Tomcat 4.x ;-).
Anyway, here's the offending code (I think).
In PageContextImpl.java
public void release() {
try {
if (isIncluded) {
((JspWriterImpl)out).flushBuffer(); // push it into the including
jspWriter
} else {
out.flush();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
}
and in JspWriterImpl.java
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
if (out != null) {
out.flush();
// Also flush the response buffer.
response.flushBuffer();
}
}
}
Geoff
--
Keep cool till after school!
[t4] [patch] for inconvenient -config current dir
Hi there,
As I've been twiddling with T4 again recently this problem has resurfaced.
In T3, I was able to specify the -config option relative to my current
directory. T4 has changed this so that a relative path used with -config is
resolved relative to CATALINA_HOME.
I find this annoying because I like to store my server.xml files into our
version control system, and it means that relative paths from my VCS work
dir to the server.xml don't work any more. I have to use something like
/vcs work dir/tomcat4/server.xml. Now, if you use an IDE to debug your
servlet in Tomcat, you need to enter this path into the config. And that
means that every time you create a new work dir, you need to update your IDE
project file.
So, can we please change back to -config relative to the CWD the way
Tomcat 3 worked? Or perhaps at least get it to check for it relative to CWD
before checking relative to CATALINA_HOME?
All thats required is to remove/change the absolute path stuff in the
configFile() method of Catalina.java like so:
protected File configFile() {
File file = new File(configFile);
/*
NOTE: alternatively use !file.exists() here for fallback
from CWD to CATALINA_HOME
if (!file.isAbsolute())
file = new File(System.getProperty(catalina.home) +
File.separator + configFile);
*/
return (file);
}
Geoff
[t4] tiny bug in catalina.bat
Possibly the world's least important bug: echo Usage: catalina ( env | run | start | stop ) Windows thinks | in echo is a pipe command ... geoff -- I hate to advocate weird chemicals, alcohol, violence or insanity to anyone... but they've always worked for me. - Hunter S. Thompson
[t4] classloader bug on session timeout
Hi there, I'm using the t4 I built checked out and built on Friday, and I noticed the following: java.lang.NoClassDefFoundError: myExistantButNotPreviouslyLoadedClass at myServlet.valueUnbound(ServletSession.java:333) at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession. java:953) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:551) at org.apache.catalina.session.StandardManager.processExpires(StandardManager.j ava:744) at org.apache.catalina.session.StandardManager.run(StandardManager.java:815) at java.lang.Thread.run(Thread.java:484) Seems that it can't successfully load classes when processing a valueUnBound event? The class that it can't find is available in the same WEB-INF/classes dir as the main servlet class... The same code works fine on t3... Geoff -- I hate to advocate weird chemicals, alcohol, violence or insanity to anyone... but they've always worked for me. - Hunter S. Thompson
Re: [t4] FYI: usual problems building according to README...
We're planning to do that, actually, and we're waiting a bit before removing the outdated scripts. fair enough. I always seem to run in to things like that when I build from source. To be expected I suppose... I don't suppose now I've got your attention you'd like to comment on the Jasper calling response.flushBuffer() when included from servlet problem I reported the other day??? :-) Its really bugging me not knowing if it's a bug or I'm missing something... I didn't comment, because I have no idea what to answer. I know very little about Jasper. fair enough! spose I should look through CVS to see whos got their paw prints on the 4.0 Jasper mods ... ;-) thanks geoff
[t4] FYI: usual problems building according to README...
Hi tc4 people, I'm putting myself through the regular build TC4 from source hell that I do whenever I want to test the latest version. (this is on WinNT4) I came across the following issues, you may be aware of them already but I thought I'd report 'em just in case... 1) It no longer builds on JDK1.2. The README indicates 1.2 or later is required. I get the following errors on build dist for tomcat: build-main: [javac] Compiling 2 source files to D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\build\classes [javac] D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\src\share\org\apache\ca talina\servlets\CGIServlet.java:1567: Wrong number of arguments in metho d. [javac] proc = rt.exec(cmdAndArgs.toString(), hashToStringArray(env), wd); [javac] ^ [javac] D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\catalina\src\share\org\apache\ca talina\util\ProcessHelper.java:381: Wrong number of arguments in method. [javac] proc = rt.exec(cmdAndArgs.toString(), hashToStringArray(env), wd); [javac] ^ [javac] 2 errors BUILD FAILED Seems it's relying on a Runtime.exec() method overload which was added in JDK1.3 (interesting, the @since tag is missing? weird. Hope I'm not suffering brain-fade on this one...) 2) it seems to be depending on old versions of the projects it depends on: For example, the bootstrap.bat file for building jakarta-ant from source doesn't co-operate well with the other stuff. It sets - ANT_HOME=. - stuffs up the classpath (adds extra 's in there) - puts ant.jar in /bootstrap/lib rather than /lib where the other build scripts expect it. Also, jakarta-regexp currently builds jakarta-regexp-1.3-dev.jar rather than the jakarta-regexp-1.2.jar that the catalina build.xml expects. Seems you can just rename the jar file or I guess you could use cvs checkout -r RELEASE_1_2 jakarta-regexp 3) seems theres co-ordination problem between the jakarta-servletapi-4 and jakarta-tomcat. When I build I get the following error: BUILD FAILED D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\build.xml:129: D:\apps\jakarta\src\40b5\jakarta-servletapi-4\docs\api not found. build dist for the servlet API does create javadoc, but they are in the dist\docs\api dir... Apart from that it went well though :-) I'm cookin' with gas now... Geoff -- Keep cool till after school!
Re: [t4] FYI: usual problems building according to README...
Hi remy, Thanks for the reply. It's a lot easier now, actually :) It wasn't that hard b4, just the README was always a little out of date... 2) it seems to be depending on old versions of the projects it depends on: It looks like you're still using the build scripts. You shouldn't. Instead, you should run Ant directly, and use a build.properties file. It's really a lot easier. Don't give me that much credit :-). I'm just following the instructions... if I ought to be running Ant directly, then the instructions should say that ... :-) I don't suppose now I've got your attention you'd like to comment on the Jasper calling response.flushBuffer() when included from servlet problem I reported the other day??? :-) Its really bugging me not knowing if it's a bug or I'm missing something... Geoff
[repost] [T4] servlet including jsp causes jsp to flush buffer?
come on guys, I know you're listening ... :-)
is this really a bug or am I missing something obvious? (I'm not really up
to speed on Jasper...)
If it is I can enter it into bugzilla...
geoff
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 4:14 PM
Subject: [T4] servlet including jsp causes jsp to flush buffer?
Hi,
I've got a servlet which includes a JSP page, and it appears that the JSP
engine in Tomcat 4.0 calls response.flushBuffer() when the include
finishes.
IMHO this behaviour is incorrect, as it should be up to the topmost
servlet to control what is happening with the buffering as much as
possible.
Currently this behaviour is preventing my servlet from controlling the
buffering as it would like to.
I looked though the list and noticed that v3.x has many flushing problems
but I was kinda hoping they'd be fixed in Tomcat 4.x ;-).
Anyway, here's the offending code (I think).
In PageContextImpl.java
public void release() {
try {
if (isIncluded) {
((JspWriterImpl)out).flushBuffer(); // push it into the including
jspWriter
} else {
out.flush();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
}
and in JspWriterImpl.java
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
if (out != null) {
out.flush();
// Also flush the response buffer.
response.flushBuffer();
}
}
}
Geoff
--
Keep cool till after school!
[T4] servlet including jsp causes jsp to flush buffer?
Hi,
I've got a servlet which includes a JSP page, and it appears that the JSP
engine in Tomcat 4.0 calls response.flushBuffer() when the include finishes.
IMHO this behaviour is incorrect, as it should be up to the topmost
servlet to control what is happening with the buffering as much as possible.
Currently this behaviour is preventing my servlet from controlling the
buffering as it would like to.
I looked though the list and noticed that v3.x has many flushing problems
but I was kinda hoping they'd be fixed in Tomcat 4.x ;-).
Anyway, here's the offending code (I think).
In PageContextImpl.java
public void release() {
try {
if (isIncluded) {
((JspWriterImpl)out).flushBuffer(); // push it into the including
jspWriter
} else {
out.flush();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
}
and in JspWriterImpl.java
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
if (out != null) {
out.flush();
// Also flush the response buffer.
response.flushBuffer();
}
}
}
Geoff
--
Keep cool till after school!
Re: Tomcat 3.2 Wins Java Editor's Choice Award!
Yep. Well done and thanks to all those who put in the hard yards to get where we are today! - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 4:46 PM Subject: Re: Tomcat 3.2 Wins Java Editor's Choice Award! I echo Marc's thanks to all Tomcat developers -- this award is a result of all the hard work that everyone involved has participated in. I will be sure to feature the award in my session on Tomcat tomorrow at JavaOne :-=) Craig McClanahan On Tue, 5 Jun 2001, Marc Saegesser wrote: Congratulations to all Tomcat developers! I just got back from the JavaWorld Editor's Choice Award presentation and I'm glad to announce that Jakarta Tomcat 3.2 won the award for Most Innovative Java Product. I'll update the Jakarta and Tomcat web sites once I see that the JavaWorld web site has the information posted. Again, thanks to everyone who made this possible. The entire Tomcat community won something tonight. Marc Saegesser
Re: Forming an opinion
"Scott Stirling" [EMAIL PROTECTED] wrote: As Kurt Schrader smartly said: "The last thing we need is the idea police here to make sure that no one is offended by someone's postings not being up to their standards of niceness. It seems to me that if you can't handle having your ideas being called shit then you should keep them to yourself and not participate here." sarcasm Sounds great, maybe that should go right on the main "getinvolved.html" page. /sarcasm JDD said essentially the same thing, it's weird, on one hand I hate to see people getting upset but on the other hand I can't see how we can provide a kind of "virtual padded room" where we can prevent people getting offended without seeming very autocratic. Any ideas how we can effectively deal with opinionated people without muzzling them? geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Forming an opinion
"Peter Donald" [EMAIL PROTECTED] wrote: At 11:08 23/1/01 +1100, Geoff Soutter wrote: Any ideas how we can effectively deal with opinionated people without muzzling them? don't bother responding to them unless they do things the right way. email them OFF list stating this in a very diplomatic way. Watch them explode and then hopefully post-explosion they will be more willing to work with you ;) Cheers, Yeah, sounds reasonable. Maybe I ought to be asking how do we protect the people that get offended? :-) geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Forming an opinion
"Anil Vijendran" [EMAIL PROTECTED] wrote: Geoff Soutter wrote: JDD said essentially the same thing, it's weird, on one hand I hate to see people getting upset but on the other hand I can't see how we can provide a kind of "virtual padded room" where we can prevent people getting offended without seeming very autocratic. I share your sentiments on this. I feel weird continuing this crap too but I'm at my wits end trying to put an end to this sort of stuff. Exactly. There's seems to be a _lot_ of complaining about this topic and very few constructive ideas on how we can improve matters. Any ideas how we can effectively deal with opinionated people without muzzling them? Its not that someone is opiniated that bothers me, its how it is conveyed. I was using "opinionated" as shorthand for behaviour that borders on personal abuse. geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c
James
I'm no expert on this matter (I don't use Apache), but here's my 2c.
The problem is you have two apps "competing" for mapping of URLs. We wish to
centralise it inside tomcat (in web.xml), and have the minimum amount of
config in the apache.conf as possible. Thus, we avoid the solution you are
proposing.
Check the 2.2 servlet spec to understand how mapping is done in a servlet
container.
geoff
- Original Message -
From: "James Courtney" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 23, 2001 5:43 PM
Subject: RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common
jk_uri_worker_map.c
Many thanks,
I was wondering why both the mod_jk module and IIS isapi act as filters
instead of an Apache handler or an IIS application respectively. In their
current implementation they scan all request URIs for ones that they are
responsible for and then, in the case of Apache anyway, register a call
back
to a handler to handle the actual request. I have had this cause problems
for me with Apache in the case where I have a servlet named foo and
another
file named foo.xxx. mod_jk correctly maps /foo to the servlet and
registers
the callback but Apache never calls the callback and instead some other
module or the Apache core make a best guess that the request really meant
foo.xxx since no /foo exists as far as Apache is concerned. By adding
handler entries to Apache's httpd.conf file like the following (pardon my
syntax if it is somewhat off)
location path="/login"
handler name="jakarta-servlet"
/location
Apache then automatically sends that URI to mod_jk without any filtering
needed. All mod_jk need now do is determine which Tomcat handler to use
(ajp12, ajp13, lb, etc...). Filtering is also more expensive because all
modules get a chance to act on the URI before the callback handler. By
registering mod_jk as a handler directly, Apache maps the URI directly to
mod_jk with basically no overhead or searching. I've made some code
changes
(about four changed lines) to mod_jk that make it behave as a pure handler
with no filtering and it seems to run great but I'd like to know before
proposing a change if there were specific reasons for the filter
implementation. Many thanks to anyone who can help:)
-Jamey
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 22, 2001 7:23 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/native/mod_jk/common
jk_uri_worker_map.c
danmil 01/01/22 19:23:03
Modified:src/native/mod_jk/common jk_uri_worker_map.c
Log:
Adding more thorough DEBUG-level to describe what mapping the module is
using for a given request.
Submitted by: James Courtney
Revision ChangesPath
1.3 +18 -6
jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file:
/home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_uri_worker_map.c 2000/11/10 18:48:50 1.2
+++ jk_uri_worker_map.c 2001/01/23 03:23:03 1.3
@@ -65,7 +65,7 @@
* servlet container.
*
*
*
* Author: Gal Shachor [EMAIL PROTECTED]
*
- * Version: $Revision: 1.2 $
*
+ * Version: $Revision: 1.3 $
*
***/
#include "jk_pool.h"
@@ -358,6 +358,7 @@
uri = clean_uri;
}
+ jk_log(l, JK_LOG_DEBUG, "Attempting to map URI %s\n", uri);
for(i = 0 ; i uw_map-size ; i++) {
if(uw_map-maps[i].ctxt_len longest_match) {
@@ -369,10 +370,20 @@
uw_map-maps[i].ctxt_len)) {
if(MATCH_TYPE_EXACT == uw_map-maps[i].match_type) {
if(strlen(uri) == uw_map-maps[i].ctxt_len) {
+ jk_log(l,
+JK_LOG_DEBUG,
+"jk_uri_worker_map_t::map_uri_to_worker, Found an exact match
%s -%s\n",
+uw_map-maps[i].worker_name,
+uw_map-maps[i].context );
return uw_map-maps[i].worker_name;
}
} else if(MATCH_TYPE_CONTEXT ==
uw_map-maps[i].match_type) {
if(uw_map-maps[i].ctxt_len longest_match) {
+ jk_log(l,
+JK_LOG_DEBUG,
+"jk_uri_worker_map_t::map_uri_to_worker, Found a context match
%s - %s\n",
+uw_map-maps[i].worker_name,
+uw_map-maps[i].context );
longest_match = uw_map-maps[i].ctxt_len;
best_match = i;
}
@@ -393,6 +404,11 @@
if(0 == strcmp(suffix, uw_map-maps[i].
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: [snip] Let me also state that at this point in time, I see Velocity+Turbine as being one of the best solutions out there. I agree it has benefits over JSP, but I do think it's still too hard for HTML only coders to deal with the Velocity syntax. Does an HTML person understand what $data.Parameters.getString($key) means? I think not. So, WM/Velocity is good (or at least better than JSP :-) for developing apps where the HTML is developed by people with Java experience - but thats exactly what I believe we should be heading away from. In contrast XMLC seems to be heading in the right direction because template authors need only understand (pure) HTML. Not that I'm necessarily recommending XMLC as a practical solution, I've never used that either... but I have written YATL, so I feel I have enough experience to comment. In conclusion, let me restate that I feel that Turbine+Velocity is the right way to implement Pull functionality for a simple to complex web application. Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only interested in the theoretical issues. Cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/14/01 3:11 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 8:30 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: [snip] Let me also state that at this point in time, I see Velocity+Turbine as being one of the best solutions out there. I agree it has benefits over JSP, but I do think it's still too hard for HTML only coders to deal with the Velocity syntax. Does an HTML person understand what $data.Parameters.getString($key) means? I think not. So, WM/Velocity is good (or at least better than JSP :-) for developing apps where the HTML is developed by people with Java experience - but thats exactly what I believe we should be heading away from. Actually, you have missed the point entirely. I'm not expecting or even asking designers to understand what $data.Parameters.getString($key) means, however, I can expect them to be able to work around those fields in a page. There are several classifications of people who are expected to work on a web application: #1. Designers. People who know HTML. May know some javascript. Nothing more. #2. Template Engineers. People who know how to work with an API and understand the template language (ie: people who understand what $data.Parameters.getString($key) *does*, but may not understand the Java behind it). Eventually, they may become engineers. #3. Java Engineers. People who are responsible for developing the API and doing the Actions. [snip] In contrast XMLC seems to be heading in the right direction because template authors need only understand (pure) HTML. Not that I'm necessarily recommending XMLC as a practical solution, I've never used that either... but I have written YATL, so I feel I have enough experience to comment. Right, however XMLC is push based and that is bad for all the reasons documented in my Pull document. It also has the problem of tying the HTML to the Java code. For example, say you want to break elements of a form across several pages. If you can't do that without editing Java code on the back end, that is bad because then you have to pay java engineers to make the changes that template engineers should be able to do. Seems to me that your argument rests on the assumption that there exists such a beast as a "template engineer" - someone who is skilled in HTML and who understands coding without ever having had formal programming training. Call me traditionalist, but having coding done by non-coders is a recipe for disaster. For example, I think that a template engineer who was capable of rewriting templates to split a form across several pages would probably be worth paying as much as a Java coder anyway. For example, you can easily hire a qualified HTML coder or a Java coder, but it's pretty difficult to hire a qualified "template author", especially when you want them to know your own flavour of YATL. Saying all that I'm sure if you set up your organisation with these three classes of developers it would work. It's simply a question of which way would be more efficient overall. I favour the 2 role way, you the 3 role way. Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only interested in the theoretical issues. It wasn't a flame war. It really saddens me to always be guilty before being proven innocent. Quit thinking that I'm always trying to start a flame war. This is a conversation and if I don't agree with something, that isn't a flame...that is me stating an opinion. Aw, chill out man! You just come across as, er, quite opinionated, thats why people always get the wrong impression. I've been hanging around this scene for long enough to appreciate the way you do stuff... without getting _too_ upset :-) Certainly no need for any paranioa ... :-) I spent a bunch of time coming up with valid reasons why other technologies are sorely lacking. At least you could do the same. I think I am! :-) Cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
"Jon Stevens" [EMAIL PROTECTED] wrote: on 1/11/01 6:32 PM, "Geoff Soutter" [EMAIL PROTECTED] wrote: Certainly I've never seen what I consider to be a clean way of letting HTML people do HTML and Java people do Java. Yes, I've seen some that are better than others (XMLC is probably the cleanest I've seen) XMLC has the disadvantage of being entirely push based. It requires changes to your Java code in order to change your HTML. That is bad. Yeah, but thats an impl detail. You could easily modify it to load the HTML on the fly, so that the HTML could be modified separately. The main thing I like here is that you actually start with a "proper" HTML file, without a proliferation of proprietary "Cold Fusion" style tags. That way HTML codes can actually code real HTML, rather than some weird proprietary HTML sublanguage. Allaires "content management" thingo Spectra defines 400 + tags - how is your average HTML coder gonna deal with that? Course, it has other problems but hey, that was my original thesis ... unfortunately the real world is a complex place :-). , but there are always problems if you consider anything other than completely simplistic examples. Witness Jon's Pull Model document... :-) Geoff Weren't you implying that under complex (read real world) scenarios, the tradtional Webmacro "push" style way of doing things breaks down? Thats all I was saying. Note your pull model Webmacro starts to sound like JSP to me... interpreted HTML... Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
TC4: small suggestion for classloader docs
Hi Craig, I've just been looking through Bootstrap.java and the classloader docs in Catalina because I need to do some classloading hacks of my own. Congrats, the code is really clear and it's (finally) helped me understand how the whole classloader delegation thing works. Anyway, just a nitpick, but there's a slightly confusing thing: the System classloader in the Bootstrap.java doesn't correspond to the "System" classloader in the docs - instead it corresponds to the "Common" classloader ... I think it'd be a bit clearer if they were synchronised... :-) Also, maybe it'd be better to get the "build dist" process to extract the docs into a directory separate from the src dir? I didn't think of looking for them there originally... Cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: small suggestion for classloader docs
Anyway, just a nitpick, but there's a slightly confusing thing: the System classloader in the Bootstrap.java doesn't correspond to the "System" classloader in the docs - instead it corresponds to the "Common" classloader ... I think it'd be a bit clearer if they were synchronised... :-) Don't blame Craig, it's my fault actually (I added the new system classloader). Ah, yes, I forgot Craig is infallible :-). His code is so clean I almost weep when I read it... Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4.0 current dir problems
Hi there Craig, I've been attempting to set up Tomcat 4.0 b1 for my own use, and I've found I have a bit of an issue with the way that it handles the "current directory". Usually I like to install a servlet container once and have multiple configurations for it set up in different directories (e.g. a server.xml and some webapps - I need this to work with our version control system). To do this I like to rely on the current directory to find the various config files. However, catalina sets the effective current directory for the -config option (and some other things, by the look) to CATALINA_HOME, which kind of breaks this way of doing things. This presumably means I would have to hard code full path names to the conf file, and from there to all the webapp dirs, etc. Unfortunatelty this is incompatible with our VC system which creates working dirs with a different name each time... Is there a good reason that catalina can't use the user's current directory as the base for relative paths? Perhaps even check for a file in the users current dir and _then_ check for the file in CATALINA_HOME? If you think it's not likely to cause problems I could probably do a patch... cheers Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [tomcat 4.0] Turning off random number seeding
Jon, I thought the RNG only took around 5 seconds on that kind of machine. Are you sure it's not classloading taking the time? I found removing the manifest from my .jar files can make up to an order of magnitude difference on some servlet engines... Cheers Geoff - Original Message - From: "Jon Stevens" [EMAIL PROTECTED] To: "tomcat-dev" [EMAIL PROTECTED] Cc: "Turbine" [EMAIL PROTECTED] Sent: Monday, December 18, 2000 1:03 PM Subject: [tomcat 4.0] Turning off random number seeding Sorry for the cross posting. See log file below. Ok, between "doGet() Start 1" and "doGet() Start 2" is essentially a call to getServletConfig(). Obviously, Tomcat must be initializing the RNG at that point because the next round doesn't produce that in the log and also it is quite fast. So: How the heck do I turn that off or at least speed it up? It is taking bloody forever (over a minute on a PIII 500mhz!)! I thought that this problem was related to Turbine's loading of Services or at least Tomcat's classloader, but now I see that the problem is definitely in the RNG! :-( :-( -jon 2000-12-17 17:56:28 StandardHost[localhost]: Deploying web application at context path /scarab from URL file:e:\projects\scarab2\target\webapps\scarab 2000-12-17 17:56:29 ContextConfig[/scarab]: Configured an authenticator for method BASIC 2000-12-17 17:56:29 StandardWrapper[/scarab:default]: Loading container servlet default 2000-12-17 17:56:29 default: init 2000-12-17 17:56:29 StandardWrapper[/scarab:invoker]: Loading container servlet invoker 2000-12-17 17:56:29 invoker: init 2000-12-17 17:56:29 jsp: init 2000-12-17 17:56:31 scarab: init 2000-12-17 17:56:31 scarab: Turbine: init() Start Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: init() Finish Initializing Services! 2000-12-17 17:56:32 scarab: Turbine: ready to rumble! 2000-12-17 17:56:32 scarab: Turbine: doGet() Start 1! 2000-12-17 17:56:32 Manager[/scarab]: Seeding random number generator class java.security.SecureRandom 2000-12-17 17:56:32 Manager[/scarab]: Seeding of random number generator has been completed 2000-12-17 17:57:23 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:23 scarab: Turbine: doGet() Start Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Finish Initializing Services! 2000-12-17 17:57:26 scarab: Turbine: doGet() Start 3! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 1! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 2! 2000-12-17 17:57:27 scarab: Turbine: doGet() Start 3! -- Honk if you love peace and quiet.
Tomcat 4.0 m4 filter impl.
Hi there, I've got some questions about Servlet API 2.3 Filters and the Tomcat 4.0 m4 implementation of them. I've been thinking about implementing one of those new-fangled Filter things. I've been reading the spec, and I've found a few things which are unclear. I've also read the source for Tomcat 4.0 m4 where appropriate to try and figure out what is currently implemented, and I'd like to know how the implementation relates to the unclear areas that I've found in the spec. The areas I'm confused about follow: 1) Filters and UnavailableException Filters can throw UnavailableException, but the 2.3 PFD doesn't seem to specify what to do with them if it does. It looks like Tomcat 4.0 m4 disables the Servlet that the request referenced. This doesn't seem like a very good idea to me, primarily because there is not necessarily a 1:1 mapping between a Filter and the Servlet it is filtering. For example, imagine if you had an authentication filter which was protecting a few static files in a subdir of your context. If the filter died and thew UnavailableException, that would mean that the DefaultServlet which is serving all the static content for your webapp would be disabled. Perhaps in this case the Filter itself ought to be disabled? It would be more work, but it would seem more consistent. 2) Filters and RequestDispatcher Filters are apparently allowed to call the include() and forward() methods of RequestDispatcher. However, the 2.3 PFD doesn't seem to mention if those calls should invoke the filter chain again or if they are supposed to reference the target servlet directly. It looks like Tomcat 4.0 m4 references them directly. I'm not sure which is the best way, but I can see some potential problems with the way Tomcat is doing it. For example, imagine if you had a nice site you'd written in XML and which used an XSLT filter transform the content into HTML. Then, you wrote an authentication filter which is inserted in the filter chain before the XSLT filter. It forward()s to "login-error.xml" when the user enters the wrong password. What happens? the login-error.xml is sent to the client directly, without the XSLT transformation. Not nice. Would anyone care to comment on what they think is the right behaviour in these cases, or to clarify my confusion? Cheers Geoff
[CATALINA] M4 source build fails?
Hi there Craig et al, I just downloaded the m4 source archives as per the message sent recently and ant and regexp from cvs and followed the intructions, but I can't get it to build. Looks to me like theres a problem with the javadoc steps. When I execute: D:\apps\jakarta\40-m4\jakarta-tomcat-4.0build dist I get: snip BUILD FAILED D:\apps\jakarta\40-m4\jakarta-tomcat-4.0\build.xml:89: srcdir D:\apps\jakarta\40-m4\jakarta-servletapi\docs\api does not exist! It seems to be looking in the servlet api source dir for the docs, which according to the servlet api build.xml are deposited in the build dir rather than the source dir. Is this just another case of me not reading carefully enough or is there a problem in here somewhere? cheers Geoff PS, I noticed during the JMX download that there are two competing download files, the "JMX Instrumentation Reference Implementation 1.0 ( .56 MB )" and "JMX Instrumentation and Agent Reference Implementation 1.0 ( 1.24 MB )". I guessed the first one and got it wrong, perhaps a note in the readme to say which download file is required would be a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
