DO NOT REPLY [Bug 33187] - JAASRealm logs passwords in the clear

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-01-29 05:25 ---
(In reply to comment #1 and comment #4)

Tracing is turned on in the example provided in the documentation, which I (and 
I suspect many others) 
simply copied as a baseline.  That's the point of an example, isn't it?

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/realm-howto.html#JAASRealm
(also 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#JAASRealm )

Example

Here is an example of how your server.xml snippet should look.



If you want tracing to be an unusual configuration, please change the 
documentation.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

CoyteRequest has no implementation for several methods

[cliff lee]

Dear tomcat developers,
 
I am trying to develop my custimized Valve for my tomcat server 5, and I need 
to modify a coming HttpRequest's headers, method, and contentType. The 
HttpRequest interface has such methods as "addHeader(), setContentType(), 
setMethod()"; however, those methods only have blank implementation in 
CoyteRequest, so I couldn't use them to build or modify a coming Http request 
in my Valve. Do you have any way to walk around it?



-
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

DO NOT REPLY [Bug 28709] - javax.servlet.http.HttpServletRequest.isRequestedSessionIdValid() returns true for an invalidated session!

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-01-28 20:47 ---
Fix went into revision 1.22 of
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,
which was tagged with TOMCAT_5_5_6.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [VOTE] Tomcat 5.5.7 Stability

[Jess Holle]

You can and have fixed CLASSPATH in the past.
Use of the JRE's lib/ext or lib/endorsed is different -- and not 
reasonably solvable, though.

--
Jess Holle
Remy Maucherat wrote:
Tim Funk wrote:
I'm going to abstain from voting since I am unable to adequately 
test. But I did find one item which could be a PITA for the folks on 
tomcat-user.

In setclasspath.sh - the CLASSPATH isn't always overridden. If the 
user tries to start tomcat with an existing CLASSPATH  - that is 
appended to the bootstrap classpath. You can only guess that wacky 
errors I saw after startup with my legacy 3+ year old CLASSPATH.

I committed the change to setclasspath.sh to fix this.
While this issue is definitely not a blocker, it might cause a lot of 
frustration for the many users who keep their CLASSPATH enironment 
variable set.

Well, JARs in system extensions is an equally common and very similar 
issue, from what I've seen (where the user has an old servlet.jar in 
the booclasspath, for example). We can't fix that one.

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

Markus Suter/MX/KNI is out of the office.

[markus . suter]

I will be out of the office starting  01/26/2005 and will not return until
02/02/2005.

NO access to e-mails. In urgent cases pls get in touch with Ms. Erika
Montes (assistant) or with the relevant product managers. Best thanks and
regards.


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

Re: [VOTE] Tomcat 5.5.7 Stability

[Remy Maucherat]

Tim Funk wrote:
I'm going to abstain from voting since I am unable to adequately test. 
But I did find one item which could be a PITA for the folks on tomcat-user.

In setclasspath.sh - the CLASSPATH isn't always overridden. If the user 
tries to start tomcat with an existing CLASSPATH  - that is appended to 
the bootstrap classpath. You can only guess that wacky errors I saw 
after startup with my legacy 3+ year old CLASSPATH.

I committed the change to setclasspath.sh to fix this.
While this issue is definitely not a blocker, it might cause a lot of 
frustration for the many users who keep their CLASSPATH enironment 
variable set.
Well, JARs in system extensions is an equally common and very similar 
issue, from what I've seen (where the user has an old servlet.jar in the 
booclasspath, for example). We can't fix that one.

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

Re: IP issues

[Yoav Shapira]

Hi,
I don't think we should re-instate the old file: that's too complicated from an
IP perspective.  Retain Remy's new file with it's easy IP handling, and give
Jason a nice thank you (but not copyright, as was made clear in the
legal-discuss archives) notice in either the file itself or our NOTICE file. 
Hopefully that way no one's ego is hurt beyond the pain already inflicted by
this whole discussion, and we all move on.

Yoav

Quoting Remy Maucherat <[EMAIL PROTECTED]>:

> Mark Thomas wrote:
> > Having raised this in the legal-discuss mailing list, the result was 
> > that there is actually no issue to worry about here. See 
> >
>
http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/[EMAIL
 PROTECTED]
> 
> > 
> > for details.
> > 
> > With this in mind we need to consider what, if anything, to do now. I 
> > see the following options:
> > 
> > TC5
> > - Need to populate o.a.c.util.CharsetMapperDefault.properties
> > Options
> > 1. Do nothing. Wait for patches to be submitted.
> > 2. Re-instate the contents of the properties file based on Jason's 
> > previous class and include appropriate text in the NOTICE file. 
> > Something like:
> > 
> > o.a.c.util.CharsetMapperDefault.properties is based on code originally 
> > written by Jason Hunter [EMAIL PROTECTED] as part of the book "Java 
> > Servlet Programming" (O'Reilly). See  > href="http://www.servlets.com/book";>http://www.servlets.com/book for 
> > more information. Used with permission under the Apache 1.1 license.
> > 
> > 
> > TC4
> > - Don't need to do anything
> > Options
> > 1. Do nothing
> > 2. Port Remy's enhancements to o.a.c.util.CharsetMapper
> > 
> > TC3
> > - Uses o.a.t.util.http.LocalToCharSetMap which has been deleted
> > Options
> > 1. Re-instate the file.
> > 2. Work around it as suggested in Bill's previous e-mail
> > 
> > My own views are:
> > TC 5 - option 2
> > TC 4 - option 2
> > TC 3 - option 1 (less effort for us)
> 
> I think we're going nowhere. If the ASF doesn't make it clear that there 
> are no redistribution IP issues because of licensing pollution, then I 
> don't think my company will feel safe continuing contributing to this 
> project since our customers will no longer feel confident using our 
> product. This is a problem ;) It's as simple as that. So we would have 
> to start maintaining our own branch, which basically means forking. I 
> suppose every vendor does that, of course, but it's still quite 
> disppointing (as then, the temptation exists to "add value" to our own 
> tree) ...
> 
> Tomcat will work perfectly well without this code, so I do not see the 
> point reintroducing it accompanied with ambiguous legal and advertising 
> statements. This "code" (it's a set of name value pairs, so it's not 
> really code actually) was improperly sneaked into the Tomcat codebase, 
> so I think we should get rid of it.
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 




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

Re: [VOTE] Tomcat 5.5.7 Stability

[Tim Funk]

I'm going to abstain from voting since I am unable to adequately test. But I 
did find one item which could be a PITA for the folks on tomcat-user.

In setclasspath.sh - the CLASSPATH isn't always overridden. If the user tries 
to start tomcat with an existing CLASSPATH  - that is appended to the 
bootstrap classpath. You can only guess that wacky errors I saw after startup 
with my legacy 3+ year old CLASSPATH.

I committed the change to setclasspath.sh to fix this.
While this issue is definitely not a blocker, it might cause a lot of 
frustration for the many users who keep their CLASSPATH enironment variable set.

-Tim
Yoav Shapira wrote:
Hi,
Tomcat 5.5.7 was released a week ago, and now it's time for a stability vote ;)
 I have yet to see TCK results, but this has been a crazy month for everyone it
seems...
[ ] Alpha: leave it as-is, numerous bugs, etc.
[ ] Beta: good quality release, at least one issue preventing stable vote
[ ] Stable: solid, no major issues (minor issues possible)
Thanks for voting,
Yoav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 67 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-28012005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-28012005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-28012005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-28012005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-28012005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2328012005, brutus:brutus-public:2328012005
Gump E-mail Identifier (unique within run) #34.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

Re: [VOTE] Tomcat 5.5.7 Stability

[Peter Rossbach]

Yoav Shapira schrieb:
Hi,
Tomcat 5.5.7 was released a week ago, and now it's time for a stability vote ;)
I have yet to see TCK results, but this has been a crazy month for everyone it
seems...
[ ] Alpha: leave it as-is, numerous bugs, etc.
[ ] Beta: good quality release, at least one issue preventing stable vote
[X] Stable: solid, no major issues (minor issues possible)
 

Stable
:-)
Peter
Thanks for voting,
Yoav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 



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