Re: Bug or feature?

2002-12-09 Thread Thomas Paradies
Sorry for answering my own mail but I lost the thread and want to clarify 
some aspects with respect to Matts message. He wrote:
---
This means that ALL roles can access this resource. When you specify *, you
don't need to specify security-role below, but if you DO specify a role or
roles, then it is necessary to define roles. At least, this is my impression
from the specs. If you want your desired behavior, change role-name to use
specialrole.
---
Principally this sounds good and I'm aware of the solution but is this the
specified 
behaviour? Again: what are security-role definitions good for? 

And again I'll refer to the spec - see below.

Thomas Paradies wrote:
 
 Hi,
 
 I'm a little bit confused about the use of the security-role tag - generally
 and especially in Tomcat. The WebApp DTD refers for auth-constraint to this
 element commented as follows:
 
 ... The role-name used here must either correspond to the role-name of one
 of the security-role elements defined for this web application

In TC the role-name in auth-constraint isn't verified against an corresponding 
security-role definition. (test: replace * by tomcat do not define a
security-role)
This is a MUST.

 , or be the
 specially reserved role-name * that is a compact syntax for indicating all
 roles in the web application.

IMO this means that * is limited for indicating all roles in THE WEB
APPLICATION 
and should not not do this for roles in other web applications even if the share 
the same realm.

 ... If no roles are defined, no user is allowed
 access to the portion of the web application described by the containing
 security-constraint...

I understand this as a MUST. And no roles are defined relates in my eyes to 
the web application. 

Comments are welcome.

 
 I've tried to do this with Tomcat (4.1.16) but it didn't work as described.
 Tested with this web.xml (test.jsp also needed):
 
 ?xml version=1.0 encoding=ISO-8859-1?
 !DOCTYPE web-app
 PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
 http://java.sun.com/dtd/web-app_2_3.dtd;
 web-app
   servlet
 servlet-nameRoleRef/servlet-name
 jsp-file/test.jsp/jsp-file
   /servlet
   servlet-mapping
 servlet-name
   RoleRef
 /servlet-name
 url-pattern
   /test
 /url-pattern
   /servlet-mapping
   security-constraint
 web-resource-collection
   web-resource-nameWebCollection/web-resource-name
   url-pattern/test/url-pattern
 /web-resource-collection
 auth-constraint
   role-name*/role-name
 /auth-constraint
   /security-constraint
   login-config
 auth-methodBASIC/auth-method
 realm-namedefault/realm-name
   /login-config
   !-- uncommenting security-role causes nothing --
   security-role
 role-namespecialrole/role-name
   /security-role
 /web-app
 
 Only specialRole should have the permission to access the resource test.jsp,
 if uncommented no user should have this permission - but in Tomcat any role
 (e.g. tomcat, from global context) has in both cases the permission ...
 
 Is this wanted behaviour or is this a bug?
 
 Regards,
 Thomas Paradies
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Regards,
Thomas Paradies

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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Bill Barker
I agree with Costin's interpretation of the Jakarta voting rules (even if I
don't agree with his -0 on this particular vote :).  Since it is a
majority vote, justifying a -1 is optional.

soapbox
I'd like to point out that we have at least 3 non-binding +1 votes on this
already.  It seems that there is a community out there for a Servlet-only
release, and IMHO, we should listen to them.
/soapbox


- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, December 08, 2002 11:32 PM
Subject: Re: [VOTE] minimal JSR 154 only distribution


 Jon Scott Stevens wrote:


  requirement in JSR 154 to provide the Admin Tool, I don't see how your
  argument is valid for what I'm proposing.

 A majority vote doesn't require arguments or validity of arguments.

 I like the idea or I don't like the idea is all that's needed.

 Valid arguments are required for a veto.

 I don't think it would be good for tomcat community if it will pass with 3
 +1 votes, 2 -1 votes and one -0.

 I hope that more tomcat committers will send at least a +0 or -0, and even
 better +1 or -1. There is no need to get into too much debate - just yes
 and no would help.



 Costin



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



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Remy Maucherat
Jeanfrancois Arcand wrote:



Jon Scott Stevens wrote:


Create a separate minimal JSR 154 only distribution of Tomcat 4.x:

   +1  []
   0   []
   -1  [X]

-jon
 


(1) Jasper is very a very small jar file.
(2) The Admin Tool should go with the minimal distribution of Tomcat. We 
decided to include JMX in Tomcat distribution...what's the point having 
JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat 
users, but I'm sure a lot of them like to have the Admin Tool .

If the vote actually passes, I'd like to have only one minimal Tomcat 
distribution, which would mean no admin and no Jasper (with separate 
optional Jasper binaries available). JMX can be used directly (using a 
MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to 
administer the server, without the need to use the admin webapp.

Remy


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



DO NOT REPLY [Bug 15172] New: - put before get fails

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15172.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15172

put before get fails

   Summary: put before get fails
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I make a PUT request on my Servlet as first request to the web app i get a
Bad Request, 400 error. If i do a GET request first and then a PUT my sevlet
works.

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




Re: [VOTE] Tomcat modules

2002-12-09 Thread Henri Gomez
Remy Maucherat wrote:

Hi,

I plan to reorganize the jakarta-tomcat-catalina repository as follows:
- catalina folder: Catalina core; this depends on the servlet API
- modules folders: Optional functionality and modules (one example is 
clustering), but which depends on the Catalina API; this does not 
directly depend on the servlet API

Alternately, using another repository (j-t-modules) is possible, but 
just using a folder looks simpler, as there is an API dependency.

I propose putting independent modules in j-t-connectors (like eventually 
some of the naming features).

ballot
+1 [ ]
-1 [ ]
/ballot

+0

I'm pretty busy these days so I can't help even if this
and the clustering are of very interest for me.

Regards



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Jon Scott Stevens wrote:

on 2002/12/7 9:37 AM, Glenn Nielsen [EMAIL PROTECTED] wrote:



I will consider voting +1 if any of the other tomcat devs who want this
will volunteer to be the release manager for the servlet only distribution.

I would find this handy when using Tomcat as a SOAP server where JSP is
not needed.

Glenn


Well this thread make some noise.


I will volunteer to be the release manager.


How will you synchronise with main branch ?

Will you wait TC 5 release to make the SMALL TC5 distro or
will you follow another cycle of release ?





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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Pier Fumagalli wrote:

On 8/12/02 0:43 Jon Scott Stevens [EMAIL PROTECTED] wrote:



on 2002/12/7 4:25 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:



Jon, I'm very sorry mate, you're 4 months too late :-( I lost my fight about
this very same topic back then...


Maybe to late for your opinion, but honestly, I haven't been that impressed
with Jetty.



In my case it speeds up my stuff around 3/4 times faster. And the footprint
is considerably slower... Depends on the app...


I make benchs between TC 4.1.16 and latest jetty, and TC 4.1 was about 
30% faster on servlet (didn't test JSP).

I saw very little if any speed increase with Jetty and Scarab and I actually
consider Jetty's distribution to be packed with more crud than
Tomcat's...but maybe I'm just biased by Tomcat.



At this point, I don't think that with JSR 154 and JSR 152 being separate,
there is much that anyone here can say negative about distributing JSR 154
only engine. Clearly there is a demand. Clearly it is a good thing to have
options.


What think JCP about a JSR 154 only engine ?



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




jvmRoute as a property

2002-12-09 Thread jean-frederic clere
Hi,

I would to add a feature: Allow jvmRoute to be a system property.

I have several Tomcat's using the same server.xml but I need a different 
sessionId for each Tomcat. The easy solution I have found is to use 
jmvRoute=SYSTEM and read the system property jmvRoute to have the jvmRoute I 
want.
I have enclosed the corresponding patch.

Should I commit it?

Cheers

Jean-frederic
Index: catalina/src/share/org/apache/catalina/core/StandardEngine.java
===
RCS file: 
/home/cvs/mirror/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v
retrieving revision 1.15
diff -u -r1.15 StandardEngine.java
--- catalina/src/share/org/apache/catalina/core/StandardEngine.java 2 May 2002 
22:14:45 -   1.15
+++ catalina/src/share/org/apache/catalina/core/StandardEngine.java 9 Dec 2002 
+08:56:06 -
@@ -171,6 +171,7 @@
  */
 public void setDefaultHost(String host) {
 
+this.log(setDefaultHost= + host);
 String oldDefaultHost = this.defaultHost;
 if (host == null) {
 this.defaultHost = null;
@@ -191,7 +192,16 @@
  */
 public void setJvmRoute(String routeId) {
 this.log(setJvmRoute= + routeId);
-jvmRouteId = routeId;
+jvmRouteId = null;
+if (SYSTEM.equals(routeId))
+   this.log(setJvmRoute is SYSTEM!!!);
+try {
+jvmRouteId = System.getProperty(jvmRoute);
+this.log(setJvmRoute read: + jvmRouteId);
+} catch(Exception ex) {
+}
+if (jvmRouteId == null)
+jvmRouteId = routeId;
 }
 
 


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


Re: jvmRoute as a property

2002-12-09 Thread Remy Maucherat
jean-frederic clere wrote:

Hi,

I would to add a feature: Allow jvmRoute to be a system property.

I have several Tomcat's using the same server.xml but I need a different 
sessionId for each Tomcat. The easy solution I have found is to use 
jmvRoute=SYSTEM and read the system property jmvRoute to have the 
jvmRoute I want.
I have enclosed the corresponding patch.

Should I commit it?

The feature could be helpful, but the implementation is weird (if you 
don't call setJvmRoute, which AFAIK only happens when it is defined in 
server.xml, it will never get set).
Probably the code should be put in the StandardEngine constructor or in 
its start method.

Remy


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



Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
What I would love to see is a tree of downloads where each one gains more
and more features (it is additive). Such as:

 JSR-154 Implementation
/  \
 Jasper  Velocity
  /   \ \
 Admin Tool (JMX) Java Server Feces   Scarab

That way, you only need to download what you need. Bundles are easily
created by simply picking off the branch of the tree that you want. If you
want the Tomcat distribution with web based administration abilities, then
you grab it at the Admin Tool level and so on. We can even build an ant
based system which is able to help us manage the selection of components to
include in the distribution. This would be similar to the way that we
currently have jar repositories and dependencies, but on an application
level. Click here to install Jasper, Struts, etc.

Not only does this provide our users the ability to simply get what they
need (and add it after the fact if they don't have it), it helps us focus on
providing a pluggable system which is separate from the other systems (ie:
clean dependencies).

I personally think that this is a much cleaner way of providing
distributions because it does not require people to learn or deal with
things they do not care about. Options are a good thing. Let's not limit
ourselves.

One last point, we should be able to experiment around here. The negative
votes have been based on biases about what I think about Jasper and my
opinions. They are not based on the idea that experimentation is a good
thing and I think that is just plain wrong and very closed minded. Who are
you to decide what our users may or may not like? In the end, if things
don't work out, then fine at least we learned something and we can move on
to the next thing.

What do we really have to loose here?

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




DO NOT REPLY [Bug 15104] - sendRedirect() does not write the port on the redirect url

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15104.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15104

sendRedirect() does not write the port on the redirect url

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 09:18 ---
But with java code does not redirect using host header

HttpURLConnection.setFollowRedirects(true);

With this sentence in java, my program is not capable or doing the redirect.
Maybe is a java implementation bug in 1.3.1?

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




DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595

Security Constraints not processed according to spec.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 09:24 ---
I have reed the specs 2.4 about this and compared it with the specs for 2.3. 
There are no real differences about this topic. But I found the problem in 
ignoring the Use of URL Paths. 

Therfore I have to reopen this BUG:

The Spec state in SRV 11.1 Use of URL Paths
...
2. The container will recursively try to match the longest path-prefix: This is 
done
by stepping down the path tree a directory at a time, using the ’/’ character as
a path separator. The longest match determines the servlet selected.
...

TOMCAT 4 is NOT doing this to resolve the URL of a security constraint. If 
TOMCAT 4 would do, than the order of the security constraints wouldn't make any 
difference (in my example). But as I said in my comment, TOMCAT is using the 
first match from the descriptor, even if there are more with LONGER path-prefix.

If this would be fixed, then it will work the way one expects it (according to 
the specs).

I was willed to send comments to the jsr expert group. But the problem is not 
the specs.

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




DO NOT REPLY [Bug 15104] - sendRedirect() does not write the port on the redirect url

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15104.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15104

sendRedirect() does not write the port on the redirect url





--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 09:27 ---
Ok fine. I think this is invalid and a user error. Please provide:
- an easy to run test case
- the full Tomcat configuration

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




Re: jvmRoute as a property

2002-12-09 Thread jean-frederic clere
Remy Maucherat wrote:

jean-frederic clere wrote:


Hi,

I would to add a feature: Allow jvmRoute to be a system property.

I have several Tomcat's using the same server.xml but I need a 
different sessionId for each Tomcat. The easy solution I have found is 
to use jmvRoute=SYSTEM and read the system property jmvRoute to 
have the jvmRoute I want.
I have enclosed the corresponding patch.

Should I commit it?


The feature could be helpful, but the implementation is weird (if you 
don't call setJvmRoute, which AFAIK only happens when it is defined in 
server.xml, it will never get set).
Probably the code should be put in the StandardEngine constructor or in 
its start method.

Ok, I will set the jvmRoute using the system property jmvRoute in the 
StandardEngine constructor.


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]




DO NOT REPLY [Bug 15143] - Unable to build mod_jk2 for apache-2.0.43 on solaris8

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15143.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15143

Unable to build mod_jk2 for apache-2.0.43 on solaris8

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Blocker |Minor
   Priority|Other   |High

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




DO NOT REPLY [Bug 15175] New: - Tomcat stops responding on solaris 8

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15175.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15175

Tomcat stops responding on solaris 8

   Summary: Tomcat stops responding on solaris 8
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Sun
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am using solaris 8 as OS, and sometime it stop working giving me the following
output.
,
[INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 80
[INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 443
Starting service APP1
Apache Tomcat/4.0.4
[INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 80
[INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 443
Starting service APP2
Apache Tomcat/4.0.4
log4j:WARN No appenders could be found for logger (org.apache.axis.AxisEngine).
log4j:WARN Please initialize the log4j system properly.
Log4j Initialized
[INFO] Http11Protocol - -SocketException reading request, ignored
PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=80]
shutdown due to exception: java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
no stack trace available
PoolTcpEndpoint: Endpoint
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=443] shutdown due to
exception: java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
no stack trace available


bash-2.03# ulimit -a
core file size (blocks) unlimited
data seg size (kbytes)  unlimited
file size (blocks)  unlimited
open files  256
pipe size (512 bytes)   10
stack size (kbytes) 8192
cpu time (seconds)  unlimited
max user processes  7893
virtual memory (kbytes) unlimited

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




DO NOT REPLY [Bug 15175] - Tomcat stops responding on solaris 8

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15175.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15175

Tomcat stops responding on solaris 8

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 10:46 ---

Have you tried setting the java heap size? E.g.
$ java -Xmx512m

for 512MB of max heap. This is normally the problem when getting 
OutOfMemoryException. 

The shell limits are of little or no interest. Look at shell variables 
CATALINA_OPTS for Catalina and TOMCAT_OPTS for Tomcat 3.

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




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

2002-12-09 Thread remm
remm2002/12/09 03:16:30

  Modified:.build.properties.default
  Log:
  - Update to NSIS Beta 0. Hopefully, no more API changes from now on.
  
  Revision  ChangesPath
  1.54  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- build.properties.default  5 Dec 2002 12:01:32 -   1.53
  +++ build.properties.default  9 Dec 2002 11:16:29 -   1.54
  @@ -182,7 +182,7 @@
   nsis.home=${base.path}/nsis-2.0
   nsis.exe=${nsis.home}/makensis.exe
   nsis.installoptions.dll=${nsis.home}/Plugins/InstallOptions.dll
  -nsis.loc=http://telia.dl.sourceforge.net/sourceforge/nsis/nsis20a7.exe
  +nsis.loc=http://telia.dl.sourceforge.net/sourceforge/nsis/nsis20b0.exe
   
   
   # - Struts, version 1.1 Beta 2 or later -
  
  
  

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




[4.1.17] Tag soon ?

2002-12-09 Thread Remy Maucherat
I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which 
hopefully would be the next stable build) tomorrow after a few more 
minor tweaks.

There was a report made against JK 2 immediately after 4.1.16 Beta was 
announced. Can someone confirm there's no major issue with JK ?

Remy


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



[4.1] Changes to base interfaces

2002-12-09 Thread Remy Maucherat
Hi,

Changing the API in the 4.1.x branch is not ok (at a bare minimum, not 
without asking/voting).
A method addition was made on 11/30 to the org.apache.catalina.Manager 
interface. This could break compatibility with 3rd party managers, and 
apparently was made during an optimization effort, as part of a larger 
patch. I originally missed this in the commit message.

I do not wish to include such an API change as part of the 4.1.x branch, 
and would want to see at least this portion of the patch (with 
dependencies; apparently there are many) reverted.

This batch of experimental patches were committed in a stable branch 
(4.1.x), and as of now are still not ported in the development branch 
(5.0), so I assume development will still continue in 4.1.x, which is 
not a good idea.
What I'd like to see happen, unless there is a good reason not to do so:
- all the changes to the manager are reverted to the 4.1.16 version
- the patches are committed to the jakarta-tomcat-catalina repository, 
where active development can continue without destabilizing the stable tree

Thanks,
Remy


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



DO NOT REPLY [Bug 15176] New: - oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15176.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15176

oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException

   Summary: oracle.xml.sql.OracleXMLSQLException:
java.lang.ClassCastException
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the doc JNDI Datasource HOW-TO, i setup the connection pool 
using DBCP, everything is the same as what the doc shows except for the oracle 
sid and user/pass.
But when i boot up tomcat, something happened.
The page which use sql select is correct while if i use sql update function a 
OracleXMLSQLException occured, Which is caused by class cast i think.
The sql statement including select,insert,update and delete all implemented 
with xdk for oracle.



the logfile shows:
StandardWrapperValve[Login]: Servlet.service() for servlet Login threw exception
oracle.xml.sql.OracleXMLSQLException: java.lang.ClassCastException
at oracle.xml.sql.dml.OracleXMLSave.saveXML(OracleXMLSave.java:2088)
at oracle.xml.sql.dml.OracleXMLSave.updateXML(OracleXMLSave.java:1443)
at XMLBean.execute(XMLBean.java:101)
at ControlBean.setTime(ControlBean.java:491)
at Login._jspService(Login.java:184)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2396)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:469)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1151)
at java.lang.Thread.run(Thread.java:536)

the 101 line of XMLBean.java is  s.updateXML(Doc), s is a instance of 
OracleXMLSave and Doc is a string.

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




adding content-type for Apache 2.0 jk/jk2

2002-12-09 Thread Henri Gomez
Hi,

I'm playing currently with mod_jk + mod_deflate on Apache 2.0,
and it seems it will be needed to set the content-type in response
in Apache 2.0 to allow mod_deflate to compress only text/html, text/xml
contents.

It seems in that case will need to parse the tomcat response
to set content-type accordingly with ap_set_content_type.

What do you think about ?


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




cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

2002-12-09 Thread hgomez
hgomez  2002/12/09 05:19:18

  Modified:jk/native/apache-2.0 mod_jk.c
  Log:
  Make jk works with filters in Apache 2.0, ie mod_deflate and 
  AddOutputFilterByType DEFLATE text/html.
  
  
  Revision  ChangesPath
  1.62  +5 -2  jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.61
  retrieving revision 1.62
  diff -u -r1.61 -r1.62
  --- mod_jk.c  6 Dec 2002 18:54:45 -   1.61
  +++ mod_jk.c  9 Dec 2002 13:19:17 -   1.62
  @@ -240,7 +240,10 @@
   if(!strcasecmp(header_names[h], Content-type)) {
   char *tmp = apr_pstrdup(r-pool, header_values[h]);
   ap_content_type_tolower(tmp);
  -r-content_type = tmp;
  +/* It should be done like this in Apache 2.0 */
  +/* This way, Apache 2.0 will be able to set the output filter */
  +/* and it make jk useable with deflate using AddOutputFilterByType 
DEFLATE text/html */
  +ap_set_content_type(r, tmp);
   } else if(!strcasecmp(header_names[h], Location)) {
   #ifdef AS400 
   /* Fix escapes in Location Header URL*/
  
  
  

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




cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

2002-12-09 Thread remm
remm2002/12/09 05:22:40

  Modified:catalina/src/conf server.xml
  Log:
  - Port connector configuration tweaks.
  
  Revision  ChangesPath
  1.67  +7 -6  jakarta-tomcat-4.0/catalina/src/conf/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- server.xml8 Dec 2002 07:14:16 -   1.66
  +++ server.xml9 Dec 2002 13:22:40 -   1.67
  @@ -92,8 +92,8 @@
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8080 minProcessors=5 maxProcessors=75
  enableLookups=true redirectPort=8443
  -   acceptCount=10 debug=0 connectionTimeout=2
  -   useURIValidationHack=false /
  +   acceptCount=100 debug=0 connectionTimeout=2
  +   useURIValidationHack=false disableUploadTimeout=true /
   !-- Note : To disable connection timeouts, set connectionTimeout value 
to -1 --
   
  @@ -102,8 +102,8 @@
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8443 minProcessors=5 maxProcessors=75
  enableLookups=true
  -acceptCount=10 debug=0 scheme=https secure=true
  -   useURIValidationHack=false
  +acceptCount=100 debug=0 scheme=https secure=true
  +   useURIValidationHack=false disableUploadTimeout=true
 Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory
  clientAuth=false protocol=TLS /
   /Connector
  @@ -130,8 +130,9 @@
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8082 minProcessors=5 maxProcessors=75
  enableLookups=true
  -   acceptCount=10 debug=0 connectionTimeout=2
  -   proxyPort=80 useURIValidationHack=false /
  +   acceptCount=100 debug=0 connectionTimeout=2
  +   proxyPort=80 useURIValidationHack=false
  +   disableUploadTimeout=true /
   --
   
   !-- Define a non-SSL legacy HTTP/1.1 Test Connector on port 8083 --
  
  
  

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




cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c

2002-12-09 Thread hgomez
hgomez  2002/12/09 05:22:45

  Modified:webapp/apache-2.0 mod_webapp.c
  Log:
  Make webapp works with filters in Apache 2.0, ie mod_deflate and 
  AddOutputFilterByType DEFLATE text/html.
  
  NB: My first webapp commit ;-)
  
  
  
  Revision  ChangesPath
  1.12  +7 -2  jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- mod_webapp.c  13 Jun 2002 11:06:47 -  1.11
  +++ mod_webapp.c  9 Dec 2002 13:22:45 -   1.12
  @@ -309,7 +309,12 @@
   
   if (type==NULL) return;
   
  -req-content_type=apr_pstrdup(req-pool,type);
  +/*req-content_type=apr_pstrdup(req-pool,type); */
  +/* It should be done like this in Apache 2.0 */
  +/* This way, Apache 2.0 will be able to set the output filter */
  +/* and it make webapp useable with deflate using AddOutputFilterByType DEFLATE 
text/html */
  +ap_set_content_type(req, apr_pstrdup(req-pool,type));
  +
   apr_table_add(req-headers_out,Content-Type,apr_pstrdup(req-pool,type));
   }
   
  
  
  

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




cvs commit: jakarta-tomcat-4.0/resources/confinstall server_2.xml

2002-12-09 Thread remm
remm2002/12/09 05:22:55

  Modified:resources/confinstall server_2.xml
  Log:
  - Port connector configuration tweaks.
  
  Revision  ChangesPath
  1.6   +6 -6  jakarta-tomcat-4.0/resources/confinstall/server_2.xml
  
  Index: server_2.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/resources/confinstall/server_2.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- server_2.xml  13 Jun 2002 21:42:26 -  1.5
  +++ server_2.xml  9 Dec 2002 13:22:55 -   1.6
  @@ -1,7 +1,7 @@
  minProcessors=5 maxProcessors=75
  enableLookups=true redirectPort=8443
  -   acceptCount=10 debug=0 connectionTimeout=2
  -   useURIValidationHack=false /
  +   acceptCount=100 debug=0 connectionTimeout=2
  +   useURIValidationHack=false disableUploadTimeout=true /
   !-- Note : To disable connection timeouts, set connectionTimeout value 
to -1 --
   
  @@ -10,8 +10,8 @@
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8443 minProcessors=5 maxProcessors=75
  enableLookups=true
  -acceptCount=10 debug=0 scheme=https secure=true
  -   useURIValidationHack=false
  +acceptCount=100 debug=0 scheme=https secure=true
  +   useURIValidationHack=false disableUploadTimeout=true
 Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory
  clientAuth=false protocol=TLS /
   /Connector
  @@ -37,8 +37,8 @@
   !--
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8082 minProcessors=5 maxProcessors=75
  -   enableLookups=true
  -   acceptCount=10 debug=0 connectionTimeout=2
  +   enableLookups=true disableUploadTimeout=true
  +   acceptCount=100 debug=0 connectionTimeout=2
  proxyPort=80 useURIValidationHack=false /
   --
   
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c

2002-12-09 Thread hgomez
hgomez  2002/12/09 05:23:20

  Modified:jk/native2/server/apache2 jk_service_apache2.c
  Log:
  Make jk2 works with filters in Apache 2.0, ie mod_deflate and 
  AddOutputFilterByType DEFLATE text/html.
  
  Revision  ChangesPath
  1.33  +5 -2  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
  
  Index: jk_service_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- jk_service_apache2.c  22 Nov 2002 16:04:06 -  1.32
  +++ jk_service_apache2.c  9 Dec 2002 13:23:19 -   1.33
  @@ -105,7 +105,10 @@
   if( val!=NULL ) {
   char *tmp = apr_pstrdup(r-pool, val);
   ap_content_type_tolower(tmp); 
  -r-content_type = tmp;
  +/* It should be done like this in Apache 2.0 */
  +/* This way, Apache 2.0 will be able to set the output filter */
  +/* and it make jk useable with deflate using AddOutputFilterByType 
DEFLATE text/html */
  +ap_set_content_type(r, tmp);
   }
   val= headers-get( env, headers, Last-Modified);
   if( val!=NULL ) {
  
  
  

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




[GUMP] Build Failure - jakarta-tomcat-catalina

2002-12-09 Thread bobh

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2002-12-09/jakarta-tomcat-catalina.html


Buildfile: build.xml

deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build

deploy-static:

deploy-catalina:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] style task available (required)=true
 [echo] --- JDK ---
 [echo] jdk.1.2.present=true
 [echo] jdk.1.3.present=true
 [echo] jdk.1.4.present=true
 [echo] --- Source Dependencies ---
 [echo] jtc.home.present=true
 [echo] --- Required Libraries ---
 [echo] beanutils.present=true
 [echo] collections.present=true
 [echo] digester.present=true
 [echo] jaxp.present=true
 [echo] jndi.present=true
 [echo] logging.present=true
 [echo] regexp.present=true
 [echo] --- Optional Libraries ---
 [echo] dbcp.present=true
 [echo] jaas.present=true
 [echo] javamail.present=true
 [echo] jmx.present=true
 [echo] jsse.present=true
 [echo] jta.present=true
 [echo] junit.present=true
 [echo] lang.present=${lang.present}
 [echo] launcher.present=${launcher.present}
 [echo] launcher.bootstrap.present=${launcher.bootstrap.present}
 [echo] ldap.present=true
 [echo] modeler.present=true
 [echo] pool.present=true
 [echo] tyrex.present=${tyrex.present}
 [echo] --- Required JARs ---
 [echo] jndi.jar.present(except JDK 1.3+)=true
 [echo] regexp.jar.present=true
 [echo] servlet-api.jar.present=true
 [echo] xerces2.jars.present(except JDK 1.4+)=true
 [echo] --- Optional JARs ---
 [echo] dbcp.jar.present=true
 [echo] jaas.jar.present=true
 [echo] javamail.jar.present=true
 [echo] jdbc20ext.jar.present=true
 [echo] jmx.jar.present=true
 [echo] jta.jar.present=true
 [echo] junit.jar.present=${junit.jar.present}
 [echo] modeler.jar.present=true
 [echo] pool.jar.present=true
 [echo] tyrex.jar.present=${tyrex.jar.present}
 [echo] --- Conditional compilation flags ---
 [echo] compile.dbcp=true
 [echo] compile.jaas=true
 [echo] compile.javamail=true
 [echo] compile.jmx=true
 [echo] compile.jndi=true
 [echo] compile.jsse=true
 [echo] compile.jta=true
 [echo] compile.junit=true
 [echo] compile.ldap=true
 [echo] compile.ssi=true
 [echo] compile.tyrex=${compile.tyrex}
 [echo] --- Distribution flags ---
 [echo] copy.dbcp.jar=true
 [echo] copy.jmx.jar=true
 [echo] copy.launcher.jars=${copy.launcher.jars}
 [echo] copy.logging.jar=true
 [echo] copy.modeler.jar=true
 [echo] copy.pool.jar=true

build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/bin
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/logs
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/work
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/temp

copy-dbcp.jar:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib

copy-jmx.jar:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib

copy-launcher.jars:

copy-modeler.jar:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib

copy-pool.jar:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib

copy-xerces2.jars:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed

build-static:
 [copy] Copying 13 files to 

cvs commit: jakarta-tomcat-connectors/jk/native2 CHANGES.txt

2002-12-09 Thread hgomez
hgomez  2002/12/09 05:27:20

  Modified:jk/native2 CHANGES.txt
  Log:
  comment change
  
  Revision  ChangesPath
  1.7   +5 -2  jakarta-tomcat-connectors/jk/native2/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CHANGES.txt   27 Nov 2002 17:12:40 -  1.6
  +++ CHANGES.txt   9 Dec 2002 13:27:20 -   1.7
  @@ -2,7 +2,10 @@
   Last modified at [$Date$]
   
   Changes with JK2 2.0.3:
  -
  +* jk2 set correctly the content-type in Apache 2.0,
  +  making it ready to works with mod_deflate and AddOutputFilterByType 
  +  [Henri Gomez]
  +  
   Changes with JK2 2.0.2:
   * Fix the bug 14293. Thanks to Martin Kraemer for his help.
 [Jean-Frederic Clere]
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

2002-12-09 Thread hgomez
hgomez  2002/12/09 05:28:55

  Modified:jk/native CHANGES.txt
  Log:
  comment changes
  
  Revision  ChangesPath
  1.5   +10 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- CHANGES.txt   25 Nov 2002 15:29:38 -  1.4
  +++ CHANGES.txt   9 Dec 2002 13:28:55 -   1.5
  @@ -1,6 +1,15 @@
   JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:-*-text-*-
   Last modified at [$Date$]
   
  +Changes with JK 1.2.2:
  +* jk set correctly the content-type in Apache 2.0,
  +  making it ready to works with mod_deflate and AddOutputFilterByType 
  +  [hgomez]
  +* jk will check result of get_endpoint and handle a failure.
  +  This call can fail if the allocation for the endpoint fails because of low 
memory conditions 
  +  causing a dereference of NULL when we try and access the endpoint
  +  [mmanders]
  +  
   Changes with JK 1.2.1:
   * Don't send initial chunk for chunked encoding, fix #14282
 [costin]
  
  
  

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




Re: [4.1] Changes to base interfaces

2002-12-09 Thread jean-frederic clere
Remy Maucherat wrote:

Hi,

Changing the API in the 4.1.x branch is not ok (at a bare minimum, not 
without asking/voting).
A method addition was made on 11/30 to the org.apache.catalina.Manager 
interface. This could break compatibility with 3rd party managers, and 
apparently was made during an optimization effort, as part of a larger 
patch. I originally missed this in the commit message.

I am the gulty for changing the Manager interface. The problem is the 
createSession is called when reading the stored sessions in the store the result 
is quite bad...
I have to look for another way for fixing the problem. (That needs time).


I do not wish to include such an API change as part of the 4.1.x branch, 
and would want to see at least this portion of the patch (with 
dependencies; apparently there are many) reverted.

This batch of experimental patches were committed in a stable branch 
(4.1.x), and as of now are still not ported in the development branch 
(5.0), so I assume development will still continue in 4.1.x, which is 
not a good idea.


What I'd like to see happen, unless there is a good reason not to do so:
- all the changes to the manager are reverted to the 4.1.16 version


That is not a big problem.


- the patches are committed to the jakarta-tomcat-catalina repository, 
where active development can continue without destabilizing the stable tree.

Ok. I will do this part today.



Thanks,
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]




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Glenn Nielsen
Jeanfrancois Arcand wrote:



Jon Scott Stevens wrote:


Create a separate minimal JSR 154 only distribution of Tomcat 4.x:

   +1  []
   0   []
   -1  [X]

-jon
 


(1) Jasper is very a very small jar file.
(2) The Admin Tool should go with the minimal distribution of Tomcat. We 
decided to include JMX in Tomcat distribution...what's the point having 
JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat 
users, but I'm sure a lot of them like to have the Admin Tool .


Not to pick on Jean Francois, but many times I have seen tomcat devs discuss
what the users want or use when discussing features.  I have no real idea what
features tomcat users use or what features they want, other than anecdotal.

Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.?


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




Patch for isapi_redirector2

2002-12-09 Thread Joakim Ström
Hi,

I have made a patch which solves a problem I had last week--isapi_redirector
sometimes corrupted data sent by the client.

I'm not sure where to send the patch, I hope I don't abuse this list by
submitting it here.

Someone more intimate with the code might want to make a better patch, the
code that follows solves the problem but is not very elegant. I have added
code that makes sure the content_length field in jk_ws_service_t gets
updated for each call to jk2_service_iis_read.

I have used version 2.0.2 of JK2.

Joakim Strom
Excosoft
===

int jk2_requtil_readFully(jk_env_t *env, jk_ws_service_t *s,
 unsigned char *buf,
 unsigned  len)
{
unsigned rdlen = 0;
unsigned padded_len = len;
long content_read = s-content_read; // Patch Dec 9, 2002. Save value to restore 
later

if (s-is_chunked  s-no_more_chunks) {
return 0;
}
if (s-is_chunked) {
/* Corner case: buf must be large enough to hold next
 * chunk size (if we're on or near a chunk border).
 * Pad the length to a reasonable value, otherwise the
 * read fails and the remaining chunks are tossed.
 */
padded_len = (len  CHUNK_BUFFER_PAD) ?
len : len - CHUNK_BUFFER_PAD;
}

while(rdlen  padded_len) {
unsigned this_time = 0;
if(s-read(env, s, buf + rdlen, len - rdlen, this_time)) {
return -1;
}
s-content_read += this_time; // Patch Dec 9, 2002.
  // Make sure content_read gets incremented
  // if this loop runs more than once

if(0 == this_time) {
if (s-is_chunked) {
s-no_more_chunks = 1; /* read no more */
}
break;
}
rdlen += this_time;
}
s-content_read = content_read; // Patch Dec 9, 2002. Reset the value before 
returning

return (int)rdlen;
}



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




RE: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Martin Algesten
As an end user. I don't use the admin tool, don't know what it is. I do
use both JSP and Servlets.

M

-Original Message-
From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] 
Sent: 09 December 2002 14:06
To: Tomcat Developers List
Subject: Re: [VOTE] minimal JSR 154 only distribution


Jeanfrancois Arcand wrote:
 
 
 Jon Scott Stevens wrote:
 
 Create a separate minimal JSR 154 only distribution of Tomcat 4.x:

+1  []
0   []
-1  [X]

 -jon
  

 
 (1) Jasper is very a very small jar file.
 (2) The Admin Tool should go with the minimal distribution of Tomcat. 
 We
 decided to include JMX in Tomcat distribution...what's the point
having 
 JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat 
 users, but I'm sure a lot of them like to have the Admin Tool .
 

Not to pick on Jean Francois, but many times I have seen tomcat devs
discuss what the users want or use when discussing features.  I have no
real idea what features tomcat users use or what features they want,
other than anecdotal.

Are there any facts behind the statement but I'm sure a lot of them
like to have the Admin Tool.?


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



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Tim Funk
I have interest in the admin tool - but I don't trust it yet and for my 
production work - and I am still stuck on the 4.0.X series.

I think the admin tool is essential for a full distribution - but 
useless in a minimal distribution. The user base wanting the min 
distribution already have the know-how to do what ever they need and the 
admin app would get in the way.

For the new user - the admin tool is very important as a guide for 
simple changes in an simple manner until they get experience with 
manipulating server.xml themselves.

I went through the same experience with weblogic 6. The admin tool was 
nice - but once I knew the XML attributes to place in their config files 
- the admin interface was (mostly) useless. I believe the same will be 
the same for tomcat users. The use of the admin app will be inversely 
proportional to the user's skill level.

Additionaly, if I create Listeners or other custom classes which need 
configured in server.xml - I don't want to use the admin app. I'd rather 
hand write the file myself. I am sure most admins in the same 
predicament would feel the same.

In a nutshell - I think the admin app is helpful to new users. 
Personally - I don't have enough experience with it to judge if it is 
better than just editing server.xml by hand.

-Tim

Glenn Nielsen wrote:
Jeanfrancois Arcand wrote:




Jon Scott Stevens wrote:


Create a separate minimal JSR 154 only distribution of Tomcat 4.x:

   +1  []
   0   []
   -1  [X]

-jon
 


(1) Jasper is very a very small jar file.
(2) The Admin Tool should go with the minimal distribution of Tomcat. 
We decided to include JMX in Tomcat distribution...what's the point 
having JMX and not the Admin Tool? Maybe JSP is not required by all 
Tomcat users, but I'm sure a lot of them like to have the Admin Tool .


Not to pick on Jean Francois, but many times I have seen tomcat devs 
discuss
what the users want or use when discussing features.  I have no real 
idea what
features tomcat users use or what features they want, other than anecdotal.

Are there any facts behind the statement but I'm sure a lot of them 
like to have the Admin Tool.?




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




Re: [4.1.17] Tag soon ?

2002-12-09 Thread Glenn Nielsen
It seeems that we are doing very frequent point releases of Tomcat 4.1.16.
Yet haven't had a stable release since 4.1.12.

Reviewing the release notes I don't see any difference between CVS HEAD and
4.1.16 except for my recent addition of the DataSource Realm. Why tag 4.1.17
when there are so few changes?

Glenn

Remy Maucherat wrote:

I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which 
hopefully would be the next stable build) tomorrow after a few more 
minor tweaks.

There was a report made against JK 2 immediately after 4.1.16 Beta was 
announced. Can someone confirm there's no major issue with JK ?

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]




Re: [4.1] Changes to base interfaces

2002-12-09 Thread Remy Maucherat
jean-frederic clere wrote:

Remy Maucherat wrote:


Hi,

Changing the API in the 4.1.x branch is not ok (at a bare minimum, not 
without asking/voting).
A method addition was made on 11/30 to the org.apache.catalina.Manager 
interface. This could break compatibility with 3rd party managers, and 
apparently was made during an optimization effort, as part of a larger 
patch. I originally missed this in the commit message.


I am the gulty for changing the Manager interface. The problem is the 
createSession is called when reading the stored sessions in the store 
the result is quite bad...
I have to look for another way for fixing the problem. (That needs time).

Ok, no problem. The idea is that I missed the fact that there was also a 
change to the base API, so it's best to do the whole in the development 
branch.

I do not wish to include such an API change as part of the 4.1.x 
branch, and would want to see at least this portion of the patch (with 
dependencies; apparently there are many) reverted.

This batch of experimental patches were committed in a stable branch 
(4.1.x), and as of now are still not ported in the development branch 
(5.0), so I assume development will still continue in 4.1.x, which is 
not a good idea.



What I'd like to see happen, unless there is a good reason not to do so:
- all the changes to the manager are reverted to the 4.1.16 version



That is not a big problem.


- the patches are committed to the jakarta-tomcat-catalina repository, 
where active development can continue without destabilizing the stable 
tree.


Ok. I will do this part today.


Thanks a lot :)

Remy


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




Re: [4.1.17] Tag soon ?

2002-12-09 Thread Remy Maucherat
Glenn Nielsen wrote:

It seeems that we are doing very frequent point releases of Tomcat 4.1.16.
Yet haven't had a stable release since 4.1.12.

Reviewing the release notes I don't see any difference between CVS HEAD and
4.1.16 except for my recent addition of the DataSource Realm. Why tag 
4.1.17
when there are so few changes?

Because:
- I usually update the release notes right before tagging, so the 
changes are actually more significant
- feedback on 4.1.16 has been uneventful, so we should try to get a 
stable release to replace 4.1.12 ASAP, as many bugs have been fixed 
since then

Remy


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



RE: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Ignacio J. Ortega
Jon,

 Create a separate minimal JSR 154 only distribution of Tomcat 4.x:
 

+0, i could be +1 but i'm out of time to offer any help in tomcat as a
whole, and of course for this particular proposal, but i dont see
anything wrong in it, more i do see it as another step, in the GTU Path
( GTU stand for Great Tomcat Unification :).. 


Saludos, 
Ignacio J. Ortega 

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




cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves PersistentValve.java

2002-12-09 Thread jfclere
jfclere 2002/12/09 07:05:55

  Modified:catalina/src/share/org/apache/catalina Manager.java
   catalina/src/share/org/apache/catalina/session
FileStore.java JDBCStore.java
PersistentManagerBase.java
  Removed: catalina/src/share/org/apache/catalina/valves
PersistentValve.java
  Log:
  Rollback the Manager interface changes and associated changes.
  DO NOT except the persistentManagers to work correctly with 4.1.x.
  
  Revision  ChangesPath
  1.8   +4 -11 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Manager.java
  
  Index: Manager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Manager.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Manager.java  30 Nov 2002 12:43:14 -  1.7
  +++ Manager.java  9 Dec 2002 15:05:55 -   1.8
  @@ -184,13 +184,6 @@
   public void addPropertyChangeListener(PropertyChangeListener listener);
   
   /**
  - * Get a session from the recycled ones or create a new empty one.
  - * The PersistentManager manager does not need to create session data
  - * because it reads it from the Store.
  - */ 
  -public Session createEmptySession();
  -
  -/**
* Construct and return a new session object, based on the default
* settings specified by this Manager's properties.  The session
* id will be assigned by this method, and available via the getId()
  
  
  
  1.10  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java
  
  Index: FileStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- FileStore.java30 Nov 2002 12:43:14 -  1.9
  +++ FileStore.java9 Dec 2002 15:05:55 -   1.10
  @@ -333,7 +333,7 @@
   
   try {
   StandardSession session =
  -(StandardSession) manager.createEmptySession();
  +(StandardSession) manager.createSession();
   session.readObjectData(ois);
   session.setManager(manager);
   return (session);
  
  
  
  1.8   +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java
  
  Index: JDBCStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JDBCStore.java30 Nov 2002 12:43:14 -  1.7
  +++ JDBCStore.java9 Dec 2002 15:05:55 -   1.8
  @@ -538,7 +538,7 @@
   
   if(ois != null) {
   try {
  -_session = (StandardSession) manager.createEmptySession();
  +_session = (StandardSession) manager.createSession();
   _session.readObjectData(ois);
   _session.setManager(manager);
   } finally {
  
  
  
  1.12  +4 -13 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
  
  Index: PersistentManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- PersistentManagerBase.java30 Nov 2002 12:43:14 -  1.11
  +++ PersistentManagerBase.java9 Dec 2002 15:05:55 -   1.12
  @@ -660,15 +660,6 @@
   
   }
   
  -/**
  - * Remove this Session from the active Sessions for this Manager,
  - * but not from the Store. (Used by the PersistentValve)
  - *
  - * @param session Session to be removed
  - */
  -public void removeSuper(Session session) {
  -super.remove (session);
  -}
   
   /**
* Save all currently active sessions in the appropriate persistence
  
  
  

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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Ignacio J. Ortega wrote:

Jon,



Create a separate minimal JSR 154 only distribution of Tomcat 4.x:




+0, i could be +1 but i'm out of time to offer any help in tomcat as a
whole, and of course for this particular proposal, but i dont see
anything wrong in it, more i do see it as another step, in the GTU Path
( GTU stand for Great Tomcat Unification :).. 

Nota that adopting modules for Tomcat could be a way to
satisfy everybody needs.

In such case I'm +1 to have a minimal Tomcat which will
load modules to have JSP, JMX, admin supports.

If anything could be set in server.xml, it will help
have an uniq distribution, that everybody will be able
to tune for its own use.




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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Remy Maucherat wrote:


 If the vote actually passes, I'd like to have only one minimal Tomcat
 distribution, which would mean no admin and no Jasper (with separate
 optional Jasper binaries available). JMX can be used directly (using a
 MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to
 administer the server, without the need to use the admin webapp.

Now - this is not nice !

I don't know why my proposal for a minimal tomcat that includes jsr152 and
jsr154 shouldn't be allowed. 

Ok, I'll make a VOTE and try to gather the votes - hopefully I'll
get at least 3 +1 votes ( and you'll at least -0 it :-).

Costin



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




Re: [4.1.17] Tag soon ?

2002-12-09 Thread Glenn Nielsen
Remy Maucherat wrote:

Glenn Nielsen wrote:


It seeems that we are doing very frequent point releases of Tomcat 
4.1.16.
Yet haven't had a stable release since 4.1.12.

Reviewing the release notes I don't see any difference between CVS 
HEAD and
4.1.16 except for my recent addition of the DataSource Realm. Why tag 
4.1.17
when there are so few changes?


Because:
- I usually update the release notes right before tagging, so the 
changes are actually more significant
- feedback on 4.1.16 has been uneventful, so we should try to get a 
stable release to replace 4.1.12 ASAP, as many bugs have been fixed 
since then

Remy


Could you please update the release notes first before proposing a tag?
That way others can better evaluate whether necessary changes have made
it into CVS before you tag a new version.

Thanks,

Glenn


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Remy Maucherat
Costin Manolache wrote:

Remy Maucherat wrote:




If the vote actually passes, I'd like to have only one minimal Tomcat
distribution, which would mean no admin and no Jasper (with separate
optional Jasper binaries available). JMX can be used directly (using a
MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to
administer the server, without the need to use the admin webapp.



Now - this is not nice !

I don't know why my proposal for a minimal tomcat that includes jsr152 and
jsr154 shouldn't be allowed. 

Ok, I'll make a VOTE and try to gather the votes - hopefully I'll
get at least 3 +1 votes ( and you'll at least -0 it :-).

I'd really like to avoid the proliferation of too many distributions. 
The light distribution confused a lot of users who didn't know what they 
needed, from what I've seen (from what I've read on tc-user).

To restate it: if we do a minimal version and it is voted to be Jasper 
less, then I think we shouldn't have a third minimal-but-with-Jasper 
distribution. Rather, I'd have a separate binary holding the Jasper 
JARs. That's just my preference anyway.

BTW, in such vote, it should be Yes or No. If you don't care, then you 
shouldn't vote.

Remy


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



Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Henri Gomez
Costin Manolache wrote:

Since things may get confusing around here, I would like to 
have an official vote on my prior proposal.

This is the list of included features:

Libs:
- JMX
- JAAS
- JNDI
- digester ( and beanutils, collections it needs ). 
- modeler
- ant ( used for startup and automation of some tasks )
- commons-logging
When/if the JNDI-based abstraction of config files is ready we'll not
need digester - but most likely it'll still be required by
modeler, and also by jasper, so I don't think we can remove it.

Tomcat:
- subset of catalina ( non-deprecated interfaces and base impl that is 
required for tomcat to work ).
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
- jasper ( at least jasper runtime - but probably the whole thing ).

Votes:
[ ] +1 I like the idea, I might help
[ ] -1 I don't like the idea, I won't help.

+0,5 :

I like the idea, but have little time to help these days.



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Henri Gomez
Remy Maucherat wrote:

Costin Manolache wrote:


Remy Maucherat wrote:




If the vote actually passes, I'd like to have only one minimal Tomcat
distribution, which would mean no admin and no Jasper (with separate
optional Jasper binaries available). JMX can be used directly (using a
MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to
administer the server, without the need to use the admin webapp.




Now - this is not nice !

I don't know why my proposal for a minimal tomcat that includes jsr152 
and
jsr154 shouldn't be allowed.
Ok, I'll make a VOTE and try to gather the votes - hopefully I'll
get at least 3 +1 votes ( and you'll at least -0 it :-).


I'd really like to avoid the proliferation of too many distributions. 
The light distribution confused a lot of users who didn't know what they 
needed, from what I've seen (from what I've read on tc-user).

To restate it: if we do a minimal version and it is voted to be Jasper 
less, then I think we shouldn't have a third minimal-but-with-Jasper 
distribution. Rather, I'd have a separate binary holding the Jasper 
JARs. That's just my preference anyway.

BTW, in such vote, it should be Yes or No. If you don't care, then you 
shouldn't vote.

What about using a minimal tomcat core with plugged modules to give
access to jsp/jmx ?

Will make both Costin, and Jon happy and let us have only one
distribution with clear indication in server.xml on how to
activate/desactive such module.





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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Jon Scott Stevens wrote:


 One last point, we should be able to experiment around here. The negative
 votes have been based on biases about what I think about Jasper and my
 opinions. 


 They are not based on the idea that experimentation is a good
 thing and I think that is just plain wrong and very closed minded. Who are
 you to decide what our users may or may not like? In the end, if things
 don't work out, then fine at least we learned something and we can move on
 to the next thing.

No Jon - my vote wasn't based on your biasses about jasper, but on the 
biasses of many members of the tomcat community. 

5.0 was supposed to be the release we make togheter, as a united community 
based on consensus. 

There is one jakarta project where experimentation without consensus
was the operating mode - and I certainly don't like the result. You may
remember about the division of the tomcat community on 3.3/4.0 - and
I don't think 69K of code ( jasper runtime ) would justify another 
division. 


 What do we really have to loose here?

Consensus. 

Costin



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Remy Maucherat
Costin Manolache wrote:

Jon Scott Stevens wrote:




One last point, we should be able to experiment around here. The negative
votes have been based on biases about what I think about Jasper and my
opinions. 




They are not based on the idea that experimentation is a good
thing and I think that is just plain wrong and very closed minded. Who are
you to decide what our users may or may not like? In the end, if things
don't work out, then fine at least we learned something and we can move on
to the next thing.



No Jon - my vote wasn't based on your biasses about jasper, but on the 
biasses of many members of the tomcat community. 

5.0 was supposed to be the release we make togheter, as a united community 
based on consensus. 

There is one jakarta project where experimentation without consensus
was the operating mode - and I certainly don't like the result. You may
remember about the division of the tomcat community on 3.3/4.0 - and
I don't think 69K of code ( jasper runtime ) would justify another 
division. 



What do we really have to loose here?



Consensus. 

People cannot agree on everything. Here, we're talking about relatively 
minor topics.
This issue won't end up in a division of the community, but rather in 
one additional binary distribution based on the same codebase. I can 
live with that (well, as long as I'm not the one building them all ;-) ).

If the lack of consensus spreads to more serious topics (like a 4.2.x 
branch), then I would agree it could be worrying.

Remy


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



DO NOT REPLY [Bug 15185] New: - problem with SSL and jdk1.4

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15185.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15185

problem with SSL and jdk1.4

   Summary: problem with SSL and jdk1.4
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Connector:HTTP/1.1 (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi, 
I have reported the following problem to Sun and they have answered this:


Hi Thomas,

This appears to be a problem with Tomcat.  Could you please forward this
bug to the jakarta bug database at http://jakarta.apache.org/site/bugs.html?
They will analyze the problem and alert us if there is a bug in the jdk.

Regards,
Nathanael
- Original Bug Report---

category : java
release : 1.4.1
subcategory : classes_security
type : bug
synopsis : NoSuchMethodError using JSEE provided with jsdk1.4.1 and Tomcat4
description : FULL PRODUCT VERSION :
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :Windows NT Version 4.0


A DESCRIPTION OF THE PROBLEM :
Dear Sirs,

I have tried to use Tomcat 4.6.0 with https and j2sdk1.4.1.
The following problem occurs:

java.lang.NoSuchMethodError:
java.security.interfaces.RSAPrivateCrtKey.getPrivateExponent
()Ljava/math/BigInteger;
at com.sun.net.ssl.internal.ssl.SunJSSE_bl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_be.init(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_aw.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
at
org.apache.catalina.connector.http.SocketInputStream.fill
(SocketInputStream.java:593)
at
org.apache.catalina.connector.http.SocketInputStream.read
(SocketInputStream.java:530)
at
org.apache.catalina.connector.http.SocketInputStream.readReq
uestLine(SocketInputStream.java:199)
at
org.apache.catalina.connector.http.HttpProcessor.parseReques
t(HttpProcessor.java:710)
at
org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:974)
at
org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)

With j2sdk1.3 and the same configuration there are no
problems.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Install js2dk1.4.1
2.Install jakarta-tomcat-4.0.6-LE-jdk14.zip
3.Configure a https connector
4.Generate a key with the keytool as described in the manual
5.Run Tomcat
6.Start a Browser and use this URL https://localhost:8443

EXPECTED VERSUS ACTUAL BEHAVIOR :
You should get the welcome site of Tomcat4, but you get
nothing because the connention hangs. In the catlina_log
you get the entry above

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NoSuchMethodError:
java.security.interfaces.RSAPrivateCrtKey.getPrivateExponent()
Ljava/math/BigInteger;
at com.sun.net.ssl.internal.ssl.SunJSSE_bl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_be.init(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_aw.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
at org.apache.catalina.connector.http.SocketInputStream.fill
(SocketInputStream.java:593)
at org.apache.catalina.connector.http.SocketInputStream.read
(SocketInputStream.java:530)
at org.apache.catalina.connector.http.SocketInputStream.readRequestLine
(SocketInputStream.java:199)
at org.apache.catalina.connector.http.HttpProcessor.parseRequest
(HttpProcessor.java:710)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:974)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)

REPRODUCIBILITY :
This bug can be reproduced always.

-- BEGIN SOURCE --
Please get the source from the jakarta project.
-- END SOURCE --
workaround : 
suggested_val : 
cust_name : Thomas Thomas
cust_email : [EMAIL PROTECTED]
jdcid : tmaesing1
keyword : webbug
company : BGS 

RE: Patch for isapi_redirector2

2002-12-09 Thread Ignacio J. Ortega
Hola Joakim:

 I'm not sure where to send the patch, I hope I don't abuse 
 this list by
 submitting it here.

Thanks !!, please read http://jakarta.apache.org/site/source.html  to
know to do it, and the format needed..

You can send it to this mail list and/or post it in bugzilla to, dont
forget to put a [Patch] prefix in the summary line of the bug and the
Re: of the message.

BTW: I would do it in both ways, to ensure it gets correctly archived
and managed... so nobody could say that your contribution was not seen..
:)


Saludos, 
Ignacio J. Ortega 

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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jeanfrancois Arcand


Jon Scott Stevens wrote:


What I would love to see is a tree of downloads where each one gains more
and more features (it is additive). Such as:

JSR-154 Implementation
   /  \
Jasper  Velocity
 /   \ \
Admin Tool (JMX) Java Server Feces   Scarab

That way, you only need to download what you need. Bundles are easily
created by simply picking off the branch of the tree that you want. If you
want the Tomcat distribution with web based administration abilities, then
you grab it at the Admin Tool level and so on. We can even build an ant
based system which is able to help us manage the selection of components to
include in the distribution. This would be similar to the way that we
currently have jar repositories and dependencies, but on an application
level. Click here to install Jasper, Struts, etc.

Not only does this provide our users the ability to simply get what they
need (and add it after the fact if they don't have it), it helps us focus on
providing a pluggable system which is separate from the other systems (ie:
clean dependencies).

I personally think that this is a much cleaner way of providing
distributions because it does not require people to learn or deal with
things they do not care about. Options are a good thing. Let's not limit
ourselves.


Youy don't need to learn JSP/Admin Tool if you don't use it. The actual 
Tomcat installation doesn't require you to learn the Admin Tool or JSP


One last point, we should be able to experiment around here. The negative
votes have been based on biases about what I think about Jasper and my
opinions. They are not based on the idea that experimentation is a good
thing and I think that is just plain wrong and very closed minded. Who are
you to decide what our users may or may not like? In the end, if things
don't work out, then fine at least we learned something and we can move on
to the next thing.


I'm with this group since August, and did not see any post from you 
since last week. So my vote is certainly not based on your biaises :-). 
And I am not using the Admin Tool at all personnaly


What do we really have to loose here?


Simplicity. But since we don't have any statistic about the user (what 
we want, what he use when he download Tomcat), it is hard to prove he 
doesn't use JSP/Admin Tool/JMX, and hard to prove he doesn't use it. 


-jon


-- Jeanfrancois



 



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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jeanfrancois Arcand


Glenn Nielsen wrote:


Jeanfrancois Arcand wrote:




Jon Scott Stevens wrote:


Create a separate minimal JSR 154 only distribution of Tomcat 4.x:

   +1  []
   0   []
   -1  [X]

-jon
 


(1) Jasper is very a very small jar file.
(2) The Admin Tool should go with the minimal distribution of Tomcat. 
We decided to include JMX in Tomcat distribution...what's the point 
having JMX and not the Admin Tool? Maybe JSP is not required by all 
Tomcat users, but I'm sure a lot of them like to have the Admin Tool .


Not to pick on Jean Francois, but many times I have seen tomcat devs 
discuss
what the users want or use when discussing features.  I have no real 
idea what
features tomcat users use or what features they want, other than 
anecdotal.

Are there any facts behind the statement but I'm sure a lot of them 
like to have the Admin Tool.? 

No, there aren't. Just based on my reading of Tomcat-users(IMBW). But 
can we say that as well with JSP (people don't need it ?). If yes, then 
I will change my vote and help building a minimal distribution without JSP.

-- Jeanfrancois




--
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]




DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888

WebappClassLoader: Lifecycle error : CL stopped

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|MacOS X |All
   Platform|Macintosh   |All



--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 17:23 ---
I also confirm that it occurs with Tomcat 4.0.3 and 4.1.12. I don't use log4j. 
My platform is a PC with Windows NT 4.
It seems to happen only when the webapp is restarted (because of a class or 
property file changed)

I'll try to track what has been done when it happens

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




DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15105.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15105

pushBody()/popBody() error on tomcat 4.1.12

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-12-09 17:42 ---
Lets verify all together the code :D

On the file PageContentImpl.java we have the two methods

public BodyContent pushBody() { 
depth++; 
if (depth = outs.length) { 
BodyContent[] newOuts = new BodyContentImpl[depth + 1]; 
for (int i = 0; i  outs.length; i++) { 
newOuts[i] = outs[i]; 
} 
newOuts[depth] = new BodyContentImpl(out); 
outs = newOuts; 
} 
out = outs[depth]; 
return outs[depth]; 
} 
 
public JspWriter popBody() { 
depth--; 
if (depth = 0) { 
out = outs[depth]; 
} else { 
out = baseOut; 
} 
return out; 
} 

As we can see on the code if we make two calls to pushBody(), then the array
outs will have two body outs A and B. If we make a popBody, then depth will be
decremented, but the B object is not removed from the outs array, then if I make
another pushBody() (this should create a new out object C, this is not done),
the outs array will have again two objects, but the second object will not be a
new one, it will be the previous B object. Then what will be in the second
element will be the new content plus previous content from B object,that is, the
new content will be appended.

Is not this the way it should work ? That is, create a new object when we make a
pushBody() OR clear the old object when we make a popBody().

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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Costin Manolache
Remy Maucherat wrote:
 
 Votes:
 [ ] +1 I like the idea, I might help
 [ ] -1 I don't like the idea, I won't help.
 
 I'll have to vote -1 until the other vote completes, and then, I'll
 either be:
 - +1 if Jon's proposal doesn't pass
 - -1 if Jon proposal is accepted, unless Jasper is removed from the list

I think this is at least unfair.

I started the discussion on minimal tomcat before Jon's vote. I was 
trying to get a consensus and opinions to shape the proposal. Jon
jumped in with the vote. I don't think who proposes the vote first
wins is the best solution, I don't think we are even talking about the
same thing ( Jon wants a JSR154-only, I'm proposing a minimal tomcat ).


I don't see why a vote on Jon's proposal would affect my proposal 
( or any future vote ). 


 As I said, I'd like to limit to 2 maximum the amount of Tomcat binary
 distributions (I think two is too much, actually, but still is
 acceptable).

Then make a proposal that maximum 2 tomcat binary distribution should be 
allowed. But even in this case - I think I am allowed to propose that 
one of the distributions ( the small one ) includes jasper runtime and is 
not called jsr154 only. Even if Jon's vote is passing.

If your -1 vote on minimal tomcat ( that includes jasper ) is based 
on concerns that we'll have too many distributions - I agree it's
a valid reason, and I know you don't need a reason to vote -1. 

I have no problem with a vote on minimal tomcat to not include
jasper compiler ( or even jasper runtime ) - if this gets a majority
of votes than it can happen. The reverse is a bit more difficult - 
i.e. we can't include jasper in a JSR154 only ( as Jon proposed )

Costin



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




Re: [4.1.17] Tag soon ?

2002-12-09 Thread M
Remy Maucherat wrote:
 
 I don't see any major issues with 4.1.16, so I plan to tag 4.1.17 (which
 hopefully would be the next stable build) tomorrow after a few more
 minor tweaks.
 
 There was a report made against JK 2 immediately after 4.1.16 Beta was
 announced. Can someone confirm there's no major issue with JK ?

I made the report and I can confirm that it still isn't working.
I'm using exacly the same configuration as for 4.1.12 and 4.1.14 both of
which work.

There's some fixes we're looking for in the new release so I've been
monitoring the list.

Should I raise a bug instead of emailing the list?

-- 
Regards,
M

Martin Sillence
PR Newswire

DL +44 (0)1865 78 5065
F  +44 (0)1865 78 5100
W  www.prnewswire.eu.com
---
Any views or opinions are solely those of the author and do not
necessarily represent those of PR Newswire Europe. The e-mail
contents are intended only for addressee and may contain
confidential and/or privileged material. If you are not the
intended recipient, please do not read, copy, use or disclose
this communication and notify the sender.

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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Henri Gomez wrote:

 What about using a minimal tomcat core with plugged modules to give
 access to jsp/jmx ?

There is already some support for that ( server/webapps is very similar
with the 3.3 modules - i.e. trusted components ). It'll need few changes
to deal with the loader issues ( i.e. they should be included in the
server loader - quite easy ).

The option I preffer for that is to use JMX. Each pluggin will be
an mbean that is loaded using either an mlet-like or via a deployment
descriptor ( server/webapps is also fine - using webapps as plugin
units ). JMX notifications can be easily used to have the plugin 
loading/unloading very flexible.


Costin   



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




DO NOT REPLY [Bug 15189] New: - Error message provided when jsp:param element is not used properly is misleading

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15189

Error message provided when jsp:param element is not used properly is misleading

   Summary: Error message provided when jsp:param element is not
used properly is misleading
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Example:

test.jsp
--

jsp:param name=param1 value=value1 /

%-- end of JSP --%

When Jasper processes this page the following error message is returned:

  'The action is not a recognizable standard action.'

This is somewhat misleading since jsp:param is a valid standard action, but the
usage context is incorrect.

I would like to request that the parser be enhanced to handle such cases so that
meaningful error messages can be provided.

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




RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster JGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java

2002-12-09 Thread Filip Hanik
Remy wrote:

I'd like to get the save/restore on shutdown features of the std
manager, and can't really see any major problem it would cause.

could be a little tricky. how would you do this without getting the nodes
out of sync.


 then, when a server joins a cluster, there is a possibility that some
 sessions might not get replicated correctly, because a state
transfer has to
 happen. Thanks to Bela Ban pointing this out

 and later in the future, instead of having every node keep a copy of the
 session, just use primary and secondary servers for the cluster data.

So only two servers are active members of the cluster ?

nope, it would be more weblogic style, so all servers are members of the
cluster, but data only gets replicated between two of them.

Is a cluster with let's say 6 members really too expensive network wise
(assuming a dedicated gig ether link between the cluster members) ?

depends on how much data is being transferred. so the answer could be yes
and no, the current implementation is more expensive than the
primary/secondary solution I was talking about.


Anyway, I think by far the most important feature to add is a TCP or
HTTP redirector, possibly written with NBIO. Until then, the clustering
doesn't have much practical interest (usless you're willing to buy
additional expensive hardware; could squid get the job done, BTW ?).

you mean a software load balancer, there are a bunch of them out there
already. I use my homegrown in Java.


I'm ok with proposing you as a committer, provided you accept to respect

I would like to continue the work on this. I think that Bela and myself
would be a big resource to Tomcat clustering.

Filip



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




Tomcat without DOS Window on Win XP, i.e. like an NT Service?

2002-12-09 Thread micael
Anyone know how to start Tomcat without the DOS window on Win XP?

Micael

---

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank you 



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



RE: Tomcat without DOS Window on Win XP, i.e. like an NT Service?

2002-12-09 Thread Tim Moore
 -Original Message-
 From: micael [mailto:[EMAIL PROTECTED]] 
 Sent: Monday, December 09, 2002 1:11 PM
 To: [EMAIL PROTECTED]
 Subject: Tomcat without DOS Window on Win XP, i.e. like an NT Service?
 
 
 Anyone know how to start Tomcat without the DOS window on Win XP?
 
 Micael

So-called NT services should still work on Win XP.  I haven't done it
myself, but some of my coworkers have.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

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




mod_jk/mod_jk2 binaries for FreeBSD and Apache 2.0.43

2002-12-09 Thread Andy Krivtsov
Please, can you send me JK/JK2 binaries for Apache 2.0.43 FreeBSD ?

 thanks,
Andy

---should provide new 
binaries for JK and JK2.

I'll do JK/JK2 for Linux boxes (and FreeBSD)

Who could do the same for Windows, Netware and Solaris ?

BTW, I'm still waiting an account on moof to build a MacOSX
version.
---



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




cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java

2002-12-09 Thread remm
remm2002/12/09 11:07:36

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  - Add missing commit for the cluster features.
  
  Revision  ChangesPath
  1.6   +16 -6 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ManagerBase.java  9 Dec 2002 15:57:43 -   1.5
  +++ ManagerBase.java  9 Dec 2002 19:07:36 -   1.6
  @@ -643,7 +643,7 @@
   if (session != null)
   session.setManager(this);
   else
  -session = new StandardSession(this);
  +session = getNewSession();
   return(session);
   }
   
  @@ -715,6 +715,15 @@
   
   // -- Protected Methods
   
  +
  +/**
  + * Get new session class to be used in the doLoad() method.
  + */
  +protected StandardSession getNewSession() {
  +return new StandardSession(this);
  +}
  +
  +
   protected void getRandomBytes( byte bytes[] ) {
   // Generate a byte array containing a session identifier
   if( devRandomSource!=null  randomIS==null ) {
  @@ -735,7 +744,8 @@
   Random random = getRandom();
   getRandom().nextBytes(bytes);
   }
  -
  +
  +
   /**
* Generate and return a new session identifier.
*/
  
  
  

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




Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/clusterJGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.javaSerializablePrincipal.java SessionMessage.java

2002-12-09 Thread Remy Maucherat
Filip Hanik wrote:

Remy wrote:



I'd like to get the save/restore on shutdown features of the std
manager, and can't really see any major problem it would cause.



could be a little tricky. how would you do this without getting the nodes
out of sync.


After reloading and passivating, the node will pull the list of sessions 
from the monitor. I agree this could end up out of sync, but this is a 
useful feature, otherwise the sessions go with the cluster.

then, when a server joins a cluster, there is a possibility that some
sessions might not get replicated correctly, because a state


transfer has to


happen. Thanks to Bela Ban pointing this out

and later in the future, instead of having every node keep a copy of the
session, just use primary and secondary servers for the cluster data.


So only two servers are active members of the cluster ?



nope, it would be more weblogic style, so all servers are members of the
cluster, but data only gets replicated between two of them.


Ok, why not.


Is a cluster with let's say 6 members really too expensive network wise
(assuming a dedicated gig ether link between the cluster members) ?



depends on how much data is being transferred. so the answer could be yes
and no, the current implementation is more expensive than the
primary/secondary solution I was talking about.


Obviously. It's a lot simpler of course ;-)


Anyway, I think by far the most important feature to add is a TCP or
HTTP redirector, possibly written with NBIO. Until then, the clustering
doesn't have much practical interest (usless you're willing to buy
additional expensive hardware; could squid get the job done, BTW ?).



you mean a software load balancer, there are a bunch of them out there
already. I use my homegrown in Java.


Yes, I mean that. If it is useful and works, maybe you'd want to add it 
in JG or contribute it to Tomcat.

I'm ok with proposing you as a committer, provided you accept to respect



I would like to continue the work on this. I think that Bela and myself
would be a big resource to Tomcat clustering.


Ok, I will nominate you then.

Remy


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Remy Maucherat
Costin Manolache wrote:

Remy Maucherat wrote:


Votes:
[ ] +1 I like the idea, I might help
[ ] -1 I don't like the idea, I won't help.


I'll have to vote -1 until the other vote completes, and then, I'll
either be:
- +1 if Jon's proposal doesn't pass
- -1 if Jon proposal is accepted, unless Jasper is removed from the list



I think this is at least unfair.

I started the discussion on minimal tomcat before Jon's vote. I was 
trying to get a consensus and opinions to shape the proposal. Jon
jumped in with the vote. I don't think who proposes the vote first
wins is the best solution, I don't think we are even talking about the
same thing ( Jon wants a JSR154-only, I'm proposing a minimal tomcat ).


I don't see why a vote on Jon's proposal would affect my proposal 
( or any future vote ). 



As I said, I'd like to limit to 2 maximum the amount of Tomcat binary
distributions (I think two is too much, actually, but still is
acceptable).



Then make a proposal that maximum 2 tomcat binary distribution should be 
allowed. But even in this case - I think I am allowed to propose that 
one of the distributions ( the small one ) includes jasper runtime and is 
not called jsr154 only. Even if Jon's vote is passing.

If your -1 vote on minimal tomcat ( that includes jasper ) is based 
on concerns that we'll have too many distributions - I agree it's
a valid reason, and I know you don't need a reason to vote -1. 

I have no problem with a vote on minimal tomcat to not include
jasper compiler ( or even jasper runtime ) - if this gets a majority
of votes than it can happen. The reverse is a bit more difficult - 
i.e. we can't include jasper in a JSR154 only ( as Jon proposed )

I agree this is unfair for your vote, and should be an independent 
issue. I'm reverting to my previous vote then (it was +1).

Remy


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



Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Jeanfrancois Arcand


Votes:
[X] +1 I like the idea, I might help
[ ] -1 I don't like the idea, I won't help.


Costin
 

-- Jeanfrancois



 



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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 7:16 AM, Costin Manolache [EMAIL PROTECTED] wrote:

 Votes:
 [ ] +1 I like the idea, I might help
 [ ] -1 I don't like the idea, I won't help.

+0 I don't have time to help, but I like the idea.

-jon


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 7:27 AM, Remy Maucherat [EMAIL PROTECTED] wrote:

 I'd really like to avoid the proliferation of too many distributions.

I don't agree with that. There is nothing wrong with giving users choices.

-jon


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 7:32 AM, Henri Gomez [EMAIL PROTECTED] wrote:

 What about using a minimal tomcat core with plugged modules to give
 access to jsp/jmx ?
 
 Will make both Costin, and Jon happy and let us have only one
 distribution with clear indication in server.xml on how to
 activate/desactive such module.

That does not make me happy. You are missing my point. Read the subject line
of this message.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 7:51 AM, Costin Manolache [EMAIL PROTECTED] wrote:

 No Jon - my vote wasn't based on your biasses about jasper, but on the
 biasses of many members of the tomcat community.

So, you speak for these people? I don't think so.

 5.0 was supposed to be the release we make togheter, as a united community
 based on consensus.

My proposal has nothing to do with that.

 There is one jakarta project where experimentation without consensus
 was the operating mode - and I certainly don't like the result. You may
 remember about the division of the tomcat community on 3.3/4.0 - and
 I don't think 69K of code ( jasper runtime ) would justify another
 division. 

I find it really funny that you are now forced to work on 4.x.

 Consensus. 

What consensus? This has nothing to do with which container to use. It has
everything to do with giving people options.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 8:21 AM, Remy Maucherat [EMAIL PROTECTED] wrote:

 People cannot agree on everything. Here, we're talking about relatively
 minor topics.
 This issue won't end up in a division of the community, but rather in
 one additional binary distribution based on the same codebase. I can
 live with that (well, as long as I'm not the one building them all ;-) ).
 
 If the lack of consensus spreads to more serious topics (like a 4.2.x
 branch), then I would agree it could be worrying.
 
 Remy

Finally, Remy is starting to see the light.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 9:14 AM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote:

 I personally think that this is a much cleaner way of providing
 distributions because it does not require people to learn or deal with
 things they do not care about. Options are a good thing. Let's not limit
 ourselves.
 
 Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
 Tomcat installation doesn't require you to learn the Admin Tool or JSP

Read what I wrote again. I said Learn or deal with and I made no specific
point about the JSP/Admin Tool.

 I'm with this group since August, and did not see any post from you
 since last week. So my vote is certainly not based on your biaises :-).

You vote is based on a lack of history and a view of the larger picture.

 Simplicity. But since we don't have any statistic about the user (what
 we want, what he use when he download Tomcat), it is hard to prove he
 doesn't use JSP/Admin Tool/JMX, and hard to prove he doesn't use it.

Exactly my point.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote:

 I don't see why a vote on Jon's proposal would affect my proposal
 ( or any future vote ).

I agree.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote:

 Then make a proposal that maximum 2 tomcat binary distribution should be
 allowed.

I will -1 this vote.

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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




RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster JGCluster.java JGManager.java ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java

2002-12-09 Thread Filip Hanik
After reloading and passivating, the node will pull the list of sessions
from the monitor. I agree this could end up out of sync, but this is a
useful feature, otherwise the sessions go with the cluster.

actually, once I have the primary/secondary implementation, the secondary
server can store the sessions to file.
you just gave me an idea :))

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 11:13 AM
To: Tomcat Developers List
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster
JGCluster.java JGManager.java ReplicatedSession.java
ReplicationStream.java SerializablePrincipal.java SessionMessage.java


Filip Hanik wrote:
 Remy wrote:


I'd like to get the save/restore on shutdown features of the std
manager, and can't really see any major problem it would cause.


 could be a little tricky. how would you do this without getting the nodes
 out of sync.



then, when a server joins a cluster, there is a possibility that some
sessions might not get replicated correctly, because a state

transfer has to

happen. Thanks to Bela Ban pointing this out

and later in the future, instead of having every node keep a copy of the
session, just use primary and secondary servers for the cluster data.

So only two servers are active members of the cluster ?


 nope, it would be more weblogic style, so all servers are members of the
 cluster, but data only gets replicated between two of them.

Ok, why not.

Is a cluster with let's say 6 members really too expensive network wise
(assuming a dedicated gig ether link between the cluster members) ?


 depends on how much data is being transferred. so the answer could be yes
 and no, the current implementation is more expensive than the
 primary/secondary solution I was talking about.

Obviously. It's a lot simpler of course ;-)

Anyway, I think by far the most important feature to add is a TCP or
HTTP redirector, possibly written with NBIO. Until then, the clustering
doesn't have much practical interest (usless you're willing to buy
additional expensive hardware; could squid get the job done, BTW ?).


 you mean a software load balancer, there are a bunch of them out there
 already. I use my homegrown in Java.

Yes, I mean that. If it is useful and works, maybe you'd want to add it
in JG or contribute it to Tomcat.

I'm ok with proposing you as a committer, provided you accept
to respect


 I would like to continue the work on this. I think that Bela and myself
 would be a big resource to Tomcat clustering.

Ok, I will nominate you then.

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]




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Jon Scott Stevens wrote:

 on 2002/12/9 7:51 AM, Costin Manolache [EMAIL PROTECTED] wrote:
 
 No Jon - my vote wasn't based on your biasses about jasper, but on the
 biasses of many members of the tomcat community.
 
 So, you speak for these people? I don't think so.

No, I speak for myself. I like and use jasper - and I think the tomcat
official releases should include both tomcat and jasper. 
Just like you don't speak for the users.

 5.0 was supposed to be the release we make togheter, as a united
 community based on consensus.
 
 My proposal has nothing to do with that.

2 -1 and one -0 vote versus 3 +1 votes doesn't look like a consensus.

If Sun or anyone else wants to release a JSR154-only product - they
can do it and we should make it easy to do so. 
I don't think we should do it ( as tomcat community ).

I heard the argument about user choice and freedom to experiment on 
avalon ( to justify everyone releasing his own container ). I think
their current attempt to have a single product is a move in the right
direction. 


 Consensus.
 
 What consensus? This has nothing to do with which container to use. It has
 everything to do with giving people options.

Is Apache http having n different releases with all the possible 
combinations of modules ( to give users choice ) ? They include all the
modules in the httpd repository ( some disabled by default ).

That also goes against my proposal for minimal tomcat as well - and supports
Remy's argument that we should have one release. 

Costin



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




[PATCH] Update Tomcat-Admin-ja ResourceFile

2002-12-09 Thread MORIGUCHI Hirokazu
Hi, Tomcat Commiters,

This patch updates a Japanese resource file of Tomcat Administration Tool.
 (ApplicationResources_ja.properties)
I translated the messages modified/added between 4.1.7 and 4.1.16.

I made it as such:
$ diff -u \
  jakarta-tomcat-4.1.16-beta-LE-jdk14-original/server/webapps/admin/WEB-INF/cl
asses/org/apache/webapp/admin/ApplicationResources_ja.properties \
  jakarta-tomcat-4.1.16-beta-LE-jdk14-new/server/webapps/admin/WEB-INF/classes
/org/apache/webapp/admin/ApplicationResources_ja.properties \
   tomcat-admin-ja-res4.1.16.patch


I hope you take this patch.

Thanks.

---
MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED]



tomcat-admin-ja-res4.1.16.patch
Description: Binary data


ApplicationResources_ja.properties
Description: Binary data
--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Jon Scott Stevens wrote:

 If Sun or anyone else wants to release a JSR154-only product - they
 can do it and we should make it easy to do so.
 I don't think we should do it ( as tomcat community ).
 
 Why? So far, you haven't even given a real reason.

That may be because every reason you don't like is not real.
So far you qualified as invalid every reason that everyone mentioned.

 You are so funny! How quickly you seem to change your mind. Go back and

I have a feeling almost everyone changed his mind in some issues
in the last 2 years. You seem to be one exception, and I don't know
if this is a good thing :-)

 Is Apache http having n different releases with all the possible
 combinations of modules ( to give users choice ) ? They include all the
 modules in the httpd repository ( some disabled by default ).
 
 They don't distribute PHP.
 
 So, why should we distribute JSP?

PHP is not developed by the httpd community. ( but php.apache.org ).
Jasper is developed by the tomcat community - same mailing list,
same avail list. 

Anyway - as long as Bill is supporting the no-jasper release, 
I won't change my vote to -1 ( but keep it -0). I haven't contributed that 
much to jasper - and it's up to jasper people to decide what they
feel ( by voting +1 or -1 ). 


Costin




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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java

2002-12-09 Thread luehe
luehe   2002/12/09 13:51:57

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  Standard syntax:
  
  - Added uri and local name to custom action attributes.
  - Enforce restriction that if a dynamic attribute has a prefix that
doesn't map to a namespace (taglib), a translation error is caused.
  
  Revision  ChangesPath
  1.42  +26 -8 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- Parser.java   5 Dec 2002 17:56:43 -   1.41
  +++ Parser.java   9 Dec 2002 21:51:56 -   1.42
  @@ -199,11 +199,29 @@
* Note: JSP and XML spec does not allow while spaces around Eq.  It is
* added to be backward compatible with Tomcat, and with other xml parsers.
*/
  -private boolean parseAttribute(AttributesImpl attrs) throws JasperException {
  - String name = parseName();
  - if (name == null)
  +private boolean parseAttribute(AttributesImpl attrs)
  + throws JasperException {
  +
  + // Get the qualified name
  + String qName = parseName();
  + if (qName == null)
return false;
   
  + // Determine prefix and local name components
  + String localName = qName;
  + String uri = ;
  + int index = qName.indexOf(':');
  + if (index != -1) {
  + String prefix = qName.substring(0, index);
  + TagLibraryInfo tagLibInfo = (TagLibraryInfo) taglibs.get(prefix);
  + if (tagLibInfo == null) {
  + err.jspError(reader.mark(),
  +  jsp.error.attribute.invalidPrefix, prefix);
  + }
  + uri = tagLibInfo.getURI();
  + localName = qName.substring(index+1);
  + }
  +
reader.skipSpaces();
if (!reader.matches(=))
err.jspError(reader.mark(), jsp.error.attribute.noequal);
  @@ -218,8 +236,8 @@
watchString = %;
watchString = watchString + quote;

  - String attr = parseAttributeValue(watchString);
  - attrs.addAttribute(, name, name, CDATA, attr);
  + String attrValue = parseAttributeValue(watchString);
  + attrs.addAttribute(uri, localName, qName, CDATA, attrValue);
return true;
   }
   
  
  
  

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




oracle 9i jdbc driver -- class12.zip or class12.jar

2002-12-09 Thread perl is
Hello,

I just installed the Tomcat package, and now try to
find oracle 9i jdbc driver, class12.zip or
class12.jar.  Does any one know the path to download
this file?  I am using PC version Oracle 9i.

Thank you very much.

Ping
12/9/02

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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




DO NOT REPLY [Bug 15201] New: - ClassCastException in JkCoyoteHandler.action() with SSL

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15201.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15201

ClassCastException in JkCoyoteHandler.action() with SSL

   Summary: ClassCastException in JkCoyoteHandler.action() with SSL
   Product: Tomcat 4
   Version: 4.1.16
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is seen using the just-released Debian 4.1.16-1 package. (I haven't been
able to build Tomcat yet.)

I get the following in my catalina.out log:
---
0 [main] INFO common.ChannelSocket  - JK2: ajp13 listening on
localhost/127.0.0.1:8009
300 [main] INFO server.JkMain  - Jk running ID=0 time=20/4751 
config=/usr/share/tomcat4/conf/jk2.properties
---

When I try to connect, over SSL via Apache, I get the following addition:

---
32394 [Thread-4] ERROR server.JkCoyoteHandler  - Error in action code 
java.lang.ClassCastException
at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:382)
at org.apache.coyote.Response.action(Response.java:216)
at
org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:310)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
at java.lang.Thread.run(Thread.java:536)
---

There seem to be no ill effects, though. The request completes anyway.

The configuration hasn't changed from my earlier 4.1.12 installation.

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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_fr.properties

2002-12-09 Thread luehe
luehe   2002/12/09 14:17:32

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_fr.properties
  Log:
  Fixed Bugzilla 15189: Error message provided when jsp:param element is
  not used properly is misleading
  
  Revision  ChangesPath
  1.43  +9 -7  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- Parser.java   9 Dec 2002 21:51:56 -   1.42
  +++ Parser.java   9 Dec 2002 22:17:32 -   1.43
  @@ -1165,7 +1165,7 @@
*| 'plugin'StdActionContent
*| 'element'   StdActionContent
*/
  -private void parseAction(Node parent) throws JasperException {
  +private void parseStandardAction(Node parent) throws JasperException {
Mark start = reader.mark();
   
if (reader.matches(include)) {
  @@ -1196,8 +1196,10 @@
parsePlugin(parent);
} else if (reader.matches(element)) {
parseElement(parent);
  + } else if (reader.matches(param)) {
  + err.jspError(start, jsp.error.param.invalidUse);
} else {
  - err.jspError(start, jsp.error.badaction);
  + err.jspError(start, jsp.error.badStandardAction);
}
   }
   
  @@ -1447,7 +1449,7 @@
   } else if (reader.matches(${)) {
   parseELExpression(parent);
} else if (reader.matches(jsp:)) {
  - parseAction(parent);
  + parseStandardAction(parent);
} else if (!parseCustomTag(parent)) {
parseTemplateText(parent);
}
  @@ -1501,7 +1503,7 @@
} else if (reader.matches(${)) {
parseELExpression(parent);
} else if (reader.matches(jsp:)) {
  - parseAction(parent);
  + parseStandardAction(parent);
} else if (!parseCustomTag(parent)) {
parseTemplateText(parent);
}
  
  
  
  1.65  +4 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.64
  retrieving revision 1.65
  diff -u -r1.64 -r1.65
  --- messages.properties   6 Dec 2002 19:11:53 -   1.64
  +++ messages.properties   9 Dec 2002 22:17:32 -   1.65
  @@ -103,6 +103,7 @@
   jsp.error.attempt_to_clear_flushed_buffer=Error: Attempt to clear a buffer that's 
already been flushed
   jsp.error.overflow=Error: JSP Buffer overflow
   jsp.error.paramexpected=Expected \param\ tag with \name\ and \value\ 
attributes
  +jsp.error.param.invalidUse=The jsp:param action must not be used outside the 
jsp:include, jsp:forward, or jsp:params elements
   jsp.error.closeindividualparam=param tag needs to be closed with \/\
   jsp.error.closeparams=param tag needs to be closed with /params
   jsp.error.plugin.notype=type not declared in jsp:plugin
  @@ -291,7 +292,7 @@
   jsp.error.could.not.add.taglibraries=Could not add tag one or more libraries.
   jsp.error.duplicate.name.jspattribute=The attribute {0} specified in the standard 
or custom action also appears as the value of the name attribute in the enclosed 
jsp:attribute
   jsp.error.not.in.template={0} not allowed in a template text body.
  -jsp.error.badaction=The action is not a recognizable standard action.
  +jsp.error.badStandardAction=The action is not a recognizable standard action.
   jsp.error.tagdirective.badbodycontent=Invalid body-content ({0}) in tag directive
   jsp.error.page.config_pagedir_encoding_conflict=Page-encoding specified in 
jsp-property-group ({0}) is different from that specified in page directive ({1})
   jsp.error.page.prolog_pagedir_encoding_conflict=Page-encoding specified in XML 
prolog ({0}) is different from that specified in page directive ({1})
  @@ -339,3 +340,4 @@
   jsp.error.tagfile.badSuffix=Missing \.tag\ suffix in tag file path {0}
   jsp.error.tagfile.illegalPath=Missing \/WEB-INF/tags\ or \/META-INF/tags\ in 
tag file path {0}
   jsp.error.plugin.wrongRootElement=Name of root element in {0} different from {1}
  +jsp.error.attribute.invalidPrefix=The attribute prefix {0} does not correspond to 
any imported tag library
  
  
  
  1.7   +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties
  
  Index: messages_fr.properties
  ===
  RCS file: 

DO NOT REPLY [Bug 15189] - Error message provided when jsp:param element is not used properly is misleading

2002-12-09 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15189

Error message provided when jsp:param element is not used properly is misleading

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Validator.java

2002-12-09 Thread luehe
luehe   2002/12/09 14:26:10

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
  Log:
  When verifying that a custom action does not have any invalid
  attributes, take the attributes' URI into account.
  
  Revision  ChangesPath
  1.56  +28 -4 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- Validator.java8 Nov 2002 19:55:47 -   1.55
  +++ Validator.java9 Dec 2002 22:26:10 -   1.56
  @@ -361,6 +361,7 @@
private ErrorDispatcher err;
private TagInfo tagInfo;
   private ClassLoader loader;
  + private Hashtable taglibs;
   
// A FunctionMapper, used to validate EL expressions.
   private FunctionMapper functionMapper;
  @@ -442,6 +443,7 @@
 */
ValidateVisitor(Compiler compiler) {
this.pageInfo = compiler.getPageInfo();
  + this.taglibs = pageInfo.getTagLibraries();
this.err = compiler.getErrorDispatcher();
this.tagInfo = compiler.getCompilationContext().getTagInfo();
this.loader = compiler.getCompilationContext().getClassLoader();
  @@ -679,10 +681,32 @@
= new Node.JspAttribute[attrs.getLength()
   + namedAttributeNodes.size()];
Hashtable tagDataAttrs = new Hashtable(attrs.getLength());
  + TagLibraryInfo tagLibInfo =
  + (TagLibraryInfo) taglibs.get(n.getPrefix());
  + String uri = tagLibInfo.getURI();
for (int i=0; iattrs.getLength(); i++) {
boolean found = false;
for (int j=0; tldAttrs != null  jtldAttrs.length; j++) {
  - if (attrs.getQName(i).equals(tldAttrs[j].getName())) {
  + /*
  +  * A custom action and its declared attributes always
  +  * belong to the same namespace, which is identified by
  +  * the prefix name of the custom tag invocation.
  +  * For example, in this invocation:
  +  * my:test a=1 b=2 c=3/, the action
  +  * test and its attributes a, b, and c all belong
  +  * to the namespace identified by the prefix my.
  +  * The above invocation would be equivalent to:
  +  * my:test my:a=1 my:b=2 my:c=3/
  +  * An action attribute may have a prefix different from
  +  * that of the action invocation only if the underlying
  +  * tag handler supports dynamic attributes, in which case
  +  * the attribute with the different prefix is considered a
  +  * dynamic attribute.
  +  */
  + if (attrs.getLocalName(i).equals(tldAttrs[j].getName())
  +  (attrs.getURI(i) == null
  + || attrs.getURI(i).length() == 0
  + || attrs.getURI(i) == uri)) {
if (tldAttrs[j].canBeRequestTime()) {
   Class expectedType = String.class;
   try {
  
  
  

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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Pier Fumagalli
On 9/12/02 3:59 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:

 (2) The Admin Tool should go with the minimal distribution of Tomcat. We
 decided to include JMX in Tomcat distribution...what's the point having
 JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat
 users, but I'm sure a lot of them like to have the Admin Tool .

That is what I'm asking myself... What's the point in all this useless crap?

Pier


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




Re: [PATCH] Update Tomcat-Admin-ja ResourceFile

2002-12-09 Thread MORIGUCHI Hirokazu
Sorry, I made a bit mistake.
This attachment file is correct.

Thanks.

MORIGUCHI Hirokazu [EMAIL PROTECTED] wrote:

 Hi, Tomcat Commiters,
 
 This patch updates a Japanese resource file of Tomcat Administration Tool.
  (ApplicationResources_ja.properties)
 I translated the messages modified/added between 4.1.7 and 4.1.16.
 
 I made it as such:
 $ diff -u \
   jakarta-tomcat-4.1.16-beta-LE-jdk14-original/server/webapps/admin/WEB-INF/cl
 asses/org/apache/webapp/admin/ApplicationResources_ja.properties \
   jakarta-tomcat-4.1.16-beta-LE-jdk14-new/server/webapps/admin/WEB-INF/classes
 /org/apache/webapp/admin/ApplicationResources_ja.properties \
tomcat-admin-ja-res4.1.16.patch
 
 
 I hope you take this patch.
 
 Thanks.
 
 ---
 MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED]


---
MORIGUCHI Hirokazu [EMAIL PROTECTED],[EMAIL PROTECTED]



tomcat-admin-ja-res4.1.16b.patch
Description: Binary data
--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Pier Fumagalli
On 9/12/02 9:16 Jon Scott Stevens [EMAIL PROTECTED] wrote:

 What I would love to see is a tree of downloads where each one gains more
 and more features (it is additive). Such as:
 
JSR-154 Implementation
   /  \
Jasper  Velocity
 /   \ \
 Admin Tool (JMX) Java Server Feces   Scarab

Jon... That spelling of JSF is (C) and TM Pier 2002 :-)

Pier


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Pier Fumagalli
On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:

 Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
 Tomcat installation doesn't require you to learn the Admin Tool or JSP

As I said 6 or so months ago... That thing is a security hole as big as
the Empire State Building... As most of the stuff that make up tomcat...
We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All
together it makes a load of em...

If someone can come up with a Servlet-only distribution, at least I won't
get holes from all the other (totally useless) components...

Pier (a _user_ now)


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Pier Fumagalli
On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote:

 Since things may get confusing around here, I would like to
 have an official vote on my prior proposal.
 
 This is the list of included features:
 
 Libs:
 - JMX
 - JAAS
 - JNDI
 - digester ( and beanutils, collections it needs ).
 - modeler
 - ant ( used for startup and automation of some tasks )
 - commons-logging
 When/if the JNDI-based abstraction of config files is ready we'll not
 need digester - but most likely it'll still be required by
 modeler, and also by jasper, so I don't think we can remove it.
 
 Tomcat:
 - subset of catalina ( non-deprecated interfaces and base impl that is
 required for tomcat to work ).
 - coyote
 - tomcat-util
 - http11/jk2
 - all valves/etc that are required for tomcat to operate.
 - naming
 - jasper ( at least jasper runtime - but probably the whole thing ).
 
 Votes:
 [ ] +1 I like the idea, I might help
 [ ] -1 I don't like the idea, I won't help.

I remember that when I proposed the same thing (roughly) and wanted to call
it Tomcat-HA or something like it, you said:

If possible, please also change the name - unless ASF gives you permission
to use tomcat name in your product.

I _love_ fairness and justice in this world... What-EVER!

Pier


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jeanfrancois Arcand


Pier Fumagalli wrote:


On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:

 

Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
Tomcat installation doesn't require you to learn the Admin Tool or JSP
   


As I said 6 or so months ago... That thing is a security hole as big as


Can you give me an example of a security hole? I would be interested to 
fix those holes

the Empire State Building... As most of the stuff that make up tomcat...
We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All
together it makes a load of em...


Yes, you are right (think about Windoses). Is the reason to have an only 
154 distribution is security? That a very different story...


If someone can come up with a Servlet-only distribution, at least I won't
get holes from all the other (totally useless) components...


True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no 
a good reason IMO.


-- Jeanfrancois


   Pier (a _user_ now)


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


 



cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties

2002-12-09 Thread luehe
luehe   2002/12/09 15:27:04

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
  Log:
  Fixed Bugtraq 4790760: A translation-time error is not generated if
  the 'name' attribute of jsp:param is an expression
  
  Revision  ChangesPath
  1.57  +12 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- Validator.java9 Dec 2002 22:26:10 -   1.56
  +++ Validator.java9 Dec 2002 23:27:03 -   1.57
  @@ -476,6 +476,13 @@
public void visit(Node.ParamAction n) throws JasperException {
   JspUtil.checkAttributes(Param action, n,
   paramActionAttrs, err);
  + // make sure the value of the 'name' attribute is not a
  + // request-time expression
  + if (isExpression(n, n.getAttributes().getValue(name))) {
  + err.jspError(n,
  +  jsp.error.attribute.standard.non_rt_with_expr,
  +  name, jsp:param);
  + }
n.setValue(getJspAttribute(value, null, null,
   n.getAttributeValue(value),
  java.lang.String.class, null,
  @@ -739,7 +746,7 @@
// Make sure its value does not contain any.
if (isExpression(n, attrs.getValue(i))) {
   err.jspError(n,
  - jsp.error.attribute.non_rt_with_expr,
  + jsp.error.attribute.custom.non_rt_with_expr,
 tldAttrs[j].getName());
}
jspAttrs[i]
  @@ -976,7 +983,7 @@
 * Checks to see if the given attribute value represents a runtime or
 * EL expression.
 */
  - private boolean isExpression(Node.CustomTag n, String value) {
  + private boolean isExpression(Node n, String value) {
if ((n.isXmlSyntax()  value.startsWith(%=))
|| (!n.isXmlSyntax()  value.startsWith(%=))
|| (value.indexOf(${) != -1  !pageInfo.isELIgnored()))
  
  
  
  1.66  +3 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- messages.properties   9 Dec 2002 22:17:32 -   1.65
  +++ messages.properties   9 Dec 2002 23:27:03 -   1.66
  @@ -297,7 +297,8 @@
   jsp.error.page.config_pagedir_encoding_conflict=Page-encoding specified in 
jsp-property-group ({0}) is different from that specified in page directive ({1})
   jsp.error.page.prolog_pagedir_encoding_conflict=Page-encoding specified in XML 
prolog ({0}) is different from that specified in page directive ({1})
   jsp.error.page.prolog_config_encoding_conflict=Page-encoding specified in XML 
prolog ({0}) is different from that specified in jsp-property-group ({1})
  -jsp.error.attribute.non_rt_with_expr=According to TLD, attribute {0} does not 
accept any expressions
  +jsp.error.attribute.custom.non_rt_with_expr=According to TLD, attribute {0} does 
not accept any expressions
  +jsp.error.attribute.standard.non_rt_with_expr=The {0} attribute of the {1} standard 
action does not accept any expressions
   jsp.error.scripting.variable.missing_name=Unable to determine scripting variable 
name from attribute {0}
   jasper.error.emptybodycontent.nonempty=According to TLD, tag {0} must be empty, but 
is not
   jsp.error.tagfile.var_name_given_equals_attr_name=In tag file {0}, the name-given 
attribute ({1}) of a variable directive equals the name attribute of an attribute 
directive
  
  
  
  1.25  +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
  
  Index: messages_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- messages_es.properties2 Dec 2002 11:21:00 -   1.24
  +++ 

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Costin Manolache
Pier Fumagalli wrote:

 On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote:
 
 Since things may get confusing around here, I would like to
 have an official vote on my prior proposal.
 
 This is the list of included features:
 
 Libs:
 - JMX
 - JAAS
 - JNDI
 - digester ( and beanutils, collections it needs ).
 - modeler
 - ant ( used for startup and automation of some tasks )
 - commons-logging
 When/if the JNDI-based abstraction of config files is ready we'll not
 need digester - but most likely it'll still be required by
 modeler, and also by jasper, so I don't think we can remove it.
 
 Tomcat:
 - subset of catalina ( non-deprecated interfaces and base impl that is
 required for tomcat to work ).
 - coyote
 - tomcat-util
 - http11/jk2
 - all valves/etc that are required for tomcat to operate.
 - naming
 - jasper ( at least jasper runtime - but probably the whole thing ).
 
 Votes:
 [ ] +1 I like the idea, I might help
 [ ] -1 I don't like the idea, I won't help.
 
 I remember that when I proposed the same thing (roughly) and wanted to
 call it Tomcat-HA or something like it, you said:
 
 If possible, please also change the name - unless ASF gives you
 permission to use tomcat name in your product.

Can you point to the proposal you made on tomcat-dev and the vote
results to your proposal ? 

Are you saying you made such a proposal and it was voted down ? 

Or it was approved and I didn't allowed you to call it whatever
tomcat-dev decided ?

My comment was in the context of a product named Tomcat-high-availability
that wasn't voted by the tomcat-dev. It doesn't matter if it is
a revolution or minimal or whatever it does - it shouldn't be named 
tomcat-anything without ASF or tomcat-dev permission. 

If this proposal doesn't pass I won't do it somewhere else and call it 
tomcat-minimal. 



Costin

 
 I _love_ fairness and justice in this world... What-EVER!
 
 Pier




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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Pier Fumagalli
On 9/12/02 23:06 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:
 Pier Fumagalli wrote:
 
 On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:
 
 Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
 Tomcat installation doesn't require you to learn the Admin Tool or JSP
 
 As I said 6 or so months ago... That thing is a security hole as big as
 
 Can you give me an example of a security hole? I would be interested to
 fix those holes

They come up every now and then... That's why Costin wanted that all-private
for your eyes only noone who is not cross checked with the FBI gets in
security mailing list, right?...

Want a list of the past ones?

http://search.cert.org/query.html?col=certadvcol=incnotescol=vulnotesht=0
qp=qt=tomcatqs=qc=pw=100%25ws=1la=enqm=0st=1nh=25lk=1rf=2rq=0s
i=1

(err, page 1 out of 24)...

 the Empire State Building... As most of the stuff that make up tomcat...
 We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All
 together it makes a load of em...
 
 Yes, you are right (think about Windoses). Is the reason to have an only
 154 distribution is security? That a very different story...

For me it is... For others it might be a different reason... I joined Apache
because of a friend, you because of your employer... SO? Reasons are
different, outcome is the same...

 If someone can come up with a Servlet-only distribution, at least I won't
 get holes from all the other (totally useless) components...
 
 True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no
 a good reason IMO.

Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-)

Rule of the thumb #1... Not even

public class Main
public static void Main(String argv[]) {
System.out.println(This program doesn't have a bug);
}
}

Doesn't have a bug, allright? Because to execute that little statement my
proc actually does some bazillion operations, and god knows how many INC,
ADD, SUB and MUL my proc does to get that out...

So, rule of the thumb #2. No software ever written is _ever_ secure (Just
consider that the Boeing 777 software - which is the most secure OS on
this planet as far as research goes - Has only one bug every 180.000 lines
of code)...

Now, don't tell me that ALL that collection of cruft doesn't have a bug...
It's just that we are lucky and noone found them yet (given enough eyes...
Linus says)...

To sum up: rule of the thumb #3, less code, less bugs (you folks from Sun
preach that all over your Solaris Blueprints stuff, I learnt it when your
employer was paying my salary).

So, please, don¹t come up on a mailing list saying that is secure, just
say that noone has found a bug yet, because that (and only that) is the
truth...

Pier


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Pier Fumagalli
On 9/12/02 23:38 Costin Manolache [EMAIL PROTECTED] wrote:

 Pier Fumagalli wrote:
 
 On 9/12/02 15:16 Costin Manolache [EMAIL PROTECTED] wrote:
 
 Since things may get confusing around here, I would like to
 have an official vote on my prior proposal.
 
 This is the list of included features:
 
 Libs:
 - JMX
 - JAAS
 - JNDI
 - digester ( and beanutils, collections it needs ).
 - modeler
 - ant ( used for startup and automation of some tasks )
 - commons-logging
 When/if the JNDI-based abstraction of config files is ready we'll not
 need digester - but most likely it'll still be required by
 modeler, and also by jasper, so I don't think we can remove it.
 
 Tomcat:
 - subset of catalina ( non-deprecated interfaces and base impl that is
 required for tomcat to work ).
 - coyote
 - tomcat-util
 - http11/jk2
 - all valves/etc that are required for tomcat to operate.
 - naming
 - jasper ( at least jasper runtime - but probably the whole thing ).
 
 Votes:
 [ ] +1 I like the idea, I might help
 [ ] -1 I don't like the idea, I won't help.
 
 I remember that when I proposed the same thing (roughly) and wanted to
 call it Tomcat-HA or something like it, you said:
 
 If possible, please also change the name - unless ASF gives you
 permission to use tomcat name in your product.
 
 Can you point to the proposal you made on tomcat-dev and the vote
 results to your proposal ?
 
 Are you saying you made such a proposal and it was voted down ?
 
 Or it was approved and I didn't allowed you to call it whatever
 tomcat-dev decided ?
 
 My comment was in the context of a product named Tomcat-high-availability
 that wasn't voted by the tomcat-dev. It doesn't matter if it is
 a revolution or minimal or whatever it does - it shouldn't be named
 tomcat-anything without ASF or tomcat-dev permission.
 
 If this proposal doesn't pass I won't do it somewhere else and call it
 tomcat-minimal. 

You're better than me in scavanging through EyeBrowse... :-)

Pier


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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Costin Manolache
Pier Fumagalli wrote:

 I remember that when I proposed the same thing (roughly) and wanted to
 call it Tomcat-HA or something like it, you said:
 
 If possible, please also change the name - unless ASF gives you
 permission to use tomcat name in your product.
 
 Can you point to the proposal you made on tomcat-dev and the vote
 results to your proposal ?
 
 Are you saying you made such a proposal and it was voted down ?
 
 Or it was approved and I didn't allowed you to call it whatever
 tomcat-dev decided ?
 
 My comment was in the context of a product named
 Tomcat-high-availability that wasn't voted by the tomcat-dev. It
 doesn't matter if it is a revolution or minimal or whatever it does - it
 shouldn't be named tomcat-anything without ASF or tomcat-dev
 permission.
 
 If this proposal doesn't pass I won't do it somewhere else and call it
 tomcat-minimal.
 
 You're better than me in scavanging through EyeBrowse... :-)

It's hard to find something that doesn't exist. 

I hate the practice of using old postings as arguments in most cases - 
it's normal for people to change their minds. 

But in this case you keep making false statements, and not only here. It 
should be quite easy to look for a [VOTE] or [PROPOSAL] that you made 
and was voted on tomcat-dev. 


Costin



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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Jon Scott Stevens
on 2002/12/9 3:58 PM, Costin Manolache [EMAIL PROTECTED] wrote:

 It's hard to find something that doesn't exist.

?

 I hate the practice of using old postings as arguments in most cases -
 it's normal for people to change their minds.

There is a difference between changing your mind and making up the rules as
you go along.

 But in this case you keep making false statements, and not only here. It
 should be quite easy to look for a [VOTE] or [PROPOSAL] that you made
 and was voted on tomcat-dev.

Then find it.

-jon


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Pier Fumagalli
On 9/12/02 23:51 Pier Fumagalli [EMAIL PROTECTED] wrote:

 Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-)

Correction to self... Not 24 pages... 24 notes... (Ok, I have an eyesight
test tomorrow morning at 10:20 in SOHO... I know, I know...)

Pier


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Costin Manolache
Pier Fumagalli wrote:

 They come up every now and then... That's why Costin wanted that
 all-private for your eyes only noone who is not cross checked with the FBI
 gets in security mailing list, right?...

Wrong. The list is for all tomcat committers - and all security information
will be posted after the fix is done. 

The list is created - and will hopefully be used next time a security 
problem is found.

 Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha!
 :-)

Again ?

There are 24 results - not 24 pages of results. And if you go down the page 
- many are not in tomcat.

Try the same thing for apache.


Yes - any code may have vulnerabilities, and the more code you have, the
more bugs you'll have. We can only do our best so that our code has 
fewer bugs - but that shouldn't stop us from distributing the code we 
write ( i.e. tomcat and jasper ). 


Costin



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




Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

2002-12-09 Thread Pier Fumagalli
On 10/12/02 0:10 Jon Scott Stevens [EMAIL PROTECTED] wrote:

 But in this case you keep making false statements, and not only here. It
 should be quite easy to look for a [VOTE] or [PROPOSAL] that you made
 and was voted on tomcat-dev.
 
 Then find it.

I believe it never even went to [VOTE]... Got shut down before.. I usually
have the bad habit of asking others before proposing votes... And, well,
sometimes I don't really use that [VOTE] or [PROPOSAL] thing... I just hope
that open minded people will read and give opinions on a free-form text
subject base... 

Pier


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




Re: [VOTE] minimal JSR 154 only distribution

2002-12-09 Thread Jeanfrancois Arcand


Pier Fumagalli wrote:


On 9/12/02 23:06 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:
 

Pier Fumagalli wrote:

   

On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote:

 

Youy don't need to learn JSP/Admin Tool if you don't use it. The actual
Tomcat installation doesn't require you to learn the Admin Tool or JSP
   

As I said 6 or so months ago... That thing is a security hole as big as

 

Can you give me an example of a security hole? I would be interested to
fix those holes
   


They come up every now and then... That's why Costin wanted that all-private
for your eyes only noone who is not cross checked with the FBI gets in
security mailing list, right?...


Not sure is the real reason. We were doing a Security Audit during that 
time and as a community, we where trying to find a better list to 
declare possible security issues and fix them before the public is informed.


Want a list of the past ones?

http://search.cert.org/query.html?col=certadvcol=incnotescol=vulnotesht=0
qp=qt=tomcatqs=qc=pw=100%25ws=1la=enqm=0st=1nh=25lk=1rf=2rq=0s
i=1

(err, page 1 out of 24)...


;-)



 

the Empire State Building... As most of the stuff that make up tomcat...
We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All
together it makes a load of em...

 

Yes, you are right (think about Windoses). Is the reason to have an only
154 distribution is security? That a very different story...
   


For me it is... For others it might be a different reason... I joined Apache
because of a friend, you because of your employer... SO? Reasons are
different, outcome is the same...


Yep. That why we are trying to reach concensus.



 

If someone can come up with a Servlet-only distribution, at least I won't
get holes from all the other (totally useless) components...

 

True. But if Jasper/AdminTool/etc. are secure, then that doesn't that no
a good reason IMO.
   


Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-)

Rule of the thumb #1... Not even

public class Main
   public static void Main(String argv[]) {
   System.out.println(This program doesn't have a bug);
   }
}

Doesn't have a bug, allright? Because to execute that little statement my
proc actually does some bazillion operations, and god knows how many INC,
ADD, SUB and MUL my proc does to get that out...

So, rule of the thumb #2. No software ever written is _ever_ secure (Just
consider that the Boeing 777 software - which is the most secure OS on
this planet as far as research goes - Has only one bug every 180.000 lines
of code)...


Did I say that every software are secure? Your are right and I will not 
argument at all. But from your previous posting, I was under the 
impression you were aware of security holes


Now, don't tell me that ALL that collection of cruft doesn't have a bug...
It's just that we are lucky and noone found them yet (given enough eyes...
Linus says)...


I never say that and I will never says that. But I least I have try 
during the Security Audit to fix some of the obvious one. Still Tomcat 
is probably not enough secure (and will never be).  My point is if you 
are aware of such obvious one, then let me know and I will fix them. But 
I don't think Tomcat is more secure without JSP I know, I know, what 
I think you don't care :-)


To sum up: rule of the thumb #3, less code, less bugs (you folks from Sun
preach that all over your Solaris Blueprints stuff, I learnt it when your
employer was paying my salary).


Wow, didn't know that... I've missed the chance to work with you :-) I 
should studies my Tomcat history and learn who is doing what, what 
biases he/she have, and then vote appropriatly.

 


So, please, don¹t come up on a mailing list saying that is secure, just
say that noone has found a bug yet, because that (and only that) is the
truth...

I agree my wording was not appropriate. Should say that in french next 
time :-)

-- Jeanfrancois




   Pier


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


 



  1   2   >