RE: Benchmarking gcj-built Tomcat

2003-10-14 Thread Chad Johnson
Gary,
  I can't help with the benchmark software but I've got a question for
you.  Generally speaking, how well does the gcj bytecode interpreter
perform?  Is it purely and interpreter or does it do some jit'ing?

Chad Johnson

-Original Message-
From: Gary Benson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 14, 2003 9:22 AM
To: [EMAIL PROTECTED]
Subject: Benchmarking gcj-built Tomcat


Hi all,

I've been working on building Tomcat and its dependencies to native
code with gcj, and I'm interested to see how it compares against
Tomcat running under a 'normal' JVM.  Now, I'm well aware that
benchmarks are not a real-world indicator of performance, but I don't
have any particular web application to test and I was wondering if
anyone has a benchmarking suite that they can point me at.

In case you are interested in the gcj-built packages, they are
available at http://people.redhat.com/gbenson/naoko/ as source rpms
and as binary rpms compiled for Red Hat Linux 9.  Everything except
the webapps is compiled to native code; the webapps are basically
unmodified and are interpreted just as they would be with a normal JVM.

Thanks,
Gary

[ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

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


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



RE: Benchmarking gcj-built Tomcat

2003-10-14 Thread Chad Johnson
Gary,
  Hmm, interesting.  The benchmarks found at:

http://www.webperformanceinc.com/library/ServletReport/

Should be reproduceable by scripts included in that article.

Chad Johnson

-Original Message-
From: Gary Benson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 14, 2003 10:14 AM
To: Tomcat Developers List
Subject: Re: Benchmarking gcj-built Tomcat


As far as I know, it's just an interpreter, but I may be wrong.
However, any calls to native-code stuff will execute as native code so
it's perhaps not quite as bad as it may seem.

Gary


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



RE: Order of parameters

2003-10-08 Thread Chad Johnson
IMO:
  -Across the board browsers are not obligated to behave like this
  -Any servlet that depended on this behavior would be locked into TC

A solution that could work: 
  Directly get the query string with request.getQueryString() parse
the results yourself and store the results in the order found.

Chad Johnson

-Original Message-
From: Martin van Dijken [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 08, 2003 4:46 AM
To: Tomcat Developers (E-mail)
Subject: Order of parameters


I've been trying to create an automated form handler. This form handler
could be a lot more effective if the request parameters were in the
order they were put on the form. Now most browsers send this information
over HTTP in the order they were found in the form. However, because the
parameters are in Tomcat put into a Hashtable, the order is lost and can
never be rebuilt.

First of all, does anybody have a problem with a little code to keep the
parameters in order?

Second, please comment my proposed solution: 

The best way I can think of to change this involves creating an
extension of Hashtable. At the moment a parameter is put into the
Hashtable, the key is put into an Arraylist. When
request.getParameterNames() is called, the parameters are returned in
the order they are found in the ArrayList. This would keep the speed of
accessing request.getParameter() fast and put a little overhead at
request creation and getParameterNames.


Martin van Dijken

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


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



RE: Order of parameters

2003-10-08 Thread Chad Johnson
Heh, well ofcourse this could also be implemented as a servlet filter! 

Overriding these methods of the request object:
-getParameter
-getParameterMap
-getParameterNames
-getParameterValues 

Chad Johnson

-Original Message-
From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 08, 2003 9:33 AM
To: Tomcat Developers List
Subject: RE: Order of parameters




On Wed, 8 Oct 2003, Chad Johnson wrote:

 A solution that could work:
   Directly get the query string with request.getQueryString() parse
 the results yourself and store the results in the order found.

Come on - you folks are java guys - wrap something around it :-0

Dw

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


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



RE: Http Connector / Gzip

2003-10-06 Thread Chad Johnson
Some regex benchmark's I ran across:

http://tusker.org/regex/regex_benchmark.html

-Chad Johnson

-Original Message-
From: Henri Gomez [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 06, 2003 11:15 AM
To: Tomcat Developers List
Subject: Re: Http Connector / Gzip


Remy Maucherat a écrit :

 Henri Gomez wrote:
 
 Hi to all,

 What about using regexp in HTTP 1.1 connector to include/exclude
 browser which could/couldn't use gzip compression ?

 May be it could be use also to drop to HTTP 1.0 browser which
 claims to be 1.1 compatible, but are not.

 CF: Apache HTTPD server
 
 
 Well, I thought regexp was rather slow in Java, so it could be a problem 
 if using a generic regexp library.

jakarta-regexp is too slow ?


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


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



RE: Http Connector / Gzip

2003-10-06 Thread Chad Johnson
Peter,
  I did a quick search around the net looking for those benchmarks.  Here's what I 
found:

http://www.bagley.org/~doug/shootout/bench/regexmatch/

Looks like the java benchmarks used the ORO library (pre jakarta oro it looks like).

-Chad Johnson

-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 06, 2003 11:29 AM
To: Tomcat Developers List
Subject: RE: Http Connector / Gzip



interesting results. By any chance did you compare it
to Perl regexp to see the difference? :)

peter



--- Chad Johnson [EMAIL PROTECTED] wrote:
 Some regex benchmark's I ran across:
 
 http://tusker.org/regex/regex_benchmark.html
 
 -Chad Johnson
 
 -Original Message-
 From: Henri Gomez [mailto:[EMAIL PROTECTED] 
 Sent: Monday, October 06, 2003 11:15 AM
 To: Tomcat Developers List
 Subject: Re: Http Connector / Gzip
 
 
 Remy Maucherat a écrit :
 
  Henri Gomez wrote:
  
  Hi to all,
 
  What about using regexp in HTTP 1.1 connector to
 include/exclude
  browser which could/couldn't use gzip compression
 ?
 
  May be it could be use also to drop to HTTP 1.0
 browser which
  claims to be 1.1 compatible, but are not.
 
  CF: Apache HTTPD server
  
  
  Well, I thought regexp was rather slow in Java, so
 it could be a problem 
  if using a generic regexp library.
 
 jakarta-regexp is too slow ?
 
 

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

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


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

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


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



RE: [next] What's next ?

2003-10-02 Thread Chad Johnson
Hello all,
  Potential new feature (for Jasper really):

-JSP Line level error reporting for exceptions that occur during jsp
execution

IE. Leverage bcel to do some class munging on the generated class files.

Chad Johnson
WS Packaging Group, Inc.

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 02, 2003 3:32 AM
To: Tomcat Developers List
Subject: [next] What's next ?


Usually, when a Tomcat branch nears its release, a new branch is
created.

However, I only have a few feature ideas that make some sense, and the 
problem is that they are minor evolutions (hence, they could perfectly 
fit inside the 5.0 branch). This includes:

- Updating JK2 to use the JMX events (the same ones the mapper uses) to 
get autoconfiguration, as an option. That seems useful, but it might 
well be a really stupid thing in the real world.

- Java or native load balancer, with session affinity support. This 
could be the perfect commons project, and is not really related to
Tomcat.

- Use an in memory Java compiler to be able to automatically precompile 
webapps upon deployment. I heard such a compiler now exists, and this 
could be added fairly easily if it works well enough. I'm not a very big

fan, but maybe it would make sense for some people.

So to summarize, I have nothing to propose (sorry), and will focus on 
bugfixes and small additions in the 5.0 branch.

If people want to see something more radical happen for the next major 
release, it's probably time to come up with proposals :)

Remy



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


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



RE: [5.0] Schedule change

2003-09-30 Thread Chad Johnson
I might be off base, but whats the problem with releasing TC 5 under the
banner of supporting a draft spec.

Servlet/JSP SpecTomcat version  
2.4/2.0 draft 3 5.0.14  
2.3/1.2 4.1.27  
2.2/1.1 3.3.1a  

Chad Johnson
Web Services Developer
WS Packaging Group, Inc.

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 30, 2003 1:28 PM
To: Tomcat Developers List
Subject: [5.0] Schedule change


Hi,

The signals I'm getting from Sun about the schedule of the 
specifications is highly confusing. Since I'm tired of having Tomcat 
depend on these, I propose taking advantage of the backwards 
compatibility of the spec, and replacing the TC 5 statement phrase with:

The 5.x releases implement the Servlet 2.3 and JSP 1.2 specifications, 
and will add support for the Servlet 2.4 and JSP 2.0 as soon as they are

officially available.

That would allow making a timely 5.0 release, rather than expecting 
stuff for an indefinite amount of time ...

If I don't get yelled at too much, I'll call for a vote on this.

Comments ?

Remy



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


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



RE: Jakarta Tomcat 4.1 XSS vulnerability

2003-09-29 Thread Chad Johnson
Hey,
  Just thought I'd pop in on this one.  Fairly standard XSS attack:

-Insert/execute javascript to pull some key piece of data (ex. value of
the jsessionid cookie)
-This same bit of javascript will then make a http request (through one
several means) to an attackers website which involves that key piece of
data (ex. as a get parameter)

Now I'm not sure if TC uses some additional authentication methods to
prevent this from being an issue (ex. a session can only come from one
ip).  So this may or may not be a valid scenario.

Chad Johnson
Web Services Developer
WS Packaging Group, Inc.


-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: Monday, September 29, 2003 2:34 PM
To: Tomcat Developers List
Subject: RE: Jakarta Tomcat 4.1 XSS vulnerability



Howdy,
This is interesting, hopefully you won't mind educating me a bit
further...

 - Is it really a vulnerability?  What can you get from this
exploit?

You can hijack the user's session or steal information from a user's 
cookie pretty easily with a XSS flaw such as this one.

How would you hijack the user's session?  By that do you mean just
getting the session ID from the JSESSION cookie on the user's
hard-drive?

That's not the problem.  If you look at the trace in my previous post,
the
problem is that the javascript was printed out un-encoded before any of

the response headers.  You can try plugging in the URL in your browser 
(just tack on 666%0a%0ascriptalert(asdf);/script666.jsp a URL)
and
you will receive a Javascript alert asdf.  Malicious users could 
obviously write something much more malicious than a simple alert used
as
the example.

But whatever a malicious user writes would be executed on their own PC,
right?  It won't run on the tomcat server or on anyone else's machines.
So the worst they can do is harm their own PC?  Or did I misunderstand
something?

Yoav Shapira



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an)
intended recipient, please immediately delete this e-mail from your
computer system and notify the sender.  Thank you.


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


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



RE: security of server.xml in tomcat

2003-06-09 Thread Chad Johnson
Just a thought, I can't see how having the username and password in code
is any more secure.  Prying eyes could have equal access to both.

Chad Johnson
Web Services Developer
WS Packaging - Wisconsin Label
Tel:(920)487-6271


-Original Message-
From: Mohamed Tagari [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 09, 2003 9:32 AM
To: [EMAIL PROTECTED]
Subject: security of server.xml in tomcat 


Hi,

Is there any way of instantiating the password and username 
parameters for connecting to a database in the application code rather 
than having it as plain text in the server.xml. 

As having the username and password as plain text is not 
very secure..

Any help/information will be apprectiated..

The database will be containing sensitive information, hence all
passwords 
and usernames have to be protected..

// java code
Context init = new InitialContext();
Context ctx = (Context) init.lookup(java:comp/env); DataSource ds =
(DataSource) ctx.lookup(jdbc/myoracle);



// extract from server.xml
Resource name=jdbc/myoracle auth=Container
  type=javax.sql.DataSource/ 

ResourceParams name=jdbc/myoracle
.
.
.
  parameter
nameusername/name
valuescott/value
  /parameter
  parameter
namepassword/name
valuetiger/value
  /parameter
.
.
/ResourceParams

mo



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


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



RE: Jasper: Error running javac.exe compiler (tc4.1.24)

2003-03-27 Thread Chad Johnson
Thomas,
  Is javac.exe in Tomcat's path?  My guess is that Ant can't find
javac.exe

-Chad Johnson

(you may be better off asking this in tomcat-user)

-Original Message-
From: Thomas Heller [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 27, 2003 10:05 AM
To: [EMAIL PROTECTED]
Subject: Jasper: Error running javac.exe compiler (tc4.1.24)


hi all,

i just installed tomcat 4.1.24 on my dev server and since then i can't
call ANY jsp file. jasper always fails with the following exception
reports.

its pretty long so i extracted the main parts:

[snip]
Error running javac.exe compiler
 at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeEx
tern
alCompile(DefaultCompilerAdapter.java:455)
 at
org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExter
nal.
java:81)
 at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:840)
 at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)

[/snip]

[snip]
--- Nested Exception ---
Caused by: java.io.IOException: CreateProcess: javac.exe -classpath
C:\projects\webapps\stats\WEB-INF\classes;C:\projects\webapps\stats\WEB
-INF
\lib\struts.jar;C:\Tomcat 4.1\shared\classes;C:\Tomcat
4.1\common\classes;C:\Tomcat
4.1\common\endorsed\xercesImpl.jar;C:\Tomcat
4.1\common\endorsed\xmlParserAPIs.jar;C:\Tomcat
4.1\common\lib\activation.jar;C:\Tomcat 4.1\common\lib\ant.jar;C:\Tomcat
4.1\common\lib\catalina-ant.jar;C:\Tomcat
4.1\common\lib\commons-collections.jar;C:\Tomcat
4.1\common\lib\commons-dbcp.jar;C:\Tomcat
4.1\common\lib\commons-logging-api.jar;C:\Tomcat
4.1\common\lib\commons-pool.jar;C:\Tomcat
4.1\common\lib\jasper-compiler.jar;C:\Tomcat
4.1\common\lib\jasper-runtime.jar;C:\Tomcat
4.1\common\lib\jdbc2_0-stdext.jar;C:\Tomcat
4.1\common\lib\jndi.jar;C:\Tomcat 4.1\common\lib\jta.jar;C:\Tomcat
4.1\common\lib\mail.jar;C:\Tomcat
4.1\common\lib\naming-common.jar;C:\Tomcat
4.1\common\lib\naming-factory.jar;C:\Tomcat
4.1\common\lib\naming-resources.jar;C:\Tomcat
4.1\common\lib\pgjdbc2.jar;C:\Tomcat 4.1\common\lib\servlet.jar;C:\Tomc?
 at java.lang.Win32Process.create(Native Method)
 at java.lang.Win32Process.init(Win32Process.java:63)
 at java.lang.Runtime.execInternal(Native Method)
 at java.lang.Runtime.exec(Runtime.java:566)

[/snip]

im on Windows XP pro, jdk1.4.1_02, tomcat 4.1.24. my guess would be the
classpath is too long and gets truncated hence the C:\Tomc?.

[javac] Since fork is true, ignoring compiler setting.

i would try it without fork, but where can i set this?

bye,
thomas


PS: the full report


-


2003-03-27 16:45:17 Error compiling file: C:\Tomcat
4.1\work\Standalone\localhost\stats\/index_jsp.java
[javac] Since fork is true, ignoring compiler setting.
[javac] Compiling 1 source file
[javac] Since fork is true, ignoring compiler setting.


2003-03-27 16:45:17 Info: Compile: javaFileName=C:\Tomcat
4.1\work\Standalone\localhost\stats\/index_jsp.java

classpath=/C:/projects/webapps/stats/WEB-INF/classes/;/C:/projects/webap
ps/s
tats/WEB-INF/lib/struts.jar;/C:/projects/webapps/stats/WEB-INF/classes/;
/C:/
projects/webapps/stats/WEB-INF/lib/struts.jar;C:/Tomcat
4.1/shared/classes/;C:/Tomcat 4.1/common/classes/;C:/Tomcat
4.1/common/endorsed/xercesImpl.jar;C:/Tomcat
4.1/common/endorsed/xmlParserAPIs.jar;C:/Tomcat
4.1/common/lib/activation.jar;C:/Tomcat 4.1/common/lib/ant.jar;C:/Tomcat
4.1/common/lib/catalina-ant.jar;C:/Tomcat
4.1/common/lib/commons-collections.jar;C:/Tomcat
4.1/common/lib/commons-dbcp.jar;C:/Tomcat
4.1/common/lib/commons-logging-api.jar;C:/Tomcat
4.1/common/lib/commons-pool.jar;C:/Tomcat
4.1/common/lib/jasper-compiler.jar;C:/Tomcat
4.1/common/lib/jasper-runtime.jar;C:/Tomcat
4.1/common/lib/jdbc2_0-stdext.jar;C:/Tomcat
4.1/common/lib/jndi.jar;C:/Tomcat 4.1/common/lib/jta.jar;C:/Tomcat
4.1/common/lib/mail.jar;C:/Tomcat
4.1/common/lib/naming-common.jar;C:/Tomcat
4.1/common/lib/naming-factory.jar;C:/Tomcat
4.1/common/lib/naming-resources.jar;C:/Tomcat
4.1/common/lib/pgjdbc2.jar;C:/Tomcat
4.1/common/lib/servlet.jar;C:/Tomcat
4.1/common/lib/tools.jar
 cp=C:\projects\webapps\stats\WEB-INF\classes
 cp=C:\projects\webapps\stats\WEB-INF\lib\struts.jar
 cp=C:\projects\webapps\stats\WEB-INF\classes
 cp=C:\projects\webapps\stats\WEB-INF\lib\struts.jar
 cp=C:\Tomcat 4.1\shared\classes
 cp=C:\Tomcat 4.1\common\classes
 cp=C:\Tomcat 4.1\common\endorsed\xercesImpl.jar
 cp=C:\Tomcat 4.1\common\endorsed\xmlParserAPIs.jar
 cp=C:\Tomcat 4.1\common\lib\activation.jar
 cp=C:\Tomcat 4.1\common\lib\ant.jar
 cp=C:\Tomcat 4.1\common\lib\catalina-ant.jar
 cp=C:\Tomcat 4.1\common\lib\commons-collections.jar
 cp=C:\Tomcat 4.1\common\lib\commons-dbcp.jar
 cp=C:\Tomcat 4.1\common\lib\commons-logging-api.jar
 cp=C:\Tomcat 4.1\common\lib\commons-pool.jar
 cp=C:\Tomcat 4.1\common\lib\jasper-compiler.jar
 cp=C:\Tomcat 4.1\common\lib\jasper-runtime.jar

Small bug with HTMLManagerServlet

2002-09-17 Thread Chad Johnson

Just wondering if anyone has had a chance to look at the patch submitted at:

http://issues.apache.org/bugzilla/show_bug.cgi?id=12053

A small bug, but an annoying one.

-Chad Johnson





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




Re: [4.1.6] Milestone available for testing

2002-07-02 Thread Chad Johnson

Hey,
  I may have missed something obvious, but if I didn't, are there plans to
add context reset/stop/start to the new administration webapp?

-Chad Johnson

- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Cc: Tomcat Users List [EMAIL PROTECTED]
Sent: Friday, June 28, 2002 2:10 PM
Subject: [4.1.6] Milestone available for testing


 Hightlights in this test release include:
 - fix for a memory leak in the request dispatcher
 - many fixes and refactorings in Jasper 2
 - admin webapp improvements
 - other misc fixes

 See the release notes for the list of changes.

 Downloads:
 http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.6/

 Remy


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





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




Maintainer of the ManagerServlet?

2001-10-24 Thread Chad Johnson

Hey,
  Just a quick question, who is in charge of future developement for the
ManagerServlet?

-Chad Johnson