date:20050218

NormW wrote:
 Good evening again.
 No idea why the size difference but have attached tonights trace log 
as indicated.
 The configuration is based on Peter Rosbach's config from a few days 
ago. The 'worker2' __will__ fail because it is non-existant, but logic 
says this is similar to a Tomcat that went offline in service, and the 
balancer (ideally?) should aim everything at worker1, but the trace 
shows even it is having trouble connecting. If this hadn't worked two 
days ago I would definitely not be taking this problem further!


OK. Was not that hard :) .
See the latest commit for ajp_common.c.
You can use worker.worker1.socket_timeout=0 if
not like compling.
Since Netware is returning EINTR on is_connected,
we'll need to check for more return values,
not just EWOULDBLOCK. Will try to fix that next week.
For now don't use socket_timeout  0 on Netware.
Tell me if it works now.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Config Query for Mod_Jk...

2005-02-18 Thread NormW

Greetings again.
Congratulations, Jackpot, Bingo, Bravo, Well Done, etc, etc...
Tomcat is back working again.
Mladen Turk wrote:
NormW wrote:
 
OK. Was not that hard :) .
See the latest commit for ajp_common.c.
You can use worker.worker1.socket_timeout=0 if
not like compling.
Will update to the latest patch in the morning I guess. Easier to adjust 
workers.properties for now.
Since Netware is returning EINTR on is_connected,
we'll need to check for more return values,
not just EWOULDBLOCK. Will try to fix that next week.
For now don't use socket_timeout  0 on Netware.
No problem... set 0 in workers.properties.

Tell me if it works now.
Consider this done!
Regards,
Mladen.
regards,
Norm

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

AW: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-18 Thread Hans Schmid

Hi,

I just want to describe our usecase because we make heavy use of the
local_worker and local_worker_only flags right now.

We use those flags for 'maintenance' mode and failover very successfuly.

But please see our setup and usecase below.

 -Ursprüngliche Nachricht-
 Von: Mladen Turk [mailto:[EMAIL PROTECTED]
 Gesendet: Donnerstag, 17. Februar 2005 20:34
 An: Tomcat Developers List
 Betreff: Re: mod_jk release policy - was: JK 1.2.9-dev test results


 Rainer Jung wrote:
  Hi,
 
  first: thanks a lot to Mladen for adding all the beautiful features [and
  removing CRLF :) ]. Big leap forward!
 

 Still, I cope with those on a daily basis.

  I think that until Monday we were still in the progress of adding
  features, and fixing bugs. 1.2.8 changed a lot internally, but most was
  functionally compatible to 1.2.6. Release 1.2.9 still supported all
  features of 1.2.6.
 

 Something similar I already explained discussing with guys interested
 on Netware platform.

 Something need to be done, and the obvious solution was not to reinvent
 the wheel, but rather use all the code and knowledge about the subject
 already present.

 To be able to use some new features like dynamic config, some things
 has to be changed internally, but nothing was touched in the protocol
 level, only how that protocol is managed.

 So I don't see the point of forking 1.3. Both config and core features
 are the same. Of course some advanced configuration properties where
 changes, lot new added, but from the outside its still old mod_jk.

 Further more adding shared memory and dynamic config I see as a final
 design change for mod_jk.

  Now we are in the discussion of dropping features (and we even did drop
  some like locality support) and I have the impresssion there should be a
  separate discussion thread about the future of mod_jk:
 


 Other thing is 'deprecating' certain thing.
 By that I don't mean deleting them or something like that, but rather
 marking them as 'no more developed'.
 The reason is for that is pure fact. For example we have lotus domino
 connector that works only for domino5. Think that later versions don't
 even have compatible api. I'm not aware anyone in the
 world used jk to connect domino with tomcat (at least never saw
 bugzilla entry on that). So it is deprecated by that fact.
 The same applies to JNI. Who uses that?

 Regarding locality, you mean local_worker and local_worker_only flags?
 IMHO that was one of the fuzziest things about jk that no one ever
 understood, not to mention that this never worked actually.
 Take for example the current documentation about local_worker:

 If local_worker is set to True it is marked as local worker. If in
 minimum one worker is marked as local worker, lb_worker is in local
 worker mode. All local workers are moved to the beginning of the
 internal worker list in lb_worker during validation.

 Now what that means to the actual user? I reeded that zillion times
 and never understood.
 Also further more:

This one is crucial for our Maintenance switchover see later.


 We need a graceful shut down of a node for maintenance. The balancer in
 front asks a special port on each node periodically. If we want to
 remove a node from the cluster, we switch off this port.

 WTF !? How? Which port? How to switch of this port?

 What counts the most is that you where unable to mark the node for
 shutdown, and not to accept new connections without session id.
 I suppose that was the purpose for those two directives, but I was
 never able to setup the jk in that direction.



First we use TC 3.3.2 (moving to 5.5.7)  behind Apache 1.3 on Solaris.
mod_jk version is a patched version based on mod_jk1.2.5

We only use one tomcat at a time to get traffic with a standby tomcat for 
maineneance.
This scenario also covers failover. We do not use the loadbalancer to actually 
balance
by factors.


We use sticky_sessions=true

This is our mod_jk setup if Tomcat-01 is serving the requests:

worker.list=loadbalancer
worker.loadbalancer.balanced_workers=ajp13-01, ajp13-02
worker.loadbalancer.local_worker_only=0

worker.ajp13-01.port=8009
worker.ajp13-01.host=tomcat-01
worker.ajp13-01.type=ajp13
worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=1

worker.ajp13-02.port=8019
worker.ajp13-02.host=tomcat-02
worker.ajp13-02.type=ajp13
worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=0


Now, all requests go to worker.ajp13-01, since local_worker=1 only for tomcat-01
so it is first in the queue.

Failover (in case tomcat-01 crashes) works, since local_worker_only=0 meaning
it also distributes the requests to the other machine if ajp13-01 is in error 
state


Now lets do maintenance (tomcat-01 should be shut down, tomcat-02 shall take 
the load):

What we do is just link in an other worker.property file on the webserver and
gracefully restart Apache to take effect.

The second worker.properties looks like this (almost the same):

worker.list=loadbalancer

Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results

Hans Schmid wrote:
Hi,
I just want to describe our usecase because we make heavy use of the
local_worker and local_worker_only flags right now.

We use those flags for 'maintenance' mode and failover very successfuly.
Cool ;).

But please see our setup and usecase below.
We only use one tomcat at a time to get traffic with a standby tomcat for 
maineneance.
This scenario also covers failover. We do not use the loadbalancer to actually 
balance
by factors.
OK. So basically you have two tomcat boxes where the second is used
only when you wish to put the first on maintenance?
Using new config:
worker.list=loadbalancer
worker.loadbalancer.balanced_workers=ajp13-01,ajp13-02
worker.loadbalancer.sticky_session=True
worker.ajp13-01.disabled=0
...
worker.ajp13-02.disabled=1
Disabled flag initially mark the worker as disabled.
It will not be used until:
Use the jkstatus console and set the:
worker.ajp13-02.disabled=0
and
worker.ajp13-01.disabled=1
And that's it.
Existing sessions will be forwarded to ajp13-01,
while new will go to the ajp13-02.
No need to make tricks with symlnks, graceful restarts, etc.
What's more, it works on all platforms and all web servers.
Also take a look at:
http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html
(Big red warning about worker names)
Regards,
Mladen.
-
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

2005-02-18 Thread 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 23 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-18022005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-18022005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-18022005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-18022005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-18022005/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 3118022005, brutus:brutus-public:3118022005
Gump E-mail Identifier (unique within run) #12.

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

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

reading xml file from disk with jsp bean under tomcat

2005-02-18 Thread Janvier Majirus

Hi all,
I am developing a simple module of my app that simple reads an xml file from 
disk and adds it on my database. I used tomcat-4.1.30 and jsp. My bean 
implements a method 
readFileFromDisk(String myfile).
When i try to execute my jsp page i have error message with code 404: myfile 
(file not fund).
Should anyone know where to place my xml file so that with my jsp bean i access 
to it?
I run my bean in standalone mode, all turn well. There is something in my 
servlet context configuration  that i don't know.
Any suggestion is welcome.
I thank all of you in advance.
Regards
 
Majirus


-
 Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail

Re: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-18 Thread Rainer Jung

So I don't see the point of forking 1.3. Both config and core features
are the same. Of course some advanced configuration properties where
changes, lot new added, but from the outside its still old mod_jk.
OK, understood from below. I agree concerning JNI deprecation. But read 
comments about local_worker.

Regarding locality, you mean local_worker and local_worker_only flags?
IMHO that was one of the fuzziest things about jk that no one ever
understood, not to mention that this never worked actually.
You are totally right about the bad documentation (at least concerning 
the status before you gave it a refresh). But I have the feeling that 
more people where using it like me, by studying the code (at least it's 
open source) and learning the functionality from there. So local_worker 
is a feature, that I assume is being useful and used.

So locality is not deprecated. Quite opposite, now it works, just
the local_worker_only is changed to sticky_session_force.
IMHO this is more clearer and descriptive directive then previous one.
My understanding of the use case: the term local_worker historically 
most likely comes from the idea, that if you use multiple systems each 
with apache and tomcat on them, then a call from an apache to the tomcat 
on the same system would be faster then going to a remote tomcat. 
local_worker should have indicated to prefer this (until 1.2.6 only one 
worker would work as a local_worker) worker unless a request carries a 
session id and stickyness is on or the local_worker is in error state. A 
more general better term would have been preferred_worker or just 
preferred and that's the way it is used today. At the moment there seems 
to be no more possibility to map a preference (I don't mean load 
balancing weights).

Still I know cases, where it makes sense to have a distinction for 
requests without session id/stickyness between:

- preferred (one or more)
- failover for the preferred (your redirect)
- maybe allowed (although the first two cases should be enough not to 
need more)
- the rest

The rest is there, because some worker may only be used, in case 
stickyness comes in.

With stickyness and session id one would have:
- sticky worker (the correct one)
- failover for the preferred (your redirect)
- any other in the same replication cluster (domain)
- the rest (loose session but can start the app again from the beginning)
Your redirect concept and my older domain patch share some use cases.
On the other hand local_worker_only only makes a difference if you 
configure local and non-local workers in a load balancer and all local 
workers go into error state. With local_worker_only, all further 
requests will fail. Without local_worker_only the non-local workers will 
be used. I always had the impression that only very few - if any - 
people will need this kind of feature.

You indicated i a separate answer, that one could use the disabled 
attribute instead. But I assume there is no failover to a disabled 
worker, whereas there should be to a non-preferred worker.

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

DO NOT REPLY [Bug 33629] New: - antiResourceLocking context option creates 'disk space' memory leak and handle leak

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33629.
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=33629

   Summary: antiResourceLocking context option creates 'disk space'
memory leak and handle leak
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Our application uses the Tomcat deployer to do hot redeployment of webapps as
part of a production system. As we are constrained to run Tomcat on Windows, we
turned the antiResourceLocking flag on (see Tomcat FAQ for Windows), having
tried the antiJARLocking flag previously and found it wasn't powerful enough
(Tomcat was sometimes failing to completely undeploy webapps).

The problem: we discovered that running with antiResourceLocking=true,
antiJARLocking=false introduced a huge leak of memory and file handles when
redeploying (a linear increase with number of deployments), caused by the Tomcat
JVM retaining handles to all of the .jar files in the tomcat\temp\ directory.
This also led to a huge 'disk space' leak, with several Gigabytes of old webapps
hanging around in the \temp\ directory after a few hundred redeploys. The
increase in memory and handles was not present before the antiResourceLocking
option was turned on.

We are using Struts, and have been able to replicate this behaviour with the
elementary struts-blank.war webapp, using Tomcat's own manager app to repeatedly
start and stop the app. (Tomcat is running on Windows XP SP2)

We tried keeping antiResourceLocking on and setting antiJARLocking=true as well.
This meant that all the handles were released and we could delete the remaining
jars from the \temp\ folder externally immediately after undeploy - great! But
there are still two problems with this solution:

   1) The Tomcat Windows FAQ says 'The antiResourceLocking attribute should not
be used at the same time as the antiJARLocking attribute.' This suggests
something bad happens if you use both - is this really true? If not, the
documentation should be changed. Something bad DEFINATELY happens if you DON'T
use them together! ;o)

   2) Although the file handles all seem to be released, the files still don't
get deleted. I suspect this may be because it takes a moment for the handles to
be released, and the deletion has been tried and failed before this point. This
is a serious problem - after running my stress test app overnight I came in to
find that tomcat had fallen over after eating up all 16GB of free disk space!
Our solution has been a background 'reaper thread' that tries to delete the temp
directories of undeployed apps that have not yet been deleted every few minutes
- I think Tomcat should include a fix for this issue when antiResourceLocking is
enabled, although I imagine there must be more elegant solutions than this!

-- 
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: mod_jk release policy - was: JK 1.2.9-dev test results

Rainer Jung wrote:
With stickyness and session id one would have:
- sticky worker (the correct one)
- failover for the preferred (your redirect)
- any other in the same replication cluster (domain)
- the rest (loose session but can start the app again from the beginning)
Your redirect concept and my older domain patch share some use cases.
Yes, I took your patch as conceptual start point.

On the other hand local_worker_only only makes a difference if you 
configure local and non-local workers in a load balancer and all local 
workers go into error state. With local_worker_only, all further 
requests will fail. Without local_worker_only the non-local workers will 
be used. I always had the impression that only very few - if any - 
people will need this kind of feature.

Well you have sticky_session_force. If the worker that has that session
is in error state then first the redirect (preferred) will be checked.
If this one is in error state too, the domain will be checked and
if not set or all are in error state 500 will be returned.
(Meaning: we don't have session replication and wish to brake in
case of failure)
If sticky_session_force is not set then other worker will be chosen
with loosing session.
(Meaning: we don't have session replication but wish to continue anyhow)
So you have two basic sticky_session concepts:
with or without session replication,
and that is what sticky_session_force determines as well how the
session loosing is treated.
The same applies when you have multiple domains. Then each domain
or group is treated as single worker and all rules mentioned above
are in place.
What is missing perhaps is a flag to indicate whether the worker name
or domain name will be used as service jvm route.
That way you could group workers without session replication in place.
(Putting workers on top of list concept). But then you don't need
the domains at the first place.
If you think some nodes (like local one) are faster, then simply use
higher lb_factor for those nodes.
You indicated i a separate answer, that one could use the disabled 
attribute instead. But I assume there is no failover to a disabled 
worker, whereas there should be to a non-preferred worker.

Disabled can be initially set for hot-standby. If set to on only the
requests with matched session id will be processed.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-18 Thread Hans Schmid

Thanks, Mladen,

as long as this disabled feature does not prevent the failover case, I am fine 
;)

See inline ...

 -Ursprüngliche Nachricht-
 Von: Mladen Turk [mailto:[EMAIL PROTECTED]
 Gesendet: Freitag, 18. Februar 2005 10:36
 An: Tomcat Developers List
 Betreff: Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results


 Hans Schmid wrote:
  Hi,
 
  I just want to describe our usecase because we make heavy use of the
  local_worker and local_worker_only flags right now.
 


  We use those flags for 'maintenance' mode and failover very successfuly.
 

 Cool ;).


  But please see our setup and usecase below.
 
  We only use one tomcat at a time to get traffic with a standby tomcat for 
  maineneance.
  This scenario also covers failover. We do not use the loadbalancer to 
  actually balance
  by factors.
 

 OK. So basically you have two tomcat boxes where the second is used
 only when you wish to put the first on maintenance?

Both Tomcats are always running, but the second one is used only for:
1.) Failover
2.) Maintenance switch - after this the roles of both Tomcats have switched
(TC-01 becomes standby)


In fact our scenario is a little bit more complex (I just did not want to 
explain
it in the first place). This brings in Loadbalancing as well:

We actually have between 3 and 6 Tomcats running at the same time depending on 
our
load, which has high seasonal peeks. So November is usually 20 times as much as 
February.
We are talking about 500 concurrent users in our webapp plus many more on the
static apache pages.

Example: 4 Tomcats are running in parallel. Just TC-01 has local_worker=1, the 
other
ones have local_worker=0. Every 30 minutes we switch our worker.properties to 
activate
a different tomcat by setting its local_worker=1 and the old one to 0.
The new tomcat has been just restarted before.

TC-01 - 30min. - TC-02 - 30min. - TC-03 - 30min. - TC-04 - 30min. - 
TC-01 again 

That way, every Tomcat gets new sessions for about 30 minutes. The long lasting
ols sticky sessions of our users (avg. session time 30min.) stay active on the
Tomcat which was active before for the rest of their live.

This effectively generates a loadbalancing distribution of about

TC-01 = 55% (the currently active Tomcat)
TC-04 = 35% (the one which was active before but still handles sticky sessions)
TC-03 = 10% (the one before TC-04, handling really long lasting old sessions)
TC-02 = 0%  (this one is the next candidate to restart and become active)


We can easily scale this approach by bringing in even more tomcats and shorter 
roll times (or less and longer times).

Works really well with our highly changing but well known traffic ;)
(and handles memory leaks as well ...)

Cheers Hans


 Using new config:

 worker.list=loadbalancer
 worker.loadbalancer.balanced_workers=ajp13-01,ajp13-02
 worker.loadbalancer.sticky_session=True

 worker.ajp13-01.disabled=0
 ...
 worker.ajp13-02.disabled=1


 Disabled flag initially mark the worker as disabled.
 It will not be used until:

 Use the jkstatus console and set the:
 worker.ajp13-02.disabled=0
 and
 worker.ajp13-01.disabled=1

 And that's it.
 Existing sessions will be forwarded to ajp13-01,
 while new will go to the ajp13-02.
 No need to make tricks with symlnks, graceful restarts, etc.
 What's more, it works on all platforms and all web servers.


 Also take a look at:
 http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html
 (Big red warning about worker names)

 Regards,
 Mladen.


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




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

DO NOT REPLY [Bug 33629] - antiResourceLocking context option creates 'disk space' memory leak and handle leak

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33629.
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=33629


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 11:44 ---
Sorry then, there is no solution. It's basically impossible to prevent webapps
from leaking file descriptors, as you see with locked JARs. If you report good
experience with using both settings at the same time, then it's good and I can
change the docs, but that's all that I can do. What I meant is that I consider
using both settings useless (each one introduces a startup performance penalty
for the webapp), so I will change the documentation.
 
Note that if antiJARLocking wasn't powerful enough, then it explains your
problems deleting the files in temp. If the files eventually get unlocked, then
it's good, but there's nothing I can do in Tomcat about that. I think you should
run periodic processes cleaning up leftover stuff in temp. Given the sequential
naming of the folders, this should be doable.

This cannot be addressed in Tomcat.

-- 
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: AW: AW: mod_jk release policy - was: JK 1.2.9-dev test results

Hans Schmid wrote:
Thanks, Mladen,
as long as this disabled feature does not prevent the failover case, I am fine 
;)

OK. So basically you have two tomcat boxes where the second is used
only when you wish to put the first on maintenance?

Both Tomcats are always running, but the second one is used only for:
1.) Failover
2.) Maintenance switch - after this the roles of both Tomcats have switched
(TC-01 becomes standby)
Ah, now I see your point.
If disabled worker will be never used unless enabled again,
but for failover you will need to set the
'redirect' to match that failover node.
Then regardless if it's disabled it will be used (of course if not being
in error state too).
redirect is ment to be used for that. You can even make redirect to a
group, thus having not only one, but rather n hot standby nodes.
In short: If initialy disabled worker will be never used (not even
for failover) unless some other worker has a redirect pointing to it,
all that untill the worker is enabled again.
If disabled during runtime the worker will not accept connections
without matching sessionid, while preserving exiting one.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33629] - antiResourceLocking context option creates 'disk space' memory leak and handle leak

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33629.
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=33629





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 12:01 ---
OK cool. I don't think the antiResourceLocking flag is usable without
antiJARLocking because of the massive handle leak, so it would be great if the
FAQ made this clear, as well as the possible need for some sort of temp cleanup
thread.

I wonder whether the Tomcat release notes should include something about the
Windows locking problem (and issues with the anti locking flags), as if you're
doing hot redeployment on Windows and you don't take appropriate action you're
going to end up with some very serious bugs.

-- 
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: reading xml file from disk with jsp bean under tomcat

2005-02-18 Thread Schalk Neethling

Janvier
Please post or attach code that is causing the problem.
Janvier Majirus wrote:
Hi all,
I am developing a simple module of my app that simple reads an xml file from disk and adds it on my database. I used tomcat-4.1.30 and jsp. My bean implements a method
readFileFromDisk(String myfile).
When i try to execute my jsp page i have error message with code 404: myfile (file not fund).
Should anyone know where to place my xml file so that with my jsp bean i access to it?
I run my bean in standalone mode, all turn well. There is something in my servlet context configuration that i don't know.
Any suggestion is welcome.
I thank all of you in advance.
Regards

Majirus

-
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail
!DSPAM:4215b893165461570615694!

--
Kind Regards
Schalk Neethling
Web Developer.Designer.Programmer.President
Volume4.Business.Solution.Developers
emotionalize.conceptualize.visualize.realize
Landlines
Tel: +27125468436
Fax: +27125468436
Web
email:[EMAIL PROTECTED]
Global: www.volume4.com
Messenger
Yahoo!: v_olume4
AOL: v0lume4
MSN: [EMAIL PROTECTED]
We support OpenSource
Get Firefox!- The browser reloaded - http://www.mozilla.org/products/firefox/
This message contains information that is considered to be sensitive or
confidential and may not be forwarded or disclosed to any other party without
the permission of the sender. If you received this message in error, please
notify me immediately so that I can correct and delete the original email.
Thank you.

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

cvs commit: jakarta-tomcat-site/xdocs-faq windows.xml

2005-02-18 Thread remm

remm2005/02/18 03:12:42

  Modified:xdocs-faq windows.xml
  Log:
  - Remove sentence.
  
  Revision  ChangesPath
  1.5   +0 -2  jakarta-tomcat-site/xdocs-faq/windows.xml
  
  Index: windows.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/windows.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- windows.xml   23 Dec 2004 11:59:02 -  1.4
  +++ windows.xml   18 Feb 2005 11:12:42 -  1.5
  @@ -137,8 +137,6 @@
 running (as a special note, when making changes JSPs without reloading
 the application, the changes has to be duplicated to the path where the
 web application resources have been copied in the temp folder).
  -  The antiResourceLocking attribute should not be used at the same time 
as
  -  the antiJARLocking attribute.
 /answer
   
   
  
  
  

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

Re: Tomcat roadmap

2005-02-18 Thread Tim Funk

Technically, someone will need to propose a VOTE for tomcat6. It would 
describe the features and release plan to be desired for 6. (Such as JSP 2.1 
support). So the real answer there is no timeline.

But based on past naming, the name tomcat 6 makes sense.
-Tim
Sam Ewing wrote:
Thanks Yoav,
JSP 2.1 specifications are currently in Early Draft
Review phase. Will these be implemented as a 'Tomcat
6' release?
I don't see a JCP for the next servlet specification
anywhere in the picture, so if there is new Tomcat
version (Tomcat 6?), would this be for Servlet 2.4/JSP
2.1? Is there any timeline for this?
Thanks again,
- Sam

Hi,
Tomcat is not a full J2EE container, only a Servlet
and JSP container.
Accordingly, J2EE spec releases don't matter per-se. 
They only matter if
they contain new Servlet or JSP spec releases in
them.
Tomcat 6 will implement the next version of the JSP
and Servlet specs,
whenever those come out.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat roadmap

2005-02-18 Thread Yoav Shapira

Hi,
Yup, Tim's right.  IIRC there's no precedence for one of the Servlet or JSP
Specs coming out without the other.  When that's closer to happening, e.g. a
public draft, then we'll look at the scope of changes and decide.  It'd be a
version change for sure, but possibly not a major one if it's only the JSP
Spec.

Are you asking simply out of curiosity? ;)

Yoav

 -Original Message-
 From: Tim Funk [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 18, 2005 6:47 AM
 To: Tomcat Developers List
 Subject: Re: Tomcat roadmap
 
 Technically, someone will need to propose a VOTE for tomcat6. It would
 describe the features and release plan to be desired for 6. (Such as JSP
 2.1
 support). So the real answer there is no timeline.
 
 But based on past naming, the name tomcat 6 makes sense.
 
 -Tim
 
 Sam Ewing wrote:
 
  Thanks Yoav,
 
  JSP 2.1 specifications are currently in Early Draft
  Review phase. Will these be implemented as a 'Tomcat
  6' release?
 
  I don't see a JCP for the next servlet specification
  anywhere in the picture, so if there is new Tomcat
  version (Tomcat 6?), would this be for Servlet 2.4/JSP
  2.1? Is there any timeline for this?
 
  Thanks again,
 
  - Sam
 
 
 Hi,
 Tomcat is not a full J2EE container, only a Servlet
 
  and JSP container.
 
 Accordingly, J2EE spec releases don't matter per-se.
 
  They only matter if
 
 they contain new Servlet or JSP spec releases in
 
  them.
 
 Tomcat 6 will implement the next version of the JSP
 
  and Servlet specs,
 
 whenever those come out.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



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

DO NOT REPLY [Bug 33632] New: - I had wrote a header filter extends RequestFilterValve for Tomcat 5.5.7

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33632.
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=33632

   Summary: I had wrote a header filter extends RequestFilterValve
for Tomcat 5.5.7
   Product: Tomcat 5
   Version: 5.5.7
  Platform: All
   URL: http://groups-
beta.google.com/group/lizongbo/browse_thread/thread/0738
9803736c635e/1ee8442eee5231d9#1ee8442eee5231d9
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When I want to forbidden some robort to access my website, 
I wrote somecode to extends the org.apache.catalina.valves.RequestFilterValve  
class.  I think this is an enhancement for Tomcat if this code is added to 
Tomcat's Source next version:

package org.apache.catalina.valves; 


import java.io.*; 
import javax.servlet.*; 


import org.apache.catalina.connector.*; 


/** 
 * pTitle: Request Header Filter For Tomcat/p 
 * pDescription: 
 * eg: set follow coment in ${catalina.home}/conf/server.xml: 
 * Valve className=org.apache.catalina.valves.RequestHeaderValve 
 *   header=User-Agent  deny=*httunit*/ 
 * then you can forbidden someone use httpunit to Access the Engine 
,Host or Context 
 * or: 
 * Valve className=org.apache.catalina.valves.RequestHeaderValve 
header=Referer 
 deny=*.mydomain.com, *localhost*/ 
 * then you can forbidden someone open the link from *.mydomain.com or 
localhost 
 * /p 
 * pCopyright: Apache License Version 2.0  /p 
 * pCompany: lizongbo/p 
 * @author lizongbo @ gmail.com 
 * @version 1.0 
 */ 
public final class RequestHeaderValve 
extends RequestFilterValve { 
  private String header = ; 
  public void invoke(Request request, Response response) throws 
IOException, 
  ServletException { 
String headervalue = request.getRequest().getHeader(getHeader()); 
headervalue = headervalue != null ? headervalue : ; 
process(headervalue, request, response); 
  } 


  public String getHeader() { 
return header; 
  } 


  public void setHeader(String header) { 
this.header = header; 
  }

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

DO NOT REPLY [Bug 33632] - I had wrote a header filter extends RequestFilterValve for Tomcat 5.5.7

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33632.
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=33632


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 13:57 ---
Created an attachment (id=14313)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14313action=view)
RequestHeaderValve

this is the src file.

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

DO NOT REPLY [Bug 33633] New: - Tomcat 5.5.6 does not run with security on

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33633.
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=33633

   Summary: Tomcat 5.5.6 does not run with security on
   Product: Tomcat 5
   Version: 5.5.6
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I try to run tomcat startup script with security=on right after I install 
Tomcat, i.e., the command:
 startup.bat -security

I get the following exceptions, same problem with Tomcat 5.5.7 (The exception 
below is from 5.5.7):

Feb 18, 2005 8:31:07 AM org.apache.catalina.core.ApplicationContext log
SEVERE: Exception starting filter BalancerFilter
javax.servlet.ServletException: java.security.AccessControlException: access den
ied (java.lang.RuntimePermission accessClassInPackage.org.apache.tomcat.util.dig
ester)
at org.apache.webapp.balancer.BalancerFilter.init(BalancerFilter.java:84
)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(Applicatio
nFilterConfig.java:225)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(Applica
tionFilterConfig.java:308)
at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFi
lterConfig.java:79)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.
java:3508)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4
079)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:759)
at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:
121)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(Contain
erBase.java:143)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73
7)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.jav
a:909)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.j
ava:872)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474
)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1106)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
eSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1019)

at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1011)

at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:440
)
at org.apache.catalina.core.StandardService.start(StandardService.java:4
50)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:683
)
at org.apache.catalina.startup.Catalina.start(Catalina.java:537)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
Feb 18, 2005 8:31:07 AM org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
Feb 18, 2005 8:31:07 AM org.apache.catalina.core.StandardContext start
SEVERE: Context startup failed due to previous errors
Feb 18, 2005 8:31:10 AM org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Controller as unavailable

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

DO NOT REPLY [Bug 33633] - Tomcat 5.5.6 does not run with security on

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33633.
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=33633


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|critical|minor
Version|5.5.6   |5.5.7




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 14:45 ---
I don't know about the problem (and I don't really care), but if the accessory
balancer webapp doesn't work, why not simply remove it ? Besides, the rest of
the server will work ok anyway, so try to file more accurate bug reports.

Note: this works ok for me with the default policy provided in Tomcat, so I
believe the cause of the problem is the policy file you are using.

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

Reminder: 5.5.8 tag tomorrow

2005-02-18 Thread Yoav Shapira

Howdy,

I'll be tagging and packaging Tomcat 5.5.8 tomorrow (Feb 19th) at 3pm my
time, 2000h UTC/GMT.  If you've made changes to the code recently, please
make sure they're in the changelog as applicable.  Thanks,

 

Yoav

DO NOT REPLY [Bug 33369] - Unpacking WAR files does not preserve timestamps

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33369.
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=33369


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:06 ---
As Remy said, if you want this, please submit a patch.

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

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33453.
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=33453


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:08 ---
Feel free to reopen this when you have a patch ready for us to evaluate -- 
looking forward to it.

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

DO NOT REPLY [Bug 33522] - Unable run a web module when you want to use javac

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33522.
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=33522





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:10 ---
Can you please point to the specific area of the docs you'd like updated, and 
what you would like them to say?

In general, we expect that a user competent enough to remove the JDT compiler 
is also competent enough to replace it as needed for his/her use-case, making 
this not a Tomcat bug.  But if the doc is incorrect I'd like to fix that.

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

DO NOT REPLY [Bug 33494] - jscv configure script fails on x86_64

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33494.
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=33494


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Unknown |Native:Packaging




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:12 ---
Changing component.

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

DO NOT REPLY [Bug 32569] - ServletContextListener will not die

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32569.
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=32569





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:13 ---
There are no remove decls, but there are direct assignments to null and 0-
sized arrays. ;(

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

DO NOT REPLY [Bug 29056] - java.util.ConcurrentModificationException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29056.
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=29056


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 15:16 ---
Please read what Remy said about distribution licenses, and Peter's latest 
MX4J suggestion.  5.0.30 includes a later MX4J I think, but 5.5.7 includes it 
for sure, and either way it's an easy swap.

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

5.5 support for Java 5 language features in JSPs

2005-02-18 Thread Jess Holle

Is there any realistic ETA for Java 5 language feature support in Tomcat 
5.5 JSPs?

Tomcat 5.0.30 has a simple web.xml flag to note the target language version.
5.5 does too -- if you force it to use javac rather than JDT.  This is 
sounding better and better the longer Tomcat 5.5 does not bundle a JDT 
that fully supports Java 5.

I realize this is not a Tomcat issue as much as a JDT issue -- except 
that Tomcat 5.5 uses JDT by default.  I also realize scriptlets are 
considered evil -- but they, and hard requirements for Java 5 *now*, are 
a fact of life for some of us.

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

Re: 5.5 support for Java 5 language features in JSPs

Jess Holle wrote:
Is there any realistic ETA for Java 5 language feature support in Tomcat 
5.5 JSPs?

Tomcat 5.0.30 has a simple web.xml flag to note the target language 
version.

5.5 does too -- if you force it to use javac rather than JDT.  This is 
sounding better and better the longer Tomcat 5.5 does not bundle a JDT 
that fully supports Java 5.

I realize this is not a Tomcat issue as much as a JDT issue -- except 
that Tomcat 5.5 uses JDT by default.  I also realize scriptlets are 
considered evil -- but they, and hard requirements for Java 5 *now*, are 
a fact of life for some of us.
Java 5 in scriptlets being a necessity ? Yeah rght. If you want it 
now, it's easy: add ant.jar and tools.jar to common/lib. JDT from 
Eclipse 3.1 will be used when it becomes stable.

I've read your previous complaint on the subject. One post is enough, 
and the question has already been answered earlier.

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

DO NOT REPLY [Bug 33636] New: - ExpandWar doesn't set the lastModified attribute

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33636.
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=33636

   Summary: ExpandWar doesn't set the lastModified attribute
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

files being created by the ExpandWar class have the creation date as the
lastModified attribute. This makes a proper cache handling quite difficult,
because the if-modified-since header increases after deploying, even if the
files in question haven't changed.

The attached simple patch changes the behaviour. It would be nice, if the patch
could be accepted at least as a configurable option. If so, I'd be ready to work
on more details and supply a larger patch later on.

Regards,

Jochen

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

DO NOT REPLY [Bug 33636] - ExpandWar doesn't set the lastModified attribute

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33636.
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=33636





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 17:04 ---
Created an attachment (id=14315)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14315action=view)
Patch setting the lastModified attribute on files being created by the
ExpandWar class


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

DO NOT REPLY [Bug 31204] - Tomcat exits on null pointer exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31204.
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=31204





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 17:17 ---
Have recently seen this issue in a production environment under load.

Appears to occur randomly via Apache 2.0.50/jk2.0.4 to Tomcat 5.0.27.  Our
application servlet nevers sees the text/xml POST.

Tomcat does not crash however, just never sees or processes the message.

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

DO NOT REPLY [Bug 33640] New: - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640

   Summary: RequestDispatcher.forward forwards to incorrect resource
when the request is wrapped with a set servletPath
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


If a HttpServletRequestWrapper overrides the getServletPath() method to return
it's own value, a RequestDispatcher.forward will forward to that resource, even
when obtaining the RequestDispatcher with getRequestDispatcher(String). I
believe the servlet spec says that it should forward to the resource specified
in getRequestDispatcher.

This also occurs on the latest Tomcat 4 - should I open a bug there too?

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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:06 ---
Created an attachment (id=14316)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14316action=view)
Simple war file displaying the problem


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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:09 ---
Please explain the problem better.

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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:12 ---
I'm not sure how to describe it better. Will the attached .war file (a very
simple application made to display this problem) not suffice?

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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:21 ---
Cool, but I think it happens because the request, which is mapped to the Jasper
servlet (*.jsp) will look at the servlet path to decide which JSP to serve.
Since your wrapper will still be at the top of the wrapper stack after the
forward as per the spec (this is so that wrapping is actually useful), the path
specified in the wrapper will be used.

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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:21 ---
The case is much simpler than what I though, so it is enough.

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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:38 ---
But SRV.14.2.8 states:
ServletContext.getRequestDispatcher(String)
Returns a RequestDispatcher object that acts as a wrapper for the resource
located at the given path. A RequestDispatcher object can be used to forward a
request to the resource or to include the resource in a response. The resource
can be dynamic or static.

Doesn't that state the it should forward to the String specified in
getRequestDispatcher(String)?

Also, SRV.14.2.5 states:
RequestDispatcher.forward(ServletRequest, ServletResponse)
For a RequestDispatcher obtained via getRequestDispatcher(), the ServletRequest
object has its path elements and parameters adjusted to match the path of the
target resource.

Are you saying there's a conflict elsewhere in the spec?


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

DO NOT REPLY [Bug 33640] - RequestDispatcher.forward forwards to incorrect resource when the request is wrapped with a set servletPath

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33640.
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=33640


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 18:53 ---
I suggest you read my answer.

Here it is another way:
- /uri.jsp maps to Jasper *.jsp
- Request is fowarded to the JSP servlet
- Your wrapper is the top of the wrapper stack (will be called first by Jasper)
- The main Jasper servlet uses getServletPath to determine which JSP it should 
send

Workaround: precompile (this maps your individual JSPs as servlets, and avoids
Jasper).

Please do not reopen the report, or I'll close the report again without any
further comments.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java mbeans-descriptors.xml

luehe   2005/02/18 10:00:22

  Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java NonLoginAuthenticator.java
SSLAuthenticator.java SingleSignOn.java
mbeans-descriptors.xml
  Log:
  - Made logging more consistent:
  
In some classes, we used to invoke logging methods on
container.getLogger(), in others, we were invoking them on Log
instance created by LogFactory (in some classes, we were using both!).
  
We now use Log instance created by LogFactory consistently.
  
  - Removed obsolete debug property from NonLoginAuthenticator MBean
descriptor
  
  Revision  ChangesPath
  1.16  +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
  
  Index: FormAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- FormAuthenticator.java7 Jan 2005 10:06:38 -   1.15
  +++ FormAuthenticator.java18 Feb 2005 18:00:22 -  1.16
  @@ -272,8 +272,8 @@
   if (session == null)
   session = request.getSessionInternal(false);
   if (session == null) {
  -if (container.getLogger().isDebugEnabled())
  -container.getLogger().debug(User took so long to log on the 
session expired);
  +if (log.isDebugEnabled())
  +log.debug(User took so long to log on the session expired);
   response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
  sm.getString(authenticator.sessionExpired));
   return (false);
  
  
  
  1.8   +8 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java
  
  Index: NonLoginAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- NonLoginAuthenticator.java23 Jun 2004 13:51:36 -  1.7
  +++ NonLoginAuthenticator.java18 Feb 2005 18:00:22 -  1.8
  @@ -23,7 +23,8 @@
   import org.apache.catalina.connector.Request;
   import org.apache.catalina.connector.Response;
   import org.apache.catalina.deploy.LoginConfig;
  -
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   
   /**
  @@ -38,6 +39,9 @@
   extends AuthenticatorBase {
   
   
  +private static Log log = LogFactory.getLog(NonLoginAuthenticator.class);
  +
  +
   // - Instance 
Variables
   
   
  @@ -91,8 +95,8 @@
   associate(ssoId, getSession(request, true));
   */
   
  -if (container.getLogger().isDebugEnabled())
  -container.getLogger().debug(User authentication is not 
required);
  +if (log.isDebugEnabled())
  +log.debug(User authentication is not required);
   return (true);
   
   
  
  
  
  1.19  +14 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
  
  Index: SSLAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- SSLAuthenticator.java 16 Jul 2004 05:47:22 -  1.18
  +++ SSLAuthenticator.java 18 Feb 2005 18:00:22 -  1.19
  @@ -30,7 +30,8 @@
   import org.apache.catalina.connector.Request;
   import org.apache.catalina.connector.Response;
   import org.apache.catalina.deploy.LoginConfig;
  -
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   
   /**
  @@ -45,6 +46,9 @@
   extends AuthenticatorBase {
   
   
  +private static Log log = LogFactory.getLog(SSLAuthenticator.class);
  +
  +
   // - 
Properties
   
   
  @@ -89,8 +93,8 @@
   Principal principal = request.getUserPrincipal();
   //String ssoId = (String) request.getNote(Constants.REQ_SSOID_NOTE);
   if (principal != null) {
  -if (container.getLogger().isDebugEnabled())
  -container.getLogger().debug(Already authenticated ' + 
principal.getName() + ');
  +if (log.isDebugEnabled())
  +log.debug(Already authenticated ' + principal.getName() + 
');
   // Associate the

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

luehe   2005/02/18 11:17:57

  Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
JAASMemoryLoginModule.java JDBCRealm.java
JNDIRealm.java RealmBase.java
UserDatabaseRealm.java
  Log:
  More logging cleanup
  
  Revision  ChangesPath
  1.13  +23 -24
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java
  
  Index: DataSourceRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- DataSourceRealm.java  3 Feb 2005 15:14:34 -   1.12
  +++ DataSourceRealm.java  18 Feb 2005 19:17:57 -  1.13
  @@ -33,6 +33,9 @@
   import org.apache.catalina.ServerFactory;
   import org.apache.catalina.core.StandardServer;
   import org.apache.catalina.util.StringManager;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
  +
   
   /**
   *
  @@ -50,6 +53,7 @@
   public class DataSourceRealm
   extends RealmBase {
   
  +private static Log log = LogFactory.getLog(DataSourceRealm.class);
   
   // - Instance 
Variables
   
  @@ -290,7 +294,7 @@
   
   } catch (SQLException e) {
   // Log the problem for posterity
  -
container.getLogger().error(sm.getString(dataSourceRealm.exception), e);
  +log.error(sm.getString(dataSourceRealm.exception), e);
   
   // Return not authenticated for this request
   return (null);
  @@ -318,8 +322,8 @@
*  authenticating this username
*/
   protected Principal authenticate(Connection dbConnection,
  -   String username,
  -   String credentials) throws 
SQLException{
  + String username,
  + String credentials) throws SQLException{
   
   String dbCredentials = getPassword(dbConnection, username);
   
  @@ -332,13 +336,13 @@
   validated = (digest(credentials).equals(dbCredentials));
   
   if (validated) {
  -if (container.getLogger().isTraceEnabled())
  -
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateSuccess,
  - username));
  +if (log.isTraceEnabled())
  +log.trace(sm.getString(dataSourceRealm.authenticateSuccess,
  +   username));
   } else {
  -if (container.getLogger().isTraceEnabled())
  -
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateFailure,
  - username));
  +if (log.isTraceEnabled())
  +log.trace(sm.getString(dataSourceRealm.authenticateFailure,
  +   username));
   return (null);
   }
   
  @@ -368,7 +372,7 @@
}
   dbConnection.close();
   } catch (SQLException e) {
  -
container.getLogger().error(sm.getString(dataSourceRealm.close), e); // Just 
log it here
  +log.error(sm.getString(dataSourceRealm.close), e); // Just log 
it here
   }
   
   }
  @@ -394,7 +398,7 @@
return dataSource.getConnection();
   } catch (Exception e) {
   // Log the problem for posterity
  -
container.getLogger().error(sm.getString(dataSourceRealm.exception), e);
  +log.error(sm.getString(dataSourceRealm.exception), e);
   }  
   return null;
   }
  @@ -450,9 +454,8 @@
   return (dbCredentials != null) ? dbCredentials.trim() : null;
   
   } catch(SQLException e) {
  - container.getLogger().error(sm
  - .getString(dataSourceRealm.getPassword.exception,
  -username));
  + log.error(sm.getString(dataSourceRealm.getPassword.exception,
  +username));
   } finally {
try {
if (rs != null) {
  @@ -462,10 +465,8 @@
stmt.close();
}
} catch (SQLException e) {
  - container.getLogger().error(sm
  -.getString(dataSourceRealm.getPassword.exception,
  +
log.error(sm.getString(dataSourceRealm.getPassword.exception,
   username));
  - 
}
   }

Re: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-18 Thread William A. Rowe, Jr.

At 12:56 PM 2/17/2005, Rainer Jung wrote:
Hi,

first: thanks a lot to Mladen for adding all the beautiful features [and 
removing CRLF :) ]. Big leap forward!

Here's a list of all mixed up line endings currently 
in jakarta-tomcat-connectors/jk/ ...

The Mismatch'ed files all represent files with mixed line endings
(some cr/lf, some cr/cr/lf.)

Fixed lines ./native/apache-1.3/mod_jk.dsp
Fixed lines ./native/apache-2.0/bldjk.qclsrc
Fixed lines ./native/apache-2.0/mod_jk.dsp
Fixed lines ./native/common/portable.h
Fixed lines ./native/domino/dsapi.dsp
Fixed lines ./native/iis/isapi.dsp
Fixed lines ./native/iis/isapi_redirect.reg
Fixed lines ./native/iis/installer/isapi-redirector-win32-msi.ism
Fixed lines ./native/iis/installer/License.rtf
Fixed lines ./native/isapi/tomcat_redirector.reg
Fixed lines ./native/netscape/nsapi.dsp
Mismatch in ./native2/CHANGES.txt:2 expected 1
Mismatch in ./native2/README.txt:2 expected 1
Mismatch in ./native2/STATUS.txt:2 expected 1
Fixed lines ./support/jk_exec.m4
Mismatch in ./xdocs/changelog.xml:2 expected 1
Mismatch in ./xdocs/index.xml:2 expected 1
Mismatch in ./xdocs/style.css:2 expected 1
Mismatch in ./xdocs/config/iis.xml:2 expected 1
Mismatch in ./xdocs/config/workers.xml:2 expected 1
Mismatch in ./xdocs/install/apache1.xml:2 expected 1
Mismatch in ./xdocs/install/iis.xml:2 expected 1
Mismatch in ./xdocs/news/20041100.xml:2 expected 1

Attached is my current lineendings script, if it's helpful.

Bill
#!/usr/local/bin/perl
#
#  Heuristically converts line endings to the current OS's preferred format
#  
#  All existing line endings must be identical (e.g. lf's only, or even
#  the accedental cr.cr.lf sequence.)  If some lines end lf, and others as
#  cr.lf, the file is presumed binary.  If the cr character appears anywhere
#  except prefixed to an lf, the file is presumed binary.  If there is no 
#  change in the resulting file size, or the file is binary, the conversion 
#  is discarded.
#  
#  Todo: Handle NULL stdin characters gracefully.
#

use IO::File;
use File::Find;

# The ignore list is '-' seperated, with this leading hyphen and
# trailing hyphens in ever concatinated list below.
$ignore = -;

# Image formats
$ignore .= gif-jpg-jpeg-png-ico-bmp-;

# Archive formats
$ignore .= tar-gz-z-zip-jar-war-;

# Many document formats
$ignore .= eps-psd-pdf-ai-;

# Some encodings
$ignore .= ucs2-ucs4-;

# Some binary objects
$ignore .= class-so-dll-exe-obj-;

# Some build env files in NW/Win32
$ignore .= mcp-xdc-ncb-opt-pdb-ilk-sbr-;

$preservedate = 1;

$forceending = 0;

$givenpaths = 0;

$notnative = 0;

while (defined @ARGV[0]) {
if (@ARGV[0] eq '--touch') {
$preservedate = 0;
}
elsif (@ARGV[0] eq '--nocr') {
$notnative = -1;
}
elsif (@ARGV[0] eq '--cr') {
$notnative = 1;
}
elsif (@ARGV[0] eq '--force') {
$forceending = 1;
}
elsif (@ARGV[0] eq '--FORCE') {
$forceending = 2;
}
elsif (@ARGV[0] =~ m/^-/) {
die What is  . @ARGV[0] .  supposed to mean?\n\n 
  . Syntax:\t$0 [option()s] [path(s)]\n\n . 'OUTCH'
Where:  paths specifies the top level directory to convert (default of '.')
options are;

  --cr keep/add one ^M
  --nocr   remove ^M's
  --touch  the datestamp (default: keeps date/attribs)
  --force  mismatched corrections (unbalanced ^M's)
  --FORCE  all files regardless of file name!

OUTCH
}
else {
find(\totxt, @ARGV[0]);
print scanned  . @ARGV[0] . \n;
$givenpaths = 1;
}
shift @ARGV;
}

if (!$givenpaths) {
find(\totxt, '.');
print did .\n;
}

sub totxt {
$oname = $_;
$tname = '.#' . $_;
if (!-f) {
return;
}
@exts = split /\./;
if ($forceending  2) {
while ($#exts  ($ext = pop(@exts))) {
if ($ignore =~ m|-$ext-|i) {
return;
}
}
}
if (($File::Find::dir . /) =~ m|/.svn/|i) {
return;
}
if (($File::Find::dir . /) =~ m|/CVS/|i) {
return;
}
@ostat = stat($oname);
$srcfl = new IO::File $oname, r or die;
$dstfl = new IO::File $tname, w or die;
binmode $srcfl; 
if ($notnative) {
binmode $dstfl;
} 
undef $t;
while ($srcfl) { 
if (s/(\r*)\n$/\n/) {
$n = length $1;
if (!defined $t) { 
$t = $n; 
}
if (!$forceending  (($n != $t) || m/\r/)) {
print Mismatch in  .$File::Find::dir./.$oname. : .$n. 
 expected  .$t. \n;
undef $t;
last;
}
elsif ($notnative  0) {
s/\n$/\r\n/; 
}
}
print $dstfl $_; 
}
if (defined $t  (tell $srcfl == tell $dstfl)) {

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

[EMAIL PROTECTED] wrote:
luehe   2005/02/18 11:17:57
  Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
JAASMemoryLoginModule.java JDBCRealm.java
JNDIRealm.java RealmBase.java
UserDatabaseRealm.java
  Log:
  More logging cleanup
I disagree with these changes: all these logs are application specific, 
which is why I direct them to the application category.

Can you explain why it is bad ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk release policy - was: JK 1.2.9-dev test results

William A. Rowe, Jr. wrote:
Here's a list of all mixed up line endings currently 
in jakarta-tomcat-connectors/jk/ ...

The Mismatch'ed files all represent files with mixed line endings
(some cr/lf, some cr/cr/lf.)

Two things.
See no CRLFs for any .h or .c inisde j-t-c.
Also Bill, will you be OK and ready to push
j-t-c to svn?
Regards,
Mladen.
Fixed lines ./native/apache-1.3/mod_jk.dsp
Fixed lines ./native/apache-2.0/bldjk.qclsrc
Fixed lines ./native/apache-2.0/mod_jk.dsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Reminder: 5.5.8 tag tomorrow

Yoav Shapira wrote:
Howdy,
I'll be tagging and packaging Tomcat 5.5.8 tomorrow (Feb 19th) at 3pm my
time, 2000h UTC/GMT.  If you've made changes to the code recently, please
make sure they're in the changelog as applicable.  Thanks,
Hi,
Can we remove the folowing as default log with /servlets-examples/?
2005.02.18 21:54:12 org.apache.catalina.core.ApplicationContext log
INFO: InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, 
filterClass
=filters.ExampleFilter]): 31 milliseconds

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

Re: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-18 Thread William A. Rowe, Jr.

It definately seems like j-t-c should be a first candidate
for svn conversion.  The other jakarta-tomcat repositories
are considerabily more complex.

But it would be good to have line endings straightened out
beforehand.

This checkout was with the cvs Win32 client.  It seems, from
all the troubles you have, that you are using the cygwin cvs
client?  The cygwin client checks out Unix text because it is
a unix shell, and shouldn't be expected to check out with Win32 
semantics (that combo would be an oxymoron.)

One nice advantage of SVN is that you can force an LF checkout
on win32, or CRLF checkout on unix, if that is what you desire.
Either is predicated on storing text files as (of all things)
text files - which the files I mentioned were not conformant.

Here are the results from checking out under unix (FYI - you can
force win32 or unix semantics with --cr or --nocr using my
lineends.pl script, and --force will ignore the mixed up line
endings when the file contains a mix of LF, CR/LF and CR/CR/LF
line endings);

Fixed lines ./jni/native/libtcnative.dsp
Fixed lines ./jni/native/libtcnative.dsw
Fixed lines ./jni/native/tcnative.dsp
Mismatch in ./jni/native/src/pool.c:1 expected 0
Mismatch in ./jni/native/src/shm.c:1 expected 0
Fixed lines ./jni/native/src/ssl.c
Fixed lines ./jni/native/build/win32ver.awk
Mismatch in ./jni/java/org/apache/tomcat/jni/OS.java:1 expected 0
Mismatch in ./jk/xdocs/changelog.xml:1 expected 0
Mismatch in ./jk/xdocs/index.xml:1 expected 0
Mismatch in ./jk/xdocs/style.css:1 expected 0
Mismatch in ./jk/xdocs/news/20041100.xml:1 expected 0
Mismatch in ./jk/xdocs/install/apache1.xml:1 expected 0
Mismatch in ./jk/xdocs/install/iis.xml:1 expected 0
Mismatch in ./jk/xdocs/config/iis.xml:1 expected 0
Mismatch in ./jk/xdocs/config/workers.xml:1 expected 0
Mismatch in ./jk/native2/CHANGES.txt:1 expected 0
Mismatch in ./jk/native2/README.txt:1 expected 0
Mismatch in ./jk/native2/STATUS.txt:1 expected 0
Fixed lines ./jk/native2/server/isapi/install4iis.js
Fixed lines ./jk/native2/server/apache2/bldjk2.qclsrc
Fixed lines ./jk/native/nt_service/nt_service.dsp
Fixed lines ./jk/native/netscape/nsapi.dsp
Fixed lines ./jk/native/isapi/tomcat_redirector.reg
Fixed lines ./jk/native/iis/isapi.dsp
Fixed lines ./jk/native/iis/isapi_redirect.reg
Fixed lines ./jk/native/iis/installer/isapi-redirector-win32-msi.ism
Fixed lines ./jk/native/domino/dsapi.dsp
Fixed lines ./jk/native/apache-2.0/mod_jk.dsp
Fixed lines ./jk/native/apache-1.3/mod_jk.dsp
Fixed lines ./ajp/ajplib/test/test.sln
Fixed lines ./ajp/ajplib/test/testajp.vcproj

(Just to reclarify, 0 expecting 1 means the module first encountered
0 CR's - just an LF, and deeper in the file encountered CR/LF - one
CR found.)

At 02:52 PM 2/18/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
Here's a list of all mixed up line endings currently in 
jakarta-tomcat-connectors/jk/ ...
The Mismatch'ed files all represent files with mixed line endings
(some cr/lf, some cr/cr/lf.)


Two things.
See no CRLFs for any .h or .c inisde j-t-c.
Also Bill, will you be OK and ready to push
j-t-c to svn?

Regards,
Mladen.

Fixed lines ./native/apache-1.3/mod_jk.dsp
Fixed lines ./native/apache-2.0/bldjk.qclsrc
Fixed lines ./native/apache-2.0/mod_jk.dsp





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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

2005-02-18 Thread Jan Luehe



Remy Maucherat wrote:
 [EMAIL PROTECTED] wrote:
 
luehe   2005/02/18 11:17:57

  Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
JAASMemoryLoginModule.java JDBCRealm.java
JNDIRealm.java RealmBase.java
UserDatabaseRealm.java
  Log:
  More logging cleanup
 
 
 I disagree with these changes: all these logs are application specific, 
 which is why I direct them to the application category.
 
 Can you explain why it is bad ?

I think the boundaries between container and application specific logs
has been pretty blurred, and we've been using the two inconsistently in
the past.

In my interpretation, any log messages issued by ServletContext.log()
should be directed to container.getLogger(), but any container
generated log messages should be directed to LogFactory.getLog().

Where do you see the line? This has been something that has confused
me in the past.


Jan


 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

Jan Luehe wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

luehe   2005/02/18 11:17:57
Modified:catalina/src/share/org/apache/catalina/realm
  DataSourceRealm.java JAASCallbackHandler.java
  JAASMemoryLoginModule.java JDBCRealm.java
  JNDIRealm.java RealmBase.java
  UserDatabaseRealm.java
Log:
More logging cleanup

I disagree with these changes: all these logs are application specific, 
which is why I direct them to the application category.

Can you explain why it is bad ?

I think the boundaries between container and application specific logs
has been pretty blurred, and we've been using the two inconsistently in
the past.
In my interpretation, any log messages issued by ServletContext.log()
should be directed to container.getLogger(), but any container
generated log messages should be directed to LogFactory.getLog().
Where do you see the line? This has been something that has confused
me in the past.
The thing has been blurred in 5.0. In 4.1, loggers were associated with 
containers (ex: a context). All logging for the container (including all 
subcomponents such as realm, manager, etc) would go to it. I liked that 
better.

I reintroduced that in 5.5 by adding a per container category (with 
nesting).

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

2005-02-18 Thread Jan Luehe



Remy Maucherat wrote:
 Jan Luehe wrote:
 
Remy Maucherat wrote:


[EMAIL PROTECTED] wrote:



luehe   2005/02/18 11:17:57

Modified:catalina/src/share/org/apache/catalina/realm
  DataSourceRealm.java JAASCallbackHandler.java
  JAASMemoryLoginModule.java JDBCRealm.java
  JNDIRealm.java RealmBase.java
  UserDatabaseRealm.java
Log:
More logging cleanup


I disagree with these changes: all these logs are application specific, 
which is why I direct them to the application category.

Can you explain why it is bad ?


I think the boundaries between container and application specific logs
has been pretty blurred, and we've been using the two inconsistently in
the past.

In my interpretation, any log messages issued by ServletContext.log()
should be directed to container.getLogger(), but any container
generated log messages should be directed to LogFactory.getLog().

Where do you see the line? This has been something that has confused
me in the past.
 
 
 The thing has been blurred in 5.0. In 4.1, loggers were associated with 
 containers (ex: a context). All logging for the container (including all 
 subcomponents such as realm, manager, etc) would go to it. I liked that 
 better.
 
 I reintroduced that in 5.5 by adding a per container category (with 
 nesting).

I'm still confused. ;-)
Which log messages are supposed to go to LogFactory.getLog(), and which
ones to Container.getLogger()?
For example, in StandardContext.java, we're using LogFactory.getLog()
exclusively. Shouldn't most of them also be considered app specific
and therefore be directed to Container.getLogger()?

I understand the difference between the 2 Log types is that one
carries the app name and the container nesting levels in its name,
whereas the other carries the fully qualified class name of the
container class that issued the log message.

Therefore, while the former allows log messages to be differentiated
by app name in the server log, the latter allows to pinpoint the
container component that printed the log message. I think a combination
of the two would be most useful.

I also think it would make sense to be able to distinguish the log
messages issued by ServletContext.log() from those log messages
that originate from the container.

I'll undo my 2 previous commits until I have a better understanding
of the issue.

Thanks,


Jan


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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java

luehe   2005/02/18 15:35:18

  Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java NonLoginAuthenticator.java
SSLAuthenticator.java SingleSignOn.java
  Log:
  Undid previous commit
  
  Revision  ChangesPath
  1.17  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
  
  Index: FormAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- FormAuthenticator.java18 Feb 2005 18:00:22 -  1.16
  +++ FormAuthenticator.java18 Feb 2005 23:35:18 -  1.17
  @@ -272,8 +272,8 @@
   if (session == null)
   session = request.getSessionInternal(false);
   if (session == null) {
  -if (log.isDebugEnabled())
  -log.debug(User took so long to log on the session expired);
  +if (container.getLogger().isDebugEnabled())
  +container.getLogger().debug(User took so long to log on the 
session expired);
   response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
  sm.getString(authenticator.sessionExpired));
   return (false);
  
  
  
  1.9   +3 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java
  
  Index: NonLoginAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- NonLoginAuthenticator.java18 Feb 2005 18:00:22 -  1.8
  +++ NonLoginAuthenticator.java18 Feb 2005 23:35:18 -  1.9
  @@ -23,8 +23,7 @@
   import org.apache.catalina.connector.Request;
   import org.apache.catalina.connector.Response;
   import org.apache.catalina.deploy.LoginConfig;
  -import org.apache.commons.logging.Log;
  -import org.apache.commons.logging.LogFactory;
  +
   
   
   /**
  @@ -39,9 +38,6 @@
   extends AuthenticatorBase {
   
   
  -private static Log log = LogFactory.getLog(NonLoginAuthenticator.class);
  -
  -
   // - Instance 
Variables
   
   
  @@ -95,8 +91,8 @@
   associate(ssoId, getSession(request, true));
   */
   
  -if (log.isDebugEnabled())
  -log.debug(User authentication is not required);
  +if (container.getLogger().isDebugEnabled())
  +container.getLogger().debug(User authentication is not 
required);
   return (true);
   
   
  
  
  
  1.20  +9 -13 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
  
  Index: SSLAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- SSLAuthenticator.java 18 Feb 2005 18:00:22 -  1.19
  +++ SSLAuthenticator.java 18 Feb 2005 23:35:18 -  1.20
  @@ -30,8 +30,7 @@
   import org.apache.catalina.connector.Request;
   import org.apache.catalina.connector.Response;
   import org.apache.catalina.deploy.LoginConfig;
  -import org.apache.commons.logging.Log;
  -import org.apache.commons.logging.LogFactory;
  +
   
   
   /**
  @@ -46,9 +45,6 @@
   extends AuthenticatorBase {
   
   
  -private static Log log = LogFactory.getLog(SSLAuthenticator.class);
  -
  -
   // - 
Properties
   
   
  @@ -93,8 +89,8 @@
   Principal principal = request.getUserPrincipal();
   //String ssoId = (String) request.getNote(Constants.REQ_SSOID_NOTE);
   if (principal != null) {
  -if (log.isDebugEnabled())
  -log.debug(Already authenticated ' + principal.getName() + 
');
  +if (container.getLogger().isDebugEnabled())
  +container.getLogger().debug(Already authenticated ' + 
principal.getName() + ');
   // Associate the session with any existing SSO session in order
   // to get coordinated session invalidation at logout
   String ssoId = (String) 
request.getNote(Constants.REQ_SSOID_NOTE);
  @@ -129,8 +125,8 @@
   */
   
   // Retrieve the certificate chain for this client
  -if (log.isDebugEnabled())
  -log.debug( Looking up certificates);
  +if

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

luehe   2005/02/18 15:43:20

  Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
JAASMemoryLoginModule.java JDBCRealm.java
JNDIRealm.java RealmBase.java
UserDatabaseRealm.java
  Log:
  Undid previous commit
  
  Revision  ChangesPath
  1.14  +23 -22
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java
  
  Index: DataSourceRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- DataSourceRealm.java  18 Feb 2005 19:17:57 -  1.13
  +++ DataSourceRealm.java  18 Feb 2005 23:43:20 -  1.14
  @@ -33,9 +33,6 @@
   import org.apache.catalina.ServerFactory;
   import org.apache.catalina.core.StandardServer;
   import org.apache.catalina.util.StringManager;
  -import org.apache.commons.logging.Log;
  -import org.apache.commons.logging.LogFactory;
  -
   
   /**
   *
  @@ -53,7 +50,6 @@
   public class DataSourceRealm
   extends RealmBase {
   
  -private static Log log = LogFactory.getLog(DataSourceRealm.class);
   
   // - Instance 
Variables
   
  @@ -294,7 +290,7 @@
   
   } catch (SQLException e) {
   // Log the problem for posterity
  -log.error(sm.getString(dataSourceRealm.exception), e);
  +
container.getLogger().error(sm.getString(dataSourceRealm.exception), e);
   
   // Return not authenticated for this request
   return (null);
  @@ -322,8 +318,8 @@
*  authenticating this username
*/
   protected Principal authenticate(Connection dbConnection,
  - String username,
  - String credentials) throws SQLException{
  +   String username,
  +   String credentials) throws 
SQLException{
   
   String dbCredentials = getPassword(dbConnection, username);
   
  @@ -336,13 +332,13 @@
   validated = (digest(credentials).equals(dbCredentials));
   
   if (validated) {
  -if (log.isTraceEnabled())
  -log.trace(sm.getString(dataSourceRealm.authenticateSuccess,
  -   username));
  +if (container.getLogger().isTraceEnabled())
  +
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateSuccess,
  + username));
   } else {
  -if (log.isTraceEnabled())
  -log.trace(sm.getString(dataSourceRealm.authenticateFailure,
  -   username));
  +if (container.getLogger().isTraceEnabled())
  +
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateFailure,
  + username));
   return (null);
   }
   
  @@ -372,7 +368,7 @@
}
   dbConnection.close();
   } catch (SQLException e) {
  -log.error(sm.getString(dataSourceRealm.close), e); // Just log 
it here
  +
container.getLogger().error(sm.getString(dataSourceRealm.close), e); // Just 
log it here
   }
   
   }
  @@ -398,7 +394,7 @@
return dataSource.getConnection();
   } catch (Exception e) {
   // Log the problem for posterity
  -log.error(sm.getString(dataSourceRealm.exception), e);
  +
container.getLogger().error(sm.getString(dataSourceRealm.exception), e);
   }  
   return null;
   }
  @@ -454,8 +450,9 @@
   return (dbCredentials != null) ? dbCredentials.trim() : null;
   
   } catch(SQLException e) {
  - log.error(sm.getString(dataSourceRealm.getPassword.exception,
  -username));
  + container.getLogger().error(sm
  + .getString(dataSourceRealm.getPassword.exception,
  +username));
   } finally {
try {
if (rs != null) {
  @@ -465,8 +462,10 @@
stmt.close();
}
} catch (SQLException e) {
  -
log.error(sm.getString(dataSourceRealm.getPassword.exception,
  + container.getLogger().error(sm
  +.getString(dataSourceRealm.getPassword.exception,
   username));
  + 
}
   }

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

Jan Luehe wrote:
Remy Maucherat wrote:
I'm still confused. ;-)
Which log messages are supposed to go to LogFactory.getLog(), and which
ones to Container.getLogger()?
For example, in StandardContext.java, we're using LogFactory.getLog()
exclusively. Shouldn't most of them also be considered app specific
and therefore be directed to Container.getLogger()?
It's a little risky. We should use the container logger only while the 
classloader is initialized.

It's probably far from perfect ;)
I understand the difference between the 2 Log types is that one
carries the app name and the container nesting levels in its name,
whereas the other carries the fully qualified class name of the
container class that issued the log message.
Therefore, while the former allows log messages to be differentiated
by app name in the server log, the latter allows to pinpoint the
container component that printed the log message. I think a combination
of the two would be most useful.
I also think it would make sense to be able to distinguish the log
messages issued by ServletContext.log() from those log messages
that originate from the container.
Yes, but from what I understand nobody uses these stupid ServletContext 
log methods anymore (they're right, it's a good idea :) ). So the log 
would be empty quite often, and the per container categories are useless.

I think the per container Logger from Tomcat 4.x was decent, that's what 
I'm trying to replicate.

I'll undo my 2 previous commits until I have a better understanding
of the issue.
In parallel, I want to start a commons component about a j.u.logging 
implementation keyed per classloader (as seen in bug 33143; it may be 
expanded a little later to allow per classloader configuration).

I'm looking for committers for the proposal :)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java

2005-02-18 Thread Jan Luehe

Remy,

Remy Maucherat wrote:
 Jan Luehe wrote:
 
Remy Maucherat wrote:

I'm still confused. ;-)
Which log messages are supposed to go to LogFactory.getLog(), and which
ones to Container.getLogger()?
For example, in StandardContext.java, we're using LogFactory.getLog()
exclusively. Shouldn't most of them also be considered app specific
and therefore be directed to Container.getLogger()?
 
 
 It's a little risky. We should use the container logger only while the 
 classloader is initialized.
 
 It's probably far from perfect ;)

Then how about RealmBase.authenticate()?

RealmBase.authenticate(String username, String credentials)
uses Container.getLogger(), whereas the other RealmBase.authenticate()
methods use LogFactory.getLog(). Shouldn't this be consistent?
This is where my confusion has stemmed from.

If you agree, I can help make the inconsistent cases consistent.

 In parallel, I want to start a commons component about a j.u.logging 
 implementation keyed per classloader (as seen in bug 33143; it may be 
 expanded a little later to allow per classloader configuration).
 
 I'm looking for committers for the proposal :)

Sounds interesting!

Jan


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

dengerous virus!Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp Constants.java LocalStrings.properties

do not send the message
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 2:56 PM
Subject: cvs commit:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp Constants.java LocalStrings.properties

 pero2005/02/15 01:26:19

   Added:   modules/cluster/src/share/org/apache/catalina/cluster/tcp
 Constants.java LocalStrings.properties
   Log:
   Start i18n support for o.a.c.cluster.tcp package

   Revision  ChangesPath
   1.1
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/Constants.java

   Index: Constants.java
   ===
   /*
* Copyright 1999,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*  http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

   package org.apache.catalina.cluster.tcp;

   /**
* Manifest constants for the
codeorg.apache.catalina.cluster.tcp/code
* package.
*
* @author Peter Rossbach
*/

   public class Constants {

   public static final String Package =
org.apache.catalina.cluster.tcp;

   }

   1.1
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/LocalStrings.properties

   Index: LocalStrings.properties
   ===
   AsyncSocketSender.create.thread=Create sender [{0}:{1,number,integer}]
queue thread to tcp background replication
   AsyncSocketSender.queue.message=Queue message to
[{0}:{1,number,integer}] id=[{2}] size={3}
   AsyncSocketSender.send.error=Unable to asynchronously send session w/
id=[{0}] message will be ignored.
   IDataSender.connect=Sender connect to [{0}:{1,number,integer}]
   IDataSender.create=Create sender [{0}:{1,number,integer}]
   IDataSender.disconnect=Sender disconnect from [{0}:{1,number,integer}]
   IDataSender.socketclose=Sender close socket to [{0}:{1,number,integer}]
   IDataSender.missing.ack=Wasn't able to read acknowledgement from
server[{0}:{1,number,integer}] in {2,number,integer} ms. Disconnecting
socket, and trying again.
   IDataSender.send.again=Send data again to [{0}:{1,number,integer}]
   IDataSender.send.message=Send message to [{0}:{1,number,integer}]
id=[{2}] size={3,number,integer}
   IDataSender.stats=Send stats from [{0}:{1,number,integer}] Nr of bytes
sent={2,number,integer} over {3} == {4,number,integer} bytes/request
   PoolSocketSender.senderQueue.sender.failed=PoolSocketSender create new
sender to [{0}:{1,number,integer}] failed
   PoolSocketSender.noMoreSender=No socket sender available for client
[{0}:{1,number,integer}] did it disappear?
   ReplicationTransmitter.getProperty=get property {0}
   ReplicationTransmitter.setProperty=set property {0}: {1}

 -
 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: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp DataSender.java AsyncSocketSender.java IDataSender.java PooledSocketSender.java ReplicationListener.java SimpleTcpCluster.java SocketSender.java TcpReplicatio

Dengerous virus is entering to your computer through this message do not
reply!
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 3:01 PM
Subject: cvs commit:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp DataSender.java AsyncSocketSender.java IDataSender.java
PooledSocketSender.java ReplicationListener.java SimpleTcpCluster.java
SocketSender.java TcpReplicationThread.java




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

Re: DO NOT REPLY [Bug 32480] - Unterminated tag if opening taglib tag is from an include file

dengerous virus is entering to your computer. do not send messages further!
- Original Message -
From: [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Tuesday, February 15, 2005 5:06 PM
Subject: DO NOT REPLY [Bug 32480] - Unterminated tag if opening taglib tag
is from an include file


 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
 RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
 http://issues.apache.org/bugzilla/show_bug.cgi?id=32480.
 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=32480


 [EMAIL PROTECTED] changed:

What|Removed |Added
 --
--
  Status|REOPENED|RESOLVED
  Resolution||INVALID




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



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_util.c jk_util.h

this message contains virus. don't send messages!
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 2:55 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/common
jk_lb_worker.c jk_util.c jk_util.h


 mturk   2005/02/16 01:25:35

   Modified:jk/native/common jk_lb_worker.c jk_util.c jk_util.h
   Log:
   Added disabled boolean directive to worker. This is used for
   hot-standby workers that can be later enabled using jkstatus console.

   Revision  ChangesPath
   1.53  +3 -1
jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c

   Index: jk_lb_worker.c
   ===
   RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
   retrieving revision 1.52
   retrieving revision 1.53
   diff -u -r1.52 -r1.53
   --- jk_lb_worker.c 16 Feb 2005 08:30:58 - 1.52
   +++ jk_lb_worker.c 16 Feb 2005 09:25:35 - 1.53
   @@ -643,6 +643,8 @@
p-lb_workers[i].s-lb_value =
p-lb_workers[i].s-lb_factor;
p-lb_workers[i].s-in_error_state = JK_FALSE;
p-lb_workers[i].s-in_recovering = JK_FALSE;
   +/* Worker can be initaly disabled as hot standby */
   +p-lb_workers[i].s-is_disabled =
jk_get_is_worker_disabled(props, worker_names[i]);
if (!wc_create_worker(p-lb_workers[i].s-name,
  props,
  (p-lb_workers[i].w),



   1.57  +16 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.c

   Index: jk_util.c
   ===
   RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
   retrieving revision 1.56
   retrieving revision 1.57
   diff -u -r1.56 -r1.57
   --- jk_util.c 16 Feb 2005 08:23:56 - 1.56
   +++ jk_util.c 16 Feb 2005 09:25:35 - 1.57
   @@ -65,6 +65,7 @@
#define REDIRECT_OF_WORKER  (redirect)
#define MOUNT_OF_WORKER (mount)
#define METHOD_OF_WORKER(method)
   +#define IS_WORKER_DISABLED  (disabled)

#define DEFAULT_WORKER_TYPE JK_AJP13_WORKER_NAME
#define SECRET_KEY_OF_WORKER(secretkey)
   @@ -640,6 +641,20 @@
return JK_FALSE;
}

   +int jk_get_is_worker_disabled(jk_map_t *m, const char *wname)
   +{
   +int rc = JK_TRUE;
   +char buf[1024];
   +if (m  wname) {
   +int value;
   +sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname,
IS_WORKER_DISABLED);
   +value = jk_map_get_bool(m, buf, 0);
   +if (!value)
   +rc = JK_FALSE;
   +}
   +return rc;
   +}
   +
void jk_set_log_format(const char *logformat)
{
jk_log_fmt = (logformat) ? logformat : JK_TIME_FORMAT;



   1.27  +3 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.h

   Index: jk_util.h
   ===
   RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.h,v
   retrieving revision 1.26
   retrieving revision 1.27
   diff -u -r1.26 -r1.27
   --- jk_util.h 16 Feb 2005 08:23:56 - 1.26
   +++ jk_util.h 16 Feb 2005 09:25:35 - 1.27
   @@ -78,6 +78,8 @@

int jk_get_worker_retries(jk_map_t *m, const char *wname, int def);

   +int jk_get_is_worker_disabled(jk_map_t *m, const char *wname);
   +
void jk_set_log_format(const char *logformat);

int jk_get_worker_list(jk_map_t *m, char ***list, unsigned
*num_of_wokers);




 -
 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: mod_jk release policy - was: JK 1.2.9-dev test results