Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Alex Fernández

Hi Brad!

Brad Cox wrote:
 I should point out at the outset that this isn't to assign blame but
 to point out a problem... namely, the complexity that developers must
 deal with to get a working infrastructure in place. My application
 uses Apache, JServ, Java, and the servlet engine from Tomcat. Period.
 No taglibs, no JSP, no XML, nothing. Yet it took a whole week to get
 even this on the air, even though I've been through the tomcat
 configuration process dozens of time by now and had working config
 files to start with.

I'm about to answer in Jon's favorite manner (hope you don't mind, Jon):
Ok, it seems to be a problem. Why don't you fix it?

 Next problem was various JServ failures, none clearly explained by
 the errors, and none explaining what what was wrong and how to
 correct it in the config files. Then most of the week worrying about
 why Tomcat wasn't recognizing my servlet context.

Would adding a 'try{} catch() {}' help solve your problem?

 I've a bunch of ideas for partial solutions but I'll hold off on
 those to see whether there's any agreement that there's a problem
 here.

Then, turn those ideas into patches and send them along. No need for
agreement, just an itch to scratch.

I don't want to play the wise guy here, it's just that (at last) the
meaning of voluntary work has entered my stubborn head. As in those old
jokes about screwing a bulb: when there's 100 users complaining about a
problem, there's 10 people talking about how to correct it, and one that
actually does something. The volunteer is the 1 in 111 that screws the
bulb.

For me, Tomcat has worked perfectly (esp. v3.3), and so I cannot justify
my working on it. But, as a consequence, I don't either complain about
the product -- in fact, it's got my highest praises.

Un saludo,

Alex.



RE: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Paulo Gaspar

I tried XSLT (... I really tried!!!) FreeMarker, WebMacro 
and Velocity.

I stay with Velocity.
(Life and templates sure can be simpler than XSLT.)


Have fun,
Paulo Gaspar

 -Original Message-
 From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, April 04, 2001 19:05
 
 You're right!
 That's another reason to use a model 2 based approach but, of 
 course, JSP still
 allows you to shoot you on your foot if you are fool enough to do 
 so. That's one
 of the reasons we chose a model 2 based approach with XML-XSLT 
 for the interface
 creation, no JSP involved: no feet in danger ;).
 just my 2c,
 Dan
 
 Jon Stevens wrote:
 
  I know that these are just minor bugs in Tomcat (and other servlet
  containers as well), but man, this is getting ridiculous. This 
 is clearly
  yet another reason to not use JSP. Especially when you have 
 sites like this:
 
  http://www.devshed.com/Server_Side/Jserv/JSP5/page3.html
 
  Actually *encouraging* people to put their usernames and passwords into
  their JSP files. The term "Gross negligence" comes to mind.
 
  -jon
 
 
 ...snip for brevity's sake
 



RE: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Paulo Gaspar

I sure had my "little" flames with Jon, but that is a very important 
thing I learned from him.

I agree that the problem is there - not enough error info - and I had my 
share of such problems, but this is open source, so, you can fix it.

OTOH, some developers can still learn a bit from this kind of feedback 
and pay a bit more of attention to providing good debug info.


Have fun,
Paulo Gaspar

 -Original Message-
 From: Alex Fernandez [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 05, 2001 10:03
 
 
 Hi Brad!
 
 ...
 
 I'm about to answer in Jon's favorite manner (hope you don't mind, Jon):
 Ok, it seems to be a problem. Why don't you fix it?
 
 ... 

 Un saludo,
 
 Alex.
 



mod_jk in a cluster

2001-04-05 Thread Bernd Koecke

Hi,

we want to use tomcat 3.2.1 in a cluster-environment. This is not a
request that someone else should code something. I think I have a
solution, but may be others are interested in it too.

We have, lets say three cluster-computer (server) and one simple
load-balancer. The load-balancer doesn't look in the Packets and doesn't
know something about Sessions etc. The server are running with apache +
tomcat. apache with mod_jk. The following things could happen:

- a request arrives at a server without a session = it should be routed
to tomcat on this server
- a request with a session on another server arrives = should be routed
to the other server
- a request with a session on this server arrives = should be routed to
this server
- a request with a session on a server which is down arrives = use
another server and send him the request. The session is not present
there and our application handles this

Is there a way to get this with existing modules? My solution plays
around with mod_jk as follows:

The easiest way is to switch off load-balancing and recovering with an
additional property in the config. But I could understand if someone
says this should be a new module. But it could work with mod_jk. For
this I use the lb_worker which controls three ajp13-worker on every
server. The ajp13-worker are connected to the three tomcats. Now I have
two possibilities:

- set the lb_value of the worker for the local tomcat to 1 and 1 for
the other workers, then switch off load-balancing by setting lb_factor
to 0.0. This should give an error because of the validate-function, but
it could be fixed with a small patch.
- setting the lb_value for the worker which is connected to tomcat on
the same server to -1 and 1 for the others and the lb_factor to a
negative value. 

Both solutions are incorrect if one of the tomcats goes down, because of
the recovering. So I come to the first idea, to use an additional flag.
If it works here, are there interests in a diff of mod_jk?

Bernd
-- 
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: [EMAIL PROTECTED]



Re: Just say no to JSP Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Mark T. Harris

 I do have all the latest jar files from SUNW, and jakarta-apache. So I
 don't know what the problems could be. My only complaints would be not
 enough debug tools around to be able to single step through new code
 when you are having problems, but I consider that minor at this point,
 given where the tomcat development cycle is.

I've investigated a LOT of reported Tomcat "bugs" where I work that turned
out to be garden-variety bugs in the application (apps not dealing correctly
with bad data, apps exiting the JVM because something unexpected happened,
etc.).

The only issue we've found that didn't appear to be an application bug was
one where CPU usage trended to 100% over the span of an hour or so.  This
was on Tomcat 3.2.1/Solaris ?/JDK 1.2.?.  The problem vanished when we
switched the environment to JDK 1.3.  Given that, we never did take the time
to figure out the exact problem.

Anyhow, the jdb debugger that is included with jdk 1.3 works pretty well for
debugging servlet/JSP code when nothing else is available.  The command
interface takes a few minutes to understand, but it does get the job done.
And of course, to debug JSP code, you really have to go after the generated
servlet.

It's not pretty, but it does work.

During development, a lot of people around here use JBuilder to
develop/debug JSP and servlet code.  It works well for us.





LXR view of tomcat src?

2001-04-05 Thread Torgeir Veimo

Is there anyone that maintain an LXR (or cvsweb) view of the tomcat
development source, or current beta3 source somewhere?

-- 
- Torgeir



jasper bug

2001-04-05 Thread Samuel Niles Peretz

org/apache/jasper/runtime/JspRuntimeLibrary.java
in the method: introspecthelper
This is a fix for the bug in handling jsp:setProperty for text fields (as posted in
previous bug reports such as http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1207)
where set method of property is not invoked for blank text fields.

The fix is simply to add another condition in the if statement that checks for a
null or blank value.  The method should only return on a blank value if the type of
the property is something other than java.lang.String.  That is, for a property of
type java.lang.String, the method should invoke the set method for that property
even if the value is blank.

Here is the unified diff, with the original version first:

diff -ubB /tmp/saved/JspRuntimeLibrary.java
/dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.java
--- /tmp/saved/JspRuntimeLibrary.java   Thu Apr 05 10:12:32 2001
+++ /dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.javaThu
Apr 05 10:17:18 2001
@@ -194,7 +194,7 @@
 createTypedArray (bean, method, values, t);
 }
 } else {
-   if(value == null || (param != null  value.equals(""))) return;
+   if(value == null || (param != null  value.equals("") 
!type.getName().equals( "java.lang.String" ))) return;

 Object oval = convert(value, type);
 if ( oval != null )
 method.invoke(bean, new Object[] { oval });





RE: TC3.2.x and security problems

2001-04-05 Thread Marc Saegesser

Here's an update.  I've installed JDK1.3.0 and JDK1.3.1-beta and tested the
following URLs.

All the tests were run on Win2000 using Tomcat 3.2.2b2.  The only difference
between these runs was the value of the JAVA_HOME environment variable.

The security problems I could duplicate *only* occurred when using JDK1.3.x.
They *never* happened with JDK1.2.2.  I was able to duplicate problems
(directory listing and file contents) for URLs using sequences of
/%252e%252e to 'escape' from the web application directory.  None of the
/%2e%2e attacks worked.

I would appreciate it if others could try these URLs on other platforms to
see if their results vary.  I'm going to investigate the JDK1.3 issues on
Win2000.

GET /examples/jsp/num/numguess.jsp%00
   JDK1.2.2 -- 404
   JDK1.3.0 -- 404
   JDK1.3.1 -- 404

GET /%252e%252e/%252e%252e/%00.jsp
   JDK1.2.2 -- 404
   JDK1.3.0 -- Directory listing
   JDK1.3.1 -- Directory listing

GET /examples/jsp/num/numguess.js%2570
   JDK1.2.2 -- 404
   JDK1.3.0 -- 404
   JDK1.3.1 -- 404

GET /%2e%2e/%2e%2e/%00.jsp
   JDK1.2.2 -- 404
   JDK1.3.0 -- 404
   JDK1.3.1 -- 404

GET /%2e%2e/%2e%2e%5cLICENSE/%00.jsp
   JDK1.2.2 -- 404
   JDK1.3.0 -- 404
   JDK1.3.1 -- 404

GET /%252e%252e/%252e%252e%5cLICENSE/%00.jsp
   JDK1.2.2 -- 404
   JDK1.3.0 -- File contents
   JDK1.3.1 -- File contents





[PATCH Suggestion] Tomcat 3.2.x adapter in load balancing using URL

2001-04-05 Thread Benoit Derouet


Hi, 

The load balancer worker fail to handle load balancing if the
application use sticky session managed by URL.
The load balancer look for a the parameter "jsessionid" in the URL, and
then can find the worker to contact for the request.
First, the JK_PATH_SESSION_IDENTIFIER in jk_global.h is set to
";jsessionid", but this should be set to "jsessionid".

In jk_lb_worker.c, the function "get_path_param" should return a the
parameter with a given name, but this function look in the URI
(jk_ws_service_t-req_uri), and not in the parameters
(jk_ws_service_t-query_string).
So this function always return NULL.

So here is a suggestion for the "get_path_param" function : 

static char *get_path_param(jk_ws_service_t *s,
const char *name,
jk_logger_t *l)
{

char *id_start = NULL;

if(s-query_string) {

for(id_start = strstr(s-query_string, name) ; 
id_start ; 
id_start = strstr(id_start + 1, name)) {
if('=' == id_start[strlen(name)]) {
/*
 * Session path-cookie was found, get
it's value
 */
id_start += (1 + strlen(name));
if(strlen(id_start)) {
char *id_end;
id_start =
jk_pool_strdup(s-pool, id_start);
/* 
 * The query string is not part
of req_uri, however
 * to be on the safe side lets
remove the trailing query 
 * string if appended...
 */
if(id_end = strchr(id_start,
'?')) { 
*id_end = '\0';
}
return id_start;
}
}
}
}
  
return NULL;
}

and the JK_PATH_SESSION_IDENTIFIER must be change to "jsessionid" in
jk_global.h.

With those two changes, it works fine. I test it on Windows 2000 with
iis and Tomcat 3.2.1.

regards

Benoit.






RE: jasper bug

2001-04-05 Thread Larry Isaacs

Hi,

Thanks for the patch. But unfortunately, this would make jasper
non-spec compliant. The JSP 1.1 spec in section 2.13.2.1 states
that for the use of propertyName="*":

   If a parameter has a value of "", the corresponding property
   is not modified.

No exception is mentioned for properties set with type String.

I have also resolved bug 1207 as invalid for the same reason.

Cheers,
Larry

 -Original Message-
 From: Samuel Niles Peretz [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 05, 2001 10:22 AM
 To: [EMAIL PROTECTED]
 Subject: jasper bug
 
 
 org/apache/jasper/runtime/JspRuntimeLibrary.java
 in the method: introspecthelper
 This is a fix for the bug in handling jsp:setProperty for 
 text fields (as posted in
 previous bug reports such as 
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1207)
 where set method of property is not invoked for blank text fields.
 
 The fix is simply to add another condition in the if 
 statement that checks for a
 null or blank value.  The method should only return on a 
 blank value if the type of
 the property is something other than java.lang.String.  That 
 is, for a property of
 type java.lang.String, the method should invoke the set 
 method for that property
 even if the value is blank.
 
 Here is the unified diff, with the original version first:
 
 diff -ubB /tmp/saved/JspRuntimeLibrary.java
 /dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrary.java
 --- /tmp/saved/JspRuntimeLibrary.java   Thu Apr 05 10:12:32 2001
 +++ 
 /dev/main/jetty/src/org/apache/jasper/runtime/JspRuntimeLibrar
 y.javaThu
 Apr 05 10:17:18 2001
 @@ -194,7 +194,7 @@
  createTypedArray (bean, method, values, t);
  }
  } else {
 -   if(value == null || (param != null  
 value.equals(""))) return;
 +   if(value == null || (param != null  
 value.equals("") 
 !type.getName().equals( "java.lang.String" ))) return;
 
  Object oval = convert(value, type);
  if ( oval != null )
  method.invoke(bean, new Object[] { oval });
 
 



one file at a time.

2001-04-05 Thread pushpendra . singh

I am developing a web page, which will have the link to copyright protected
reference materials. I will be using some web-builder tool such as
front-page or dream-weaver.
The problem faced is the implementation of access control over the refrence
material, which is nothing but pdf files. the control should be such that
when a user is aacessing, viewing or using a file no other user user should
be able to view or access that file i.e. one user, one file at a time.
I am in a fix, what to do?
should i use the singlethreadmodel interface of servlet or jsp to develop
this control, but i am afraid that i will end up in writing 300 servlet
classes each crresponding to one pdf file.
Any suggestions addressing this problem?
Thanking you.

Pushpendra Singh.




Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Mel Martinez


--- Nick Bauman [EMAIL PROTECTED] wrote:
 Read Jon's article about the problems of JSP.
 
 http://jakarta.apache.org/velocity/ymtd/ymtd.html
 
 I read it and it made me rethink a lot of
 assumptions I had made about JSP.
 

Without getting into the larger debate - actually
agree with many of the article's issues - the
following paragraph, though, bothers me:
---
There are some fundamental issues that are being dealt
with in the generated .jsp template. The first one is
the class name. What happens is that the engine needs
to produce a name that is unique in order to work
around class loader issues that might crop up.
Therefore, each and every time one modifies a .jsp
page, a new file is created on disk in the temporary
directory. Unfortunately, this directory ends up
growing in size until someone decides to clean it up.
The engine could probably do this for you, except then
it might make the mistake of actually removing the
wrong file.
[from
http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html
]

The above paragraph describes a 'fundamental issue'
that has absolutely nothing to do with the Java Server
Pages specification and, rather, entirely to do with a
particular implementation of the specification.  As
such, it has no legitimate argumentative value here
and seems quite gratuitous.  The statement 'The engine
could probably do this for you, except then it might
make the mistake of actually REMOVING THE WRONG FILE.'
(emphasis mine) is a blatant appeal to fear.  I highly
doubt this was intentional on Jon's part, but that is
what it is.

Jon - you do not need to do this to support your
arguments.  Please retract this paragraph from the
essay when convenient.

Also, in your discussion on error handling, the fact
that JSP's only catch Exceptions will be changed in
JSP 1.2 spec to include all Throwables.  And further,
it could be argued that many of your complaints about
poor compilation error messages are again, an artifact
of implementation (maturity), rather than
specification.  However, I (were I to argue such)
would have to concede that in that case the
specification is possibly incomplete (failure to
address standardizing the compile/debug part of the
cycle).

All-in-all, though, I won't argue with the basic
point: Java Server Pages do NOT provide a tool-level
separation between View and Control.  And I wish
others would stop pretending that it did.  

With my team, I try to stress that JSPs can (and
actually should) be used to implement both View and
Control aspects of MVC and to address this we have
adopted (hopefully) strong standards for how we do JSP
development.  There is more to it, but basically we
conceptually separate JSPs into four basic roles:
presentation control, presentation content, request
filtering and pure business.  We then enforce naming
conventions and required strategies to development of
JSPs in these roles.  I don't claim this is ideal, but
it seems to work very well.

I am interested in template solutions like Velocity,
though and intend to look at it closely.

Cheers,

Dr. Mel Martinez
[EMAIL PROTECTED]




__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/



Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Mel Martinez


--- Nick Bauman [EMAIL PROTECTED] wrote:
 Read Jon's article about the problems of JSP.
 
 http://jakarta.apache.org/velocity/ymtd/ymtd.html
 
 I read it and it made me rethink a lot of
 assumptions I had made about JSP.
 

Without getting into the larger debate - actually
agree with many of the article's issues - the
following paragraph, though, bothers me:
---
There are some fundamental issues that are being dealt
with in the generated .jsp template. The first one is
the class name. What happens is that the engine needs
to produce a name that is unique in order to work
around class loader issues that might crop up.
Therefore, each and every time one modifies a .jsp
page, a new file is created on disk in the temporary
directory. Unfortunately, this directory ends up
growing in size until someone decides to clean it up.
The engine could probably do this for you, except then
it might make the mistake of actually removing the
wrong file.
[from
http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html
]

The above paragraph describes a 'fundamental issue'
that has absolutely nothing to do with the Java Server
Pages specification and, rather, entirely to do with a
particular implementation of the specification.  As
such, it has no legitimate argumentative value here
and seems quite gratuitous.  The statement 'The engine
could probably do this for you, except then it might
make the mistake of actually REMOVING THE WRONG FILE.'
(emphasis mine) is a blatant appeal to fear.  I highly
doubt this was intentional on Jon's part, but that is
what it is.

Jon - you do not need to do this to support your
arguments.  Please retract this paragraph from the
essay when convenient.

Also, in your discussion on error handling, the fact
that JSP's only catch Exceptions will be changed in
JSP 1.2 spec to include all Throwables.  And further,
it could be argued that many of your complaints about
poor compilation error messages are again, an artifact
of implementation (maturity), rather than
specification.  However, I (were I to argue such)
would have to concede that in that case the
specification is possibly incomplete (failure to
address standardizing the compile/debug part of the
cycle).

All-in-all, though, I won't argue with the basic
point: Java Server Pages do NOT provide a tool-level
separation between View and Control.  And I wish
others would stop pretending that it did.  

With my team, I try to stress that JSPs can (and
actually should) be used to implement both View and
Control aspects of MVC and to address this we have
adopted (hopefully) strong standards for how we do JSP
development.  There is more to it, but basically we
conceptually separate JSPs into four basic roles:
presentation control, presentation content, request
filtering and pure business.  We then enforce naming
conventions and required strategies to development of
JSPs in these roles.  I don't claim this is ideal, but
it seems to work very well.

I am interested in template solutions like Velocity,
though and intend to look at it closely.

Cheers,

Dr. Mel Martinez
[EMAIL PROTECTED]




__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/



RE: mod_jk in a cluster

2001-04-05 Thread James Courtney

With the exception of failover (case 4 below), I believe that the first
three cases can be handled by having your load balancer be "sticky" by
client address to any of the app servers (machines running Apache with
Tomcat).  Thus if your load balancer receives a request from client
some.client.net and round robin assigns the request to server B, given
servers A, B, and C, then all subsequest requests from some.client.net
should be routed to server B.  If B ever goes down the session information
from some.client.net is lost and the client will have to retry their
session.  To implement a failover system is highly non-trivial and my
understanding is that most application servers (even commercial ones) do not
support this.  In fact I'm told by several coworkers who worked formerly for
BEA and know people there up to and including the B, the E, and the A that
WebLogic only recently got failover with session replication right.  To make
this work you will need a somewhat complicated session replication mechanism
between all app servers which is n(n-1) replications (in this case 6) if
replication is done between all servers and at best n choose 2 (in this case
3, or an extra session "write through" per request if you prefer)
replications if each app server has a single failover server.  That can be a
lot of network traffic and a lot of new code.  If I'm wrong and there's a
way to make this work in Tomcat then kudos to all involved and let me know
how to do it:)!
-Jamey

-Original Message-
From: bk [mailto:bk]On Behalf Of Bernd Koecke
Sent: Thursday, April 05, 2001 4:19 AM
To: tomcat-dev
Subject: mod_jk in a cluster


Hi,

we want to use tomcat 3.2.1 in a cluster-environment. This is not a
request that someone else should code something. I think I have a
solution, but may be others are interested in it too.

We have, lets say three cluster-computer (server) and one simple
load-balancer. The load-balancer doesn't look in the Packets and doesn't
know something about Sessions etc. The server are running with apache +
tomcat. apache with mod_jk. The following things could happen:

- a request arrives at a server without a session = it should be routed
to tomcat on this server
- a request with a session on another server arrives = should be routed
to the other server
- a request with a session on this server arrives = should be routed to
this server
- a request with a session on a server which is down arrives = use
another server and send him the request. The session is not present
there and our application handles this

Is there a way to get this with existing modules? My solution plays
around with mod_jk as follows:

The easiest way is to switch off load-balancing and recovering with an
additional property in the config. But I could understand if someone
says this should be a new module. But it could work with mod_jk. For
this I use the lb_worker which controls three ajp13-worker on every
server. The ajp13-worker are connected to the three tomcats. Now I have
two possibilities:

- set the lb_value of the worker for the local tomcat to 1 and 1 for
the other workers, then switch off load-balancing by setting lb_factor
to 0.0. This should give an error because of the validate-function, but
it could be fixed with a small patch.
- setting the lb_value for the worker which is connected to tomcat on
the same server to -1 and 1 for the others and the lb_factor to a
negative value.

Both solutions are incorrect if one of the tomcats goes down, because of
the recovering. So I come to the first idea, to use an additional flag.
If it works here, are there interests in a diff of mod_jk?

Bernd
--
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: [EMAIL PROTECTED]


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread cmanolache

On Thu, 5 Apr 2001, Mel Martinez wrote:

 The above paragraph describes a 'fundamental issue'
 that has absolutely nothing to do with the Java Server
 Pages specification and, rather, entirely to do with a
 particular implementation of the specification.  As

And most of the other arguments are in the same category - 
bad implementation of the spec.

So we need to fix it :-) After all that's one of the diferences between
the zillion templating systems and jsp - a spec with a wide variety of
implementations that improve.

I do agree with some of Jon's arguments - the spec is not perfect ( but I
don't think HTTP spec is perfect either, or HTML or XSLT or even the
servlet spec - and for many of those I could list more serious reasons
for not using them and choosing a random alternative :-). 

Costin







Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Jon Stevens

Mel,

Please do not CC me directly as I'm already on the list. I have filed your
changes away for when I do my next revision of the site (there are several
other people's comments that I want to integrate as well). I hear you and
you made good suggestions.

Also, I do have to say that those two nits are fairly minor given that the
scope of the entire article is quite large. In other words, there is plenty
of other valid reasons there to not use JSP and that those two nits are
really minor in the grand scope of things. :-)

thanks,

-jon




Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Jon Stevens

on 4/4/01 3:55 PM, "Brad Cox" [EMAIL PROTECTED] wrote:

 Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh.

Yucky.

 I'm so happy to see that more and more people are waking up to the fact that
 JSP is bad. I'm also happy to see you worry about form validation issues.
 That is a problem that we are currently solving in Turbine right now. It is
 called "Intake". :-)
 
 I'll try to make some time to check that out.

I find it funny that you decided to group Turbine and Velocity and Webmacro
into this big statement about (Yet another language) yet you didn't even
really check it out first. That is bad journalism IMHO.

 Sigh. Yet another typo. I really thought we'd caught them all.

Those are just the spelling mistakes...there are plenty of other typo's in
that article.

 #1. Confused "Turbine" with "add programming language features to HTML".
 
 #2. Confused "WebMacro" and thus Velocity with "add programming language
 features to HTML".
 
 If you spend time with the products, you would see that isn't the case and
 you might actually retract your statements.
 
 You've touched a nerve here. This is the amount of time that gets
 consumed installing web based infrastructures.

What does that have to do with any of the above? In fact, if you really take
the time looking at Velocity, you will see that we have included complete
documentation (written by a professional tech writer), numerous working
examples, demo Velocity applications bundled with both versions of Tomcat
all ready to go, etc.

Yes, Turbine needs more work on the examples and documentation front, but it
isn't a released product yet (we plan on a JavaOne release) and will
definitely have much improved documentation and examples before we release.

We are also putting a huge amount of effort into creating a Turbine EE
system that is a bundle of everything you need to get started. It is called
the Turbine Developers Kit (TDK).

[rant removed]

 I'd be grateful to hear them when you get a moment.

I'd be grateful if you would take the time to investigate our solutions (ie:
Velocity and Turbine) before you bash them or decide that they are not
worthy.

:-)

Maybe your next article can be about how much you like Velocity and/or
Turbine.

:-)

-jon




Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Jon Stevens

on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote:

 So we need to fix it :-) After all that's one of the diferences between
 the zillion templating systems and jsp - a spec with a wide variety of
 implementations that improve.
 
 I do agree with some of Jon's arguments - the spec is not perfect ( but I
 don't think HTTP spec is perfect either, or HTML or XSLT or even the
 servlet spec - and for many of those I could list more serious reasons
 for not using them and choosing a random alternative :-).
 
 Costin

I would like to hear what is wrong with Velocity's spec:

http://jakarta.apache.org/velocity/vtl-reference-guide.html

and

http://jakarta.apache.org/velocity/user-guide.html
http://jakarta.apache.org/velocity/developer-guide.html

:-)

-jon




Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Mel Martinez


--- Jon Stevens [EMAIL PROTECTED] wrote:
 Mel,
 
 Please do not CC me directly as I'm already on the
 list. 

Sorry - artifact of how I started the reply (from
browsing the essay).  Oops.

 I have filed your
 changes away for when I do my next revision of the
 site (there are several
 other people's comments that I want to integrate as
 well). I hear you and
 you made good suggestions.
 
 Also, I do have to say that those two nits are
 fairly minor given that the
 scope of the entire article is quite large. In other
 words, there is plenty
 of other valid reasons there to not use JSP and that
 those two nits are
 really minor in the grand scope of things. :-)
 

Oh yes, I hope I made it clear that I don't think my
two little nits in any way invalidate the larger
points.  I am simply offering them as constructive
ways to improve the argument.

Cheers,

Dr. Mel Martinez
[EMAIL PROTECTED]



__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/



Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-05 Thread Matthew Dornquast

I could be wrong given I don't know the full context, but the code from the
article on this page:
http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html  isn't thead
safe, multiple requests coming in on different threads at the same time
would cause init() to be called multiple times.

-Matthew





cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java

2001-04-05 Thread remm

remm01/04/05 11:47:52

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  - Path /. wasn't normalized properly (but /./ was). It's treated as a special case.
  
  Revision  ChangesPath
  1.34  +7 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- DefaultServlet.java   2001/04/02 21:14:19 1.33
  +++ DefaultServlet.java   2001/04/05 18:47:50 1.34
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.33 2001/04/02 21:14:19 craigmcc Exp $
  - * $Revision: 1.33 $
  - * $Date: 2001/04/02 21:14:19 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.34 2001/04/05 18:47:50 remm Exp $
  + * $Revision: 1.34 $
  + * $Date: 2001/04/05 18:47:50 $
*
* 
*
  @@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.33 $ $Date: 2001/04/02 21:14:19 $
  + * @version $Revision: 1.34 $ $Date: 2001/04/05 18:47:50 $
*/
   
   public class DefaultServlet
  @@ -877,6 +877,9 @@
   
   if (normalized == null)
   return (null);
  +
  +if (normalized.equals("/."))
  +return "/";
   
// Normalize the slashes and add leading slash if necessary
if (normalized.indexOf('\\') = 0)
  
  
  



Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

2001-04-05 Thread Jon Stevens

on 4/5/01 5:35 AM, "Matthew Dornquast" [EMAIL PROTECTED]
wrote:

 I could be wrong given I don't know the full context, but the code from the
 article on this page:
 http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html  isn't thead
 safe, multiple requests coming in on different threads at the same time
 would cause init() to be called multiple times.
 
 -Matthew

Yup. I think it has already been fixed in Tomcat (along with some other
problems...ie: the double locked checking as well), but that is the example
that is published in Jason's Servlet book that is coming out soon so I
wanted to use that because his book will be going out to hundreds of
thousands of people...

I'm more concerned with illustrating my point in the essay than pointing out
bad generation of code because that is something that can be fairly easily
fixed.

-jon




cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java

2001-04-05 Thread remm

remm01/04/05 12:03:09

  Modified:catalina/src/share/org/apache/catalina/servlets
WebdavServlet.java
  Log:
  - Prevent COPY method from manipulating anything in /WEB-INF or /META-INF.
Note : That could only happen when a user had red/write access on the
context.
  
  Revision  ChangesPath
  1.16  +18 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
  
  Index: WebdavServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- WebdavServlet.java2001/04/05 18:55:02 1.15
  +++ WebdavServlet.java2001/04/05 19:03:08 1.16
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
 1.15 2001/04/05 18:55:02 remm Exp $
  - * $Revision: 1.15 $
  - * $Date: 2001/04/05 18:55:02 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
 1.16 2001/04/05 19:03:08 remm Exp $
  + * $Revision: 1.16 $
  + * $Date: 2001/04/05 19:03:08 $
*
* 
*
  @@ -125,7 +125,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
  - * @version $Revision: 1.15 $ $Date: 2001/04/05 18:55:02 $
  + * @version $Revision: 1.16 $ $Date: 2001/04/05 19:03:08 $
*/
   
   public class WebdavServlet
  @@ -1481,10 +1481,24 @@
   }
   }
   
  +destinationPath = normalize(destinationPath);
  +
   if (debug  0)
   System.out.println("Dest path :" + destinationPath);
   
  +if ((destinationPath.toUpperCase().startsWith("/WEB-INF")) ||
  +(destinationPath.toUpperCase().startsWith("/META-INF"))) {
  +resp.sendError(WebdavStatus.SC_FORBIDDEN);
  +return false;
  +}
  +
   String path = getRelativePath(req);
  +
  +if ((path.toUpperCase().startsWith("/WEB-INF")) ||
  +(path.toUpperCase().startsWith("/META-INF"))) {
  +resp.sendError(WebdavStatus.SC_FORBIDDEN);
  +return false;
  +}
   
   if (destinationPath.equals(path)) {
   resp.sendError(WebdavStatus.SC_FORBIDDEN);
  
  
  



LoadBalancer worker

2001-04-05 Thread Vikas Bansal


Hello,
I want to enable the load balancer worker on Apache/Tomcat. Even though
I have configured the workers.properties file as -
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2,
myajp13_2

The load balancer worker is not invoked, for I do see the debug
statements for lb worker in mod_jk.log.

Could you tell me, what is it that I am doing. What additional
configuration do I need to do to enable load balancer.

Any help in this regard is appreaciated.
-Vikas.




RE: LoadBalancer worker

2001-04-05 Thread GOMEZ Henri

Hello,
I want to enable the load balancer worker on Apache/Tomcat. Even though
I have configured the workers.properties file as -
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2,
myajp13_2

Don't forget to add loadbalancer to workers list !


The load balancer worker is not invoked, for I do see the debug
statements for lb worker in mod_jk.log.

Could you tell me, what is it that I am doing. What additional
configuration do I need to do to enable load balancer.

Any help in this regard is appreaciated.
-Vikas.




cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF web.xml

2001-04-05 Thread craigmcc

craigmcc01/04/05 12:30:40

  Modified:catalina/src/conf web_23.dtd
   catalina/src/share/org/apache/catalina Context.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java
   catalina/src/share/org/apache/catalina/startup
ContextConfig.java
   jasper/src/share/org/apache/jasper/resources web_23.dtd
   webapps/examples/WEB-INF web.xml
  Added:   catalina/src/share/org/apache/catalina/deploy
ContextLocalEjb.java
  Log:
  Implement the following changes in the web application deployment descriptor
  DTD, per approval by the JSR-053 Expert Group:
  
  * The run-as element now has description and role-name subelements.
  
  * The new local-ejb-ref element describes an optional capability that
allows a web application to reference a local EJB, if supported by the
container.
  
  Revision  ChangesPath
  1.4   +50 -3 jakarta-tomcat-4.0/catalina/src/conf/web_23.dtd
  
  Index: web_23.dtd
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web_23.dtd,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- web_23.dtd2001/03/22 17:19:37 1.3
  +++ web_23.dtd2001/04/05 19:30:39 1.4
  @@ -6,7 +6,7 @@
   !ELEMENT web-app (icon?, display-name?, description?, distributable?, 
context-param*, filter*, filter-mapping*, listener*, servlet*, servlet-mapping*, 
session-config?,
   mime-mapping*, welcome-file-list?, error-page*, taglib*,
   resource-env-ref*, resource-ref*, security-constraint*, login-config?, 
security-role*,
  -env-entry*, ejb-ref*)
  +env-entry*, ejb-ref*, ejb-local-ref*)
   
   !--
   Declares a filter in the web application. The filter is mapped to either a servlet 
or a URL pattern in the filter-mapping element, using the filter-name value to 
reference. Filters can access the initialization parameters declared in the deployment 
descriptor at runtime via the FilterConfig interface.
  @@ -574,11 +574,55 @@
   
   
   !--
  -The run-as element must contain the name of a security role defined for this web 
application. If the optional run-as element is used for a servlet definition, the 
security identity of a call to any EJBs from the servlet must be propogated as the 
security role with the same name.
  +The ejb-local-ref element is used for the declaration of a reference to
  +an enterprise bean's local home. The declaration consists of:
   
  + - an optional description
  + - the EJB reference name used in the code of the web component
  +   that's referencing the enterprise bean
  + - the expected type of the referenced enterprise bean
  + - the expected local home and local interfaces of the referenced
  +   enterprise bean
  + - optional ejb-link information, used to specify the referenced
  +   enterprise bean
  +
  +Used by web-app
  +--
  +
  +!ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type,
  + local-home, local, ejb-link?)
  +
  +!-- 
  +
  +The local element contains the fully-qualified name of the
  +enterprise bean's local interface. 
  +
  +Used by ejb-local-ref
  +
  +--
  +!ELEMENT local (#PCDATA)
  +
  +!-- 
  +
  +The local-home element contains the fully-qualified name of the
  +enterprise bean's local home interface. 
  +
  +Used by ejb-local-ref
  +--
  +!ELEMENT local-home (#PCDATA)
  +
  +
  +
  +
  +!--
  +The run-as element, if defined for a servlet, overrides the security identity used 
to call an EJB
  +by that servlet in this web application. The role-name is one of the security roles 
already
  +defined for this web application.
  +
  +Used by: servlet
   --
  +!ELEMENT run-as (description?, role-name)
   
  -!ELEMENT run-as (#PCDATA)
   
   
   !--
  @@ -664,4 +708,7 @@
   !ATTLIST home id ID #IMPLIED
   !ATTLIST remote id ID #IMPLIED
   !ATTLIST ejb-link id ID #IMPLIED
  +!ATTLIST ejb-local-ref id ID #IMPLIED
  +!ATTLIST local-home id ID #IMPLIED
  +!ATTLIST local id ID #IMPLIED
   !ATTLIST run-as id ID #IMPLIED
  
  
  
  1.16  +37 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java
  
  Index: Context.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- Context.java  2001/02/26 03:49:23 1.15
  +++ Context.java  2001/04/05 19:30:39 1.16
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 
1.15 2001/02/26 03:49:23 glenn Exp $
  - * $Revision: 1.15 $
  - * $Date: 2001/02/26 03:49:23 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Context.java,v 
1.16 2001/04/05 

Re: LoadBalancer worker

2001-04-05 Thread Vikas Bansal

Yes it is there. Sorry I did not mention it earlier-
worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer

GOMEZ Henri wrote:

 Hello,
 I want to enable the load balancer worker on Apache/Tomcat. Even though
 I have configured the workers.properties file as -
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2,
 myajp13_2

 Don't forget to add loadbalancer to workers list !

 
 The load balancer worker is not invoked, for I do see the debug
 statements for lb worker in mod_jk.log.
 
 Could you tell me, what is it that I am doing. What additional
 configuration do I need to do to enable load balancer.
 
 Any help in this regard is appreaciated.
 -Vikas.
 




cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B4.txt

2001-04-05 Thread craigmcc

craigmcc01/04/05 12:37:01

  Added:   .RELEASE-NOTES-4.0-B4.txt
  Log:
  Start release notes for the next round.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B4.txt
  
  Index: RELEASE-NOTES-4.0-B4.txt
  ===
Apache Tomcat Version 4.0 Beta 4
=
  Release Notes
  =
  
  $Id: RELEASE-NOTES-4.0-B4.txt,v 1.1 2001/04/05 19:37:01 craigmcc Exp $
  
  
  
  INTRODUCTION:
  
  
  
  This document describes the changes that have been made in the current
  beta release of Apache Tomcat, relative to the previous release.
  
  Bug reports should be entered at the interim bug reporting system for
  Jakarta projects at:
  
  http://nagoya.apache.org/bugzilla/
  
  Please use project codes "Catalina" and "Jasper" for servlet-related and
  JSP-related bug reports, respectively.
  
  
  
  NEW FEATURES:
  
  
  
  -
  Catalina New Features:
  -
  
  DTD Changes:  Catalina now supports the most recent changes to the web
  application deployment descriptor approved by the JSR-053 expert group:
  * The run-as element now has description and role-name subelements.
  * The new local-ejb-ref element (and associated subelements) supports
the optional EJB feature of local EJBs.
  
  
  ---
  Jasper New Features:
  ---
  
  
  
  Webapps New Features:
  
  
  
  ==
  BUG FIXES AND IMPROVEMENTS:
  ==
  
  
  --
  Catalina Bug Fixes:
  --
  
  
  
  Jasper Bug Fixes:
  
  
  
  -
  Webapps Bug Fixes:
  -
  
  
  
  KNOWN ISSUES IN THIS RELEASE:
  
  
  
  --
  Redeploying From a Web Application Archive:
  --
  
  If you attempt to undeploy, then redeploy, an application from the same
  web application archive file URL (where the URL refers to an actual WAR
  file, not to a directory), the redeploy will fail with error "zip file is
  closed".  There appears to be a problem in the JDK's JarURLConnection class
  where JAR files are cached, even after they are closed, so that a request
  for a connection to the same URL returns the previous JarFile object instead
  of a new one.  As a workaround, you should do one of the following:
  * Change the URL of the web application archive each time you redeploy.
  * Deploy from an unpacked directory (on the same server) instead of from
a WAR file (this is often more convenient in a development environment
anyway).
  
  
  --
  Tomcat 4.0 and XML Parsers:
  --
  
  Previous versions of Tomcat 4.0 exposed the XML parser used by Jasper (the
  JAXP/1.1 reference implementation) to web applications.  This is no longer
  the case, because Jasper loads its parser with a new class loader instead.
  Keep the following points in mind when considering how to use XML parsers
  in Tomcat 4.0 and your web applications:
  
  * If you wish to make the JAXP/1.1 RI XML parser available to all web
applications, simply move the "jaxp.jar" and "crimson.jar" files from
the "$TOMCAT_HOME/jasper" directory to the "$TOMCAT_HOME/lib" directory.
  
  * If you wish to make another XML parser that is JAXP/1.1-compatible
available to all web applications, install that parser into the
"$TOMCAT_HOME/lib" directory and remove "jaxp.jar" and "crimson.jar"
from the "$TOMCAT_HOME/jasper" directory.  It has been reported that
Xerces 1.3.1 can be used in this fashion, but 2.x alpha releases
can not be.
  
  * If you wish to use an XML parser (such as Xerces) in the WEB-INF/lib
directory of your web application, this should now be possible, because
of the modified JAXP 1.1 parser mentioned below.
  
  WARNING:  Tomcat 4.0 now ships with a modified version of the JAXP/1.1
  (Final) "jaxp.jar" and "crimson.jar" files in the "jasper" subdirectory.
  The "sealed" attribute has been removed from the manifest file for these
  two JARs, to avoid "package sealing violation" errors that were caused by
  them in a JDK 1.3 environment.  You MUST NOT replace these files with a
  different (or later) release of JAXP, unless that later release has had
  the sealed attribute removed, or you will encounter "package sealing violation"
  errors when trying to use a different XML parser in a web application.
  
  
  



RE: LoadBalancer worker

2001-04-05 Thread GOMEZ Henri

did you do ?

JkMount /examples/servlet/* loadbalancer
JkMount /examples/*.jsp loadbalancer

-Original Message-
From: Vikas Bansal [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 9:31 PM
To: [EMAIL PROTECTED]
Subject: Re: LoadBalancer worker


Yes it is there. Sorry I did not mention it earlier-
worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer

GOMEZ Henri wrote:

 Hello,
 I want to enable the load balancer worker on Apache/Tomcat. 
Even though
 I have configured the workers.properties file as -
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, 
myajp12_2,
 myajp13_2

 Don't forget to add loadbalancer to workers list !

 
 The load balancer worker is not invoked, for I do see the debug
 statements for lb worker in mod_jk.log.
 
 Could you tell me, what is it that I am doing. What additional
 configuration do I need to do to enable load balancer.
 
 Any help in this regard is appreaciated.
 -Vikas.
 




Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script sourcecode by URL trickery]

2001-04-05 Thread cmanolache

On Thu, 5 Apr 2001, Jon Stevens wrote:

 on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote:
 
  So we need to fix it :-) After all that's one of the diferences between
  the zillion templating systems and jsp - a spec with a wide variety of
  implementations that improve.
  
  I do agree with some of Jon's arguments - the spec is not perfect ( but I
  don't think HTTP spec is perfect either, or HTML or XSLT or even the
  servlet spec - and for many of those I could list more serious reasons
  for not using them and choosing a random alternative :-).
  
  Costin
 
 I would like to hear what is wrong with Velocity's spec:
 
 http://jakarta.apache.org/velocity/vtl-reference-guide.html
 http://jakarta.apache.org/velocity/user-guide.html
 http://jakarta.apache.org/velocity/developer-guide.html

Nothing wrong - yet another fine language, and a very nice implementation. 
And nothing good either - or I coulnd't find anything revolutionary
compared with other programming languages or other fine template-like 
systems. 

Arguing what is the best programming language or if interpreted is better
than compiled is mostly a waste of time. Some people will prefer to learn
VTL, other will prefer to use Java, other will like the XML-like syntax.

I think code generation is a good thing, and I prefer using Jsp with Java
for quick prototypes and taglibs when possible.

Costin


















TC 4.0B2 problems when compiled with jikes : Was RE: TC 4.02 error = jikes 1.3 problem

2001-04-05 Thread GOMEZ Henri

Hi,

Did someone (Remy, Craig) has an idea about the problem 
at startup with a TC 4.0 compiled with jikes 1.3 ?



 Hi,

 Just trying a clean rebuilt of TC 4.0b2 and got :

 Using CLASSPATH:
 /var/tomcat4/bin/bootstrap.jar:/opt/IBMJava2-13/lib/tools.jar
 Using CATALINA_HOME: /var/tomcat4
 Starting service Tomcat-Standalone
 Apache Tomcat/4.0-b2
 Exception during startup processing
 java.lang.reflect.InvocationTargetException:
java.lang.NoClassDefFoundError:
 org/apache/naming/factory/Constants
 at org.apache.naming.ResourceRef.clinit(ResourceRef.java)
 at

org.apache.catalina.core.StandardContext.createNamingContext(St
andardContext
 .java:3447)
 at
 
org.apache.catalina.core.StandardContext.start(StandardContext.
java:3098)
 at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1059)
 at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1059)
 at
 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:253)
 at
 
org.apache.catalina.core.StandardService.start(StandardService.
java:353)
 at
 
org.apache.catalina.core.StandardServer.start(StandardServer.java:454)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:707)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:627)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177)


 Here is my TC4 jars layout :

 /var/tomcat4/bin/bootstrap.jar
 /var/tomcat4/common/lib/jndi.jar
 /var/tomcat4/common/lib/naming.jar
 /var/tomcat4/common/lib/servlet.jar
 /var/tomcat4/jasper/jasper-compiler.jar
 /var/tomcat4/jasper/xerces.jar
 /var/tomcat4/lib/jasper-runtime.jar
 /var/tomcat4/lib/namingfactory.jar
 /var/tomcat4/server/lib/catalina.jar
 /var/tomcat4/server/lib/jmxri.jar
 /var/tomcat4/server/lib/regexp.jar
 /var/tomcat4/server/lib/warp.jar
 /var/tomcat4/server/lib/xerces.jar

 I use the original server.xml.

I checked and the Constants class which fails to load is in
namingfactory.jar. ResourceRef is in naming.jar.
So something is wrong with the packaging. Moving 
namingfactory.jar over to
common/lib will probably fix the problem. I can't figure out 
why my setup is
working fine, though ...

I moved and it works now.

I redo the test, with tc 4.02 binary, with :

/var/tomcat4b/bin/bootstrap.jar
/var/tomcat4b/common/lib/jndi.jar
/var/tomcat4b/common/lib/naming.jar
/var/tomcat4b/common/lib/servlet.jar
/var/tomcat4b/jasper/jasper-compiler.jar
/var/tomcat4b/jasper/jaxp.jar
/var/tomcat4b/jasper/crimson.jar
/var/tomcat4b/lib/jasper-runtime.jar
/var/tomcat4b/lib/namingfactory.jar
/var/tomcat4b/server/lib/catalina.jar
/var/tomcat4b/server/lib/jmxri.jar
/var/tomcat4b/server/lib/jakarta-regexp-1.2.jar
/var/tomcat4b/server/lib/warp.jar
/var/tomcat4b/server/lib/crimson.jar
/var/tomcat4b/server/lib/jaxp.jar

It works fine with namingfactory.jar in /var/tomcat4b/lib/.
Since I also use jakarta-regexp-1.2.jar, the only difference
since to be I used xerces-j instead of jaxp/crimson.

I replaced xerces.jar by jaxp.jar/crimson.jar and moved namingfactory.jar
back to /var/tomcat4/server/lib/ :

/var/tomcat4/bin/bootstrap.jar
/var/tomcat4/common/lib/jndi.jar
/var/tomcat4/common/lib/naming.jar
/var/tomcat4/common/lib/servlet.jar
/var/tomcat4/jasper/jasper-compiler.jar
/var/tomcat4/jasper/jaxp.jar
/var/tomcat4/jasper/crimson.jar
/var/tomcat4/lib/jasper-runtime.jar
/var/tomcat4/lib/namingfactory.jar
/var/tomcat4/server/lib/catalina.jar
/var/tomcat4/server/lib/jmxri.jar
/var/tomcat4/server/lib/jakarta-regexp-1.2.jar
/var/tomcat4/server/lib/warp.jar
/var/tomcat4/server/lib/crimson.jar
/var/tomcat4/server/lib/jaxp.jar

I've got the same problem !

The problem since to be with jikes 1.3.
When I used javac from my IBM SDK 1.3 (latest)
or jikes 1.2, everything is fine.

But when compiled with jikes 1.3, there is something
broken 




Re: LoadBalancer worker

2001-04-05 Thread Vikas Bansal

Great. I did the change you suggested and now it goes thru the
loadbalancer worker.
But now I have a question-
It looks like this way all my ajp12 and ajp13 workers would be  load
balanced. So it might happen that the request may go to a ajp12/13
worker having low lb_value but that context might not be served by that
worker!  Because lb_worker will choose the worker with low lb_value.


GOMEZ Henri wrote:

 did you do ?

 JkMount /examples/servlet/* loadbalancer
 JkMount /examples/*.jsp loadbalancer

 -Original Message-
 From: Vikas Bansal [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 05, 2001 9:31 PM
 To: [EMAIL PROTECTED]
 Subject: Re: LoadBalancer worker
 
 
 Yes it is there. Sorry I did not mention it earlier-
 worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer
 
 GOMEZ Henri wrote:
 
  Hello,
  I want to enable the load balancer worker on Apache/Tomcat.
 Even though
  I have configured the workers.properties file as -
  worker.loadbalancer.type=lb
  worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1,
 myajp12_2,
  myajp13_2
 
  Don't forget to add loadbalancer to workers list !
 
  
  The load balancer worker is not invoked, for I do see the debug
  statements for lb worker in mod_jk.log.
  
  Could you tell me, what is it that I am doing. What additional
  configuration do I need to do to enable load balancer.
  
  Any help in this regard is appreaciated.
  -Vikas.
  
 




Re: JNDI realm for Catalina

2001-04-05 Thread John Holman


- Original Message -
From: "Martin Smith" [EMAIL PROTECTED]


 I wonder if it wouldn't be useful to permit a principal or a credential to
be an
 attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
 types of data, I wonder if it may be more efficient to maintain it
"distributed"
 in subjects' entries rather than in a possibly very large and dynamic
attribute
 list.)

 (Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the
 distinction and appropriate practical uses of "principals" versus
"credentials".

My understanding - which may not be accurate! -  is that in the context of a
web application the "principal" is the entity on behalf of which a request
is processed, while "credentials" are data used to authenticate that
principal - i.e. to establish its identity. But here I think you are talking
about something different from either - i.e. an attribute of an (already
authenticated) user that is used to decide whether to authorise access to
some resource.

In principle you might be able do what you want using the current code by
setting roleSearchBase to where the users entries are held and setting
roleSearchFilter to e.g. ((mail={0})(creditBalance  1)). This assumes
that you can define a "creditBalance" attribute type with a syntax that
makes the inequality work as you expect. In practice I'm not sure this is
necessarily the best approach in this particular case - perhaps it would be
better to retrieve the credit balance and make the comparison explicitly in
the application. Remember also that the role, once established, persists for
the lifetime of the session.

In general though it is certainly possible to define roles implicitly in
terms of attributes held in the user entries, and the design does support
this.

 Does this model handle "dynamic" groups, by which I mean a reference to a
 method/algorythm/formula computed at runtime, like "member of
ou=myDepartment",
 or "person entries with creditbalance  1" ?  I understand this can be
 achieved by referring to an attribute that stores a URI that includes an
LDAP
 query string.

I *think* this is pecular to the Netscape/iPlanet directory servers. It
seems that you store an LDAP search query in the form of an LDAP URL as the
value of a "memberURL" attribute in an entry with object class
"groupOfURLs". What's not clear to me is whether the directory server
automatically executes the query when you ask for the value of such an
attribute. (This would be an extension of the LDAP standard). If so, you
could just define roleSearchFilter to be (groupOfURL={1}), thus matching the
user's DN with the list of computed DNs.  But if the directory server just
returns the URL for the client to use, the model as it stands would not
handle it.


 In any case, this authenticator is a very exciting contribution.

Thanks! - but note that there are other offerings and this particular one
may not make it into the Catalina code.

John






Persistent connections in tomcat 3.x

2001-04-05 Thread pradeep sankaranthi

Hi
I wanted to findout if persistent/keepalive connections are supported by
tomcat3.2 /3.3
In my application I am trying to invoke  a servlet from a C application
through plain sockets In my post header I am specifying Connection :
keep-alive parameter, however when I try to reuse the connection and post
again using the same socket, I get an error saying the socket has been
shutdown. So my question is if Tomcat supports connection keep alive and if
there is anyother way to support persistent connections in the above
scenario.

thanks

_
Get your FREE download of MSN Explorer at http://explorer.msn.com




RE: TC3.2.x and security problems

2001-04-05 Thread Marc Saegesser

I figured out the difference that's causing the URL to be decoded twice.  It
seems that as of JDK1.3.0 URLs using the file: scheme are now decoded like
http: scheme URLs.  For example file:c:\temp\%2e%2e\fubar.txt are
interpreted as file:c:\temp\..\fubar.txt.  In JDK1.2.2 this would have
generated a FileNotFoundException.

I think this is a bug, file URLs should not be URL decoded.  We'll see if
Sun agrees, but in the mean time I'll handle this in Tomcat to prevent file
contents from being exposed.

 -Original Message-
 From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 05, 2001 10:05 AM
 To: [EMAIL PROTECTED]
 Subject: RE: TC3.2.x and security problems


 Here's an update.  I've installed JDK1.3.0 and JDK1.3.1-beta and
 tested the
 following URLs.

 All the tests were run on Win2000 using Tomcat 3.2.2b2.  The only
 difference
 between these runs was the value of the JAVA_HOME environment variable.

 The security problems I could duplicate *only* occurred when
 using JDK1.3.x.
 They *never* happened with JDK1.2.2.  I was able to duplicate problems
 (directory listing and file contents) for URLs using sequences of
 /%252e%252e to 'escape' from the web application directory.  None of the
 /%2e%2e attacks worked.

 I would appreciate it if others could try these URLs on other platforms to
 see if their results vary.  I'm going to investigate the JDK1.3 issues on
 Win2000.

 GET /examples/jsp/num/numguess.jsp%00
JDK1.2.2 -- 404
JDK1.3.0 -- 404
JDK1.3.1 -- 404

 GET /%252e%252e/%252e%252e/%00.jsp
JDK1.2.2 -- 404
JDK1.3.0 -- Directory listing
JDK1.3.1 -- Directory listing

 GET /examples/jsp/num/numguess.js%2570
JDK1.2.2 -- 404
JDK1.3.0 -- 404
JDK1.3.1 -- 404

 GET /%2e%2e/%2e%2e/%00.jsp
JDK1.2.2 -- 404
JDK1.3.0 -- 404
JDK1.3.1 -- 404

 GET /%2e%2e/%2e%2e%5cLICENSE/%00.jsp
JDK1.2.2 -- 404
JDK1.3.0 -- 404
JDK1.3.1 -- 404

 GET /%252e%252e/%252e%252e%5cLICENSE/%00.jsp
JDK1.2.2 -- 404
JDK1.3.0 -- File contents
JDK1.3.1 -- File contents





cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java WebdavServlet.java

2001-04-05 Thread remm

remm01/04/05 19:45:48

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java WebdavServlet.java
  Log:
  - Add addiotional check to prevent using DELETE and PUT on URLs
starting with /WEB-INF and /META-INF.
  
  Revision  ChangesPath
  1.35  +16 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- DefaultServlet.java   2001/04/05 18:47:50 1.34
  +++ DefaultServlet.java   2001/04/06 02:45:48 1.35
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.34 2001/04/05 18:47:50 remm Exp $
  - * $Revision: 1.34 $
  - * $Date: 2001/04/05 18:47:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.35 2001/04/06 02:45:48 remm Exp $
  + * $Revision: 1.35 $
  + * $Date: 2001/04/06 02:45:48 $
*
* 
*
  @@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.34 $ $Date: 2001/04/05 18:47:50 $
  + * @version $Revision: 1.35 $ $Date: 2001/04/06 02:45:48 $
*/
   
   public class DefaultServlet
  @@ -575,6 +575,12 @@
   
   String path = getRelativePath(req);
   
  +if ((path.toUpperCase().startsWith("/WEB-INF")) ||
  +(path.toUpperCase().startsWith("/META-INF"))) {
  +resp.sendError(HttpServletResponse.SC_FORBIDDEN);
  +return;
  +}
  +
   // Looking for a Content-Range header
   if (req.getHeader("Content-Range") != null) {
   // No content range header is supported
  @@ -636,6 +642,12 @@
   }
   
   String path = getRelativePath(req);
  +
  +if ((path.toUpperCase().startsWith("/WEB-INF")) ||
  +(path.toUpperCase().startsWith("/META-INF"))) {
  +resp.sendError(HttpServletResponse.SC_FORBIDDEN);
  +return;
  +}
   
   // Retrieve the Catalina context
   // Retrieve the resources
  
  
  
  1.17  +10 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
  
  Index: WebdavServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- WebdavServlet.java2001/04/05 19:03:08 1.16
  +++ WebdavServlet.java2001/04/06 02:45:48 1.17
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
 1.16 2001/04/05 19:03:08 remm Exp $
  - * $Revision: 1.16 $
  - * $Date: 2001/04/05 19:03:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
 1.17 2001/04/06 02:45:48 remm Exp $
  + * $Revision: 1.17 $
  + * $Date: 2001/04/06 02:45:48 $
*
* 
*
  @@ -125,7 +125,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
  - * @version $Revision: 1.16 $ $Date: 2001/04/05 19:03:08 $
  + * @version $Revision: 1.17 $ $Date: 2001/04/06 02:45:48 $
*/
   
   public class WebdavServlet
  @@ -1685,6 +1685,12 @@
   private boolean deleteResource(String path, HttpServletRequest req, 
  HttpServletResponse resp)
   throws ServletException, IOException {
  +
  +if ((path.toUpperCase().startsWith("/WEB-INF")) ||
  +(path.toUpperCase().startsWith("/META-INF"))) {
  +resp.sendError(WebdavStatus.SC_FORBIDDEN);
  +return false;
  +}
   
   String ifHeader = req.getHeader("If");
   if (ifHeader == null)