from:"Tim Funk"

Re: SVN

2005-10-19 Thread Tim Funk


Here is a quicky way to get the latest 5.5.x branch:

http://marc.theaimsgroup.com/?l=tomcat-dev&m=11286855136&w=2

-Tim

Allistair Crossley wrote:


Hi,
 
Can I just ask if the Tomcat subversion migration is now complete? If i were to want to obtain the latest 5.5.x branch, would I just do so from /tomcat/current/5.5.x. Also, I presume the build.xml script will have changed now? I wonder if someone might highlight a few steps/ant targets for the new setup, and I will give it a shot and write a more formal help page,




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

svn commit failed

2005-11-07 Thread Tim Funk


I was trying to update the faq and on commit I get:

svn: Commit failed (details follow):
svn: MKACTIVITY of 
'/repos/asf/!svn/act/cbfb08b7-fd04-0410-812a-daddc51de6cc': 403 Forbidden 
(http://svn.apache.org)


I (think I) have the correct ID and password. Am I missing karma?

-Tim

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

Re: DO NOT REPLY [Bug 37150] - denial of service on many and long requests on v5.5.x

2005-11-08 Thread Tim Funk

Turning off directory listings by default is a good security practice. I only 
wait for the all the tomcat user questions of how to turn it on instead of off ;)


-Tim

Mark Thomas wrote:

--- Additional Comments From [EMAIL PROTECTED]  2005-11-08 23:45 
---

(In reply to comment #5)
The abstraction layer will make directory listings expensive (actually,
directory listings in Java are going to be expensive regardless), so I 
don't see

how this can be optimized.



Looking at the profiler output, I agree that this will always be slow. 
Closer inspection shows that at best I could reduce the time spent 
generating the listing by about a third. Not enough to make a major 
difference to this case.


Therefore, a warning in the docs is called for. Something like:
"Directory listings of directories containing many entries is an 
expensive process. Multiple requests for large directory listings can 
consume significant proportions of server resources. Use this option 
with caution."


The only remaining question is whether we turn directory listings off by 
default. Thoughts?


Mark



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

Re: directory listings

2005-11-30 Thread Tim Funk

It looks like this issue only occurs when the XSLT transformation is done on 
the directory listing. Which is not an out of box configuration so there is 
no worry for DOS (in case anyone is wondering).


Otherwise - looks interesting.  cacheTTL  and cacheMax should be configurable 
at servlet init time.



-Tim

Rafael H. Schloming wrote:


Hi,

I've been looking into the performance problems associated with many
concurrent requests of large directories. After doing some informal
benchmarking I've come up with the attached patch that improves
performance in this scenario. The patch adds a size limited Map with a 5
second timeout for caching rendered directory listings. My tests show a
significant performance improvement and the server no longer keels over
from OutOfMemory exceptions at higher concurrency levels.



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

Re: Proxied client IP logging

2005-12-14 Thread Tim Funk


I'm not really interested in this patch for a few reasons:
1) The functionality is available via a custom pattern
2) X-Forwarded-For (IIRC) can be multi-valued (comma seperated via multiple 
proxies)
3) X-Forwarded - This can break existing implementations for clients which 
are sending X-Forwarded-For (but we wish to ignore)


-Tim

Phil Shaw wrote:
While I'm subscribed to this list I would like to submit this method 
for logging forwarded IP addresses when Tomcat is behind a proxy. 
Replace the simple request.getRemoteAddr(); call in the invoke method 
of AccessLogValve with getClientIp(ServletRequest).


Hope this may be useful. If you need a more formal assignment to 
Apache, please let me know. 


Best regards,

Phil


/**
 *  Get a forwarded client IP address if available.
 *  @param  The servlet request object.
 *  @return The HTTP X-Forwarded-For header value if 
present,

 *  or the default remote address if not.
 */
private final String getClientIp(final ServletRequest request) {

  try {

HttpServletRequest httpRequest = (HttpServletRequest) request;

String forwardedIp = httpRequest.getHeader("X-Forwarded-For");

if (forwardedIp != null) {

  return forwardedIp;
}
else {

  return request.getRemoteAddr();
}
  }
  catch (ClassCastException cce) {

return request.getRemoteAddr();
  }
}


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

Re: Tomcat 6 plans (JSP 2.1)

2005-12-20 Thread Tim Funk


+0

(+1 - if I can realign my day job duties to free up time to help more :( )

-Tim

Remy Maucherat wrote:

Hi,

Besides adding support for Servlet 2.5 which does not seem too 
overwhelming, most of the specification work is on support of JSP 2.1. I 
am happy to report that Jacob Hookom is willing to contribute code to 
add the necessary JSP support in Tomcat (he has done such an 
implementation already, and owns the copyright on that code). To host 
the code, a new branch is going to be needed for Jasper (as well as a 
new folder in servletapi).


For testing the implementation, Jacob is going to need access to the JSP 
2.1 TCK (I suppose he'll need to be a committer to do that, but it 
should be ok by then).


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

Re: svn commit: r372314 - /tomcat/container/tc5.5.x/catalina/src/conf/web.xml

2006-01-26 Thread Tim Funk


It seems an extra 'a' snuck into this commit.

-Tim

[EMAIL PROTECTED] wrote:

Author: pero
Date: Wed Jan 25 13:05:47 2006
Modified: tomcat/container/tc5.5.x/catalina/src/conf/web.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/conf/web.xml?rev=372314&r1=372313&r2=372314&view=diff
+
+ppt
+application/vnd.ms-powerpoint
+
+a
   


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

Re: svn commit: r375582 - in /tomcat/connectors/trunk: http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java jk/java/org/apache/coyote/ajp/AjpAprProcessor.java

2006-02-07 Thread Tim Funk

Is it possible for Socket.sendbb to return 0? If so, on what conditions? 
(Trying to prevent an infinite loop)


[This happened to me with a jk bug in the past (tomcat 4.0 and an older 
version of jk) during a read where tomcat was assuming one thing and apache 
was assuming something else. (Can't remember the specifics) ]


-Tim

[EMAIL PROTECTED] wrote:

Author: remm
Date: Tue Feb  7 03:47:20 2006
New Revision: 375582

URL: http://svn.apache.org/viewcvs?rev=375582&view=rev
Log:
- 38464: Fix incorrect usage of sendbb method, which can in some cases do 
incomplete writes.
  Let me know if there are still problems.
- Note: for AJP, the fix is there just-in-case, as it is apparently impossible 
to get in this
  situation.

Modified: 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java?rev=375582&r1=375581&r2=375582&view=diff
==
--- 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
 (original)
+++ 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
 Tue Feb  7 03:47:20 2006
@@ -695,9 +695,14 @@
 protected void flushBuffer()
 throws IOException {
 if (bbuf.position() > 0) {
-if (Socket.sendbb(socket, 0, bbuf.position()) < 0) {
-throw new IOException(sm.getString("iib.failedwrite"));
-}
+int i = 0;
+int n = 0;
+do {
+if ((n = Socket.sendbb(socket, i, bbuf.position())) < 0) {
+throw new IOException();
+}
+i += n;
+} while (i < bbuf.position());
 bbuf.clear();
 }
 }



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

Re: [PATCH] catalina.sh 'CATALINA_NATIVE'

2006-02-09 Thread Tim Funk

I see the point of the native dir. Once my sysadmin sees this (whose not much 
of a java guy) - he'd be confused in seeing a bin dir with jar, bat, sh, and 
so files in it. Maybe itstime to reorg the the bin package dir. Possibly 
something along the lines of:


bin/ <-- All the sh and bat files
lib/jar <-- all the jar files for the system classloader. The scripts can 
also be made smart enough to iterate throug this dir and append them instead 
of hardcoding.

lib/native/{platform}/

Re: svn commit: r378241 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java

2006-02-16 Thread Tim Funk

On an unrelated note ... what is threadSync for? It looks like a leftover 
when the class was created from a copy of another Endpoint.


-Tim

[EMAIL PROTECTED] wrote:

Author: remm
Date: Thu Feb 16 05:22:51 2006
New Revision: 378241

URL: http://svn.apache.org/viewcvs?rev=378241&view=rev
Log:
- Fix a dumb programming error which could cause a crash (rare, fortunately) 
after a poll error.
  i-- was used for the loop, so if sockets add were pending, the first socket 
(position 0) would
  be destroyed but not removed from the poller.
- Change syncing to sync on "this", as init reallocates a new addS object. 
Please review to make
  sure all my syncs match my notify calls :)

Modified:

tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java



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

Re: Challenges for Java hosting

2006-04-07 Thread Tim Funk

I was thinking that too. A big problem with JVM's is memory leaks. The easy 
solution is to restart tomcat. But that causes a period of downtime due to 
waiting for a restart.


Why not make mod_ajp "smarter" or create a tomcat launcher where some parent 
process (apache, or the launcher) listens for requests from the public and 
uses AJP to have tomcat serve the requests. [The downside is added latenency]


The parent process can spawn a new tomcat after some configurable time and 
kill the old one. By using the cluster code - the sessions can be synced 
before the old tomcat goes away.


This mechanism could also be used as a way to perform graceful restarts too 
where an web app upgrade is done and reloading webapps will cause memory leaks.


[Disclaimer: the above ramblings may not be based in reality]

-Tim

Henri Gomez wrote:



I suppose native code could be used to improve the situation in some
areas (although I don't know how to do it ;) ).



Native code ? Do you imagine some sort of sub-JVM launching ?



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

Re: svn commit: r399545 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java

2006-05-04 Thread Tim Funk


Sun requires it.

-Tim

Filip Hanik - Dev Lists wrote:


did we say that TC6 will only support jdk1.5 and higher?
 


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

Re: svn commit: r536456 - /tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml

2007-05-10 Thread Tim Funk


Alternatives -
1: wrap in single quotes
'%h %l %u %t "%r" %s %b'

2: Use " (didn't try this)
"%h %l %u %t "%r" %s %b"


-Tim

Jean-Frederic wrote:

On Wed, 2007-05-09 at 19:58 +0900, Takayuki Kaneko wrote:

Hi,

IMO, you should arrenge the document like this.
-default) corresponds to %h %l %u %t "%r" %s %b".
+default) corresponds to %h %l %u %t "%r" %s %b.

"common" pattern is defined at org.apache.catalina.valves.Constant
public static final String COMMON_PATTERN = "%h %l %u %t \"%r\" %s %b";

Double quotations are needed because %r would have white spaces.


The \" doesn't work... The server.xml can't be parsed ;-(

Cheers

Jean-Frederic


Regards,

-Takayuki

On 5/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: jfclere
Date: Wed May  9 01:14:37 2007
New Revision: 536456

URL: http://svn.apache.org/viewvc?view=rev&rev=536456
Log:
Arrange the default value of pattern.

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml?view=diff&rev=536456&r1=536455&r2=536456
==
--- tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml Wed May  9 01:14:37 2007
@@ -179,7 +179,7 @@


 The shorthand pattern name common (which is also the
-default) corresponds to %h %l %u %t "%r" %s %b".
+default) corresponds to "%h %l %u %t %r %s %b".

 The shorthand pattern name combined appends the
 values of the Referer and User-Agent headers,



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

Re: [VOTE] Release build 6.0.13

2007-05-11 Thread Tim Funk


The only 2 things I noticed (which aren't a big deal)

The index pages had a bad links to the docs. (Now fixed)

The status screen has a rendering bug when a webapp is stopped. I didn't 
have a chance to dig into it - but its not a big deal either.


Otherwise - it looked good.

-Tim

Remy Maucherat wrote:

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.13/

According to the release process, the 6.0.13 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable



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

Re: Versioning in sources

2007-05-24 Thread Tim Funk

Why not change dist.xml to rewrite ServerInfo.properties (and other 
appropriate files) when creating the distribution src pacakges?


Then the extra commits are avoided.

-Tim

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

aah, that makes sense.

Remember that the release manager is carrying his/her own 
build.properties, and if you build from source, you should too.
in there you override any properties needed. That is why all binary 
builds are correct, but your build isn't.


what you are asking for is that we update build.properties.default 
before tagging a release, correct?


Obviously, I am purposefully not doing that (I find those stupid 
commits, well, stupid ...).




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

Re: Gotta submit a Board report this month...

2007-06-01 Thread Tim Funk


What about the new security site?

-Tim

Yoav Shapira wrote:

... by June 18th at the latest, because the Board meeting is on June
20th.  But since I'll be leaving the country on vacation the preceding
weekend, our deadline is a bit earlier, let's say June 15th.

This is just an early heads-up.  Anyone have comments on what should
go in, besides the standard list of releases we've done since the last
report?



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

Re: Draft Board report for June 2007

2007-06-08 Thread Tim Funk

I can take a year of service unless someone else is itching to do it 
instead.


-Tim

Yoav Shapira wrote:

Also, this reminds me: is anyone interested in taking over the Apache
Tomcat PMC Chair role for next year?




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

Re: [Configuration] Specifying Location of server.xml on startup

2007-07-03 Thread Tim Funk

(Just a guess ... but) There isn't interest. If you wish server.xml in a 
different location - switching to the embedded version of tomcat would 
be a better choice. See the mail archives/Google on embedding tomcat.


-Tim

Ole Ersoy wrote:

Hi,

Just wondering whether there are any plans around being able to pass a 
startup parameter for the location of server.xml?  I could add a JIRA if 
there is interest.



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

Re: Tomcat supporting PHP

2007-07-19 Thread Tim Funk


IIRC .. Glassfish took over the role of being RI.

-Tim

Henri Gomez wrote:

Tomcat is the RI for servlet/JSP engine, nothing less nothing more.



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

Re: [VOTE] Release build 6.0.14

2007-07-31 Thread Tim Funk

As long as http://issues.apache.org/bugzilla/show_bug.cgi?id=43002 is 
not serious then stable


-Tim

Remy Maucherat wrote:

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.14/

According to the release process, the 6.0.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable



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

Re: 6.x feature wishlist

2007-08-07 Thread Tim Funk

Filip Hanik - Dev Lists wrote:
I wanted to start a wish list of what we can move forward with, here is
a short list of items that I had in mind as a starter

1. Session replication - stateless backup location
Store the backup location of a session as part of the sessionId,
similar to the jvmRoute but opposite.
This way, you can scale a cluster horizontally, since the location of
the backup node doesn't have to be known until you fail over.

Since I loathe HttpSession - this means nothing to me.

2. Add a block/no-block parameter to InputFilter.doRead and
OutputFilter.doWrite
InputFilter -> public int doRead(ByteChunk chunk, Request unused,
boolean block) throws IOException;
OutputFilter -> public int doWrite(ByteChunk chunk, Response unused,
boolean block) throws IOException;
Servlet 3.0 will most likely expose non blocking read/write through
the servlet API, this will get us there ahead of time
Haven't thought of how we expose this API yet though, but more will
follow

I agree with remy. This option should be a wait and see.

3. Consolidate connector code
Currently we have
Http11Processor/Http11NioProcessor/Http11AprProcessor doing almost the
same thing, there is much that

can be consolidated to make the code more maintainable
Essentially, you create a Endpoint base line interface.
At the same time we could consolidate the Internal(In/Out)put buffers
as they are copies too.
We have some fairly tuned endpoints now, it would also be nice to make
these protocol agnostic.

It would be worth a try - but I'd expect too many special cases would
cause one large piece of convoluted code instead of 3+ copy/paste pieces
of code.

4. Startup -> server.xml warnings
If one enters an invalid element or attribute that is simply ignored
today, at least output an info or warn message letting the

admin know if its misconfiguration.

Please! A warning would be ideal if the attribute in the XML is not
found as a bean in the target object. This would be nice as a backport too.

5. Finish bayeux -> I started this in sandbox, took me a while to
understand the protocol, and its not as cool as I thought it would be

but I still feel its important for it to be part of Tomcat

Scratch away ...

6. Auto context logging
Automatically create loggers for each context, so that one doesn't
have to specify one per context in logging.properties
Of course, you can turn on/off the auto context logger through
logging.properties
I don't have enough pain points to have an opinion on this. But out of
the box - one log consolidated log file is better than one log file per
context. (YMMV)

7. File cache - use MappedByteBuffers for the file cache, that way the
send file operation can benefit even more
when you have two direct buffers, and you also avoid reading the disk
each time for a file

ideas on this came from Jeanfrancois Arcand.

(http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21)

A good file system does all this for us. Doing this as a Valve/Filter
would be nice. As a Valve/Filter - once can also cache dynamic content too.

8. Add getName()/setName() to the WebappClassLoader, name of the web app
classloader will correspond to the one of the Context container
Applications like Terracotta or AOP apps can much easier plug in and
be able to share data when they know what loader the class came from
would this work? The same webapp can be loaded multiple times for
various virtual hosts. The name would be the same for them all.

9. Add the configuration option to start the connectors after all apps
are deployed
If some applications are taking long to startup, load balancers are
already trying to send requests to the Tomcat instance, which is just
bound to a port, but not yet taking requests

That would be nice.

11.Timestamps & System.currentTimeMillis
System.currentTimeMillis is invoked everywhere during the chain of
events for a HTTP requests, even though most dates only need precision
down to the second.
I've received feedback that this could be improved by keeping a time
service, that updates a timestamp every second, and therefor reduces the
number of system calls
I think we would need to prove the theory before committing to the
implementation, but that should be pretty easy

If it can be proven than its worth it. I am highly skeptical.

12.Comet sample webapp
While most folks want to start with Comet, it is a strange question,
tons of users on the user list just are having a hard time getting kick
started

A sample webapp linked from the home page would be nice. (With the
appropriate Valves in place to help prevent some of the security reports
that typically get created from examples )

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

Re: svn commit: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-15 Thread Tim Funk

I thought changes were going into trunk and then when applicable, 
backported to 6.0.x.


Since this change is only writing warning messages. It seems appropriate 
that it can remain in 6.0.x.


-Tim

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
this should have been done in trunk, way too big change for a minor 
dot release upgrade
I suggest we move it there, revert in 6.0, and if it works well in 
trunk, we backport


Personally, I will not be working in trunk, which is your toy branch. I 
considered this change to be appropriate to be committed in 6.0.x. Are 
you vetoing this commit ?




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

Re: How to restrict access to particular files in Tomcat 4.1?

2007-08-17 Thread Tim Funk

Please use the user list for this topic. (With more details describing 
your situation)


In the meantime look at
- Servlet Filters
- Security Declarations in web.xml ()

-Tim

BNArun wrote:

Could any one tell me the way of restricting access to particular files in
Tomcat 4.1?



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

Re: [VOTE] Move trunk to sandbox

2007-09-04 Thread Tim Funk



Remy Maucherat wrote:


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

 



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

Re: [VOTE] Make released versions RTC

2007-09-04 Thread Tim Funk


What is a change? Any commit?

Is a change only for new features and bug fixes are out of scope?

-Tim

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.



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

Re: [VOTE] Make released versions RTC

2007-09-04 Thread Tim Funk

In that case

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

For ensuring new features start in "trunk" and work their way back, I'd 
+1. But since bugs (in BZ not marked as enhancement) would also need RTC 
- that is my reason for -1.

-Tim

jean-frederic clere wrote:

Tim Funk wrote:

What is a change? Any commit?

Is a change only for new features and bug fixes are out of scope?

My idea is to have it for all commits but only on release branches.
The idea is more to force people participating on the development of new
feature and help to fixing bugs.

Cheers

Jean-Frederic

-Tim

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.

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

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-13 Thread Tim Funk


D'oh.

I was tempted to post a patch first and discuss, but since it was only a 
setZZZ addition and the functionality is exactly the same when the 
parameter is NOT set - I thought this could go CTR. In light of the 
recent CTR/RTC discussions - we are still CTR until the vote passes. 
Likewise - while this is an API change - I guess my expectation on API 
change was anything that breaks backwards compatibility. (method 
signature changes) Unless someone subclassed FileDirContext and used the 
method names in the patch - then no one (user community) would notice.


When I first wrote this, my first pass was to subclass it where I could 
just call files() but that didn't work due since I still had to change 
other methods. I'd have to do a more comprehensive change (more risky 
IMO) to FileDirContext before I'd be able subclass it effectively.


The real use case is where you have uploaded files, or just a bunch of 
other files sitting in a different location on disk. You need to make 
them look as part of the current webapp while not having to rely on 
symlinks. So the feature is "similar" to the Alias directive in apache.


Since you -1 - I'd like to have a technical reason on why to back the 
patch out. Then I'd be glad to do so or make the appropriate changes. If 
the reason is - I think its bloat - I'm not sure how to resolve this issue.


[I'm actually on vacation this week so my replies might be slower than 
normal]


-Tim

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: funkman
Date: Thu Sep 13 08:19:59 2007
New Revision: 575332

URL: http://svn.apache.org/viewvc?rev=575332&view=rev
The reasonable thing would have been to talk a bit about it. I think 
using a subclass (assuming you really want to put this in, which I don't 
really like - small euphemism) would be more reasonable.


Since you did not do any of this, I will have to veto this patch.



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

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-14 Thread Tim Funk


The basic concept behind the logic is:
- Look for prefix
- Replace with new base path

The new path replacement is done before the symlink and case check is 
done so those checks are still preserved. (Just with the new path alias).


If there is a security manager in play - it should already be blocking 
access to directories outside of one's control.


For file/directory redirection such as replacing requesting /foo and 
then redirecting to /foo/ - I will add (if this is accepted) an entry to 
the FAQ to strongly recommend replacements include the trailing / - such 
that a user shoudl enter: /foo/bar/=/docs/tmp/ AND NOT 
/foo/bar=/docs/tmp since wierd behaviors can arise since a request of 
/foo/barry/file.pdf would yield /docs/tmpry/file.pdf (notice the last ry 
being preserved). I left this behavior in instead of requiring a 
trailing / since ... well if someone wishes to shoot themself in the 
foot - I won't stop them.


For /WEB-INF/ handling - this does provide an ability to have WEB-INF 
live somewhere else on the filesystem other than the webapp. When I 
first made the patch - I thought about making an exception for that - 
but then decided not to since I couldn't ponder a reason security wise 
to do so.


From a security point of view - the only gotcha I see is in a shared 
environment where you might suck in part of someone else's webapp in a 
shared environment. If this can be done - then it would be worthwhile 
adding a flag which would allow any aliasing to occur. Or a simpler 
alternative is if you are running with a security manager turned on - 
then aliasing is disabled.



-Tim

Remy Maucherat wrote:

Remy Maucherat wrote:
It's not a real veto anyway, but no proper review mechanism exists at 
the moment, and it's hard to integrate feature additions in 6.0.x 
without prior discussion.


I did review the patch:
- the syntax seems appropriate
- I don't know if it allows redirecting a single fine, but I think it 
should if it does not (I did not test it; at least the list feature 
would not be working right now)
- it seems like it will still validate going out of the remapped "base" 
path, which is good
- interaction with the webapp classloader, which might have special 
handling for /WEB-INF on the file based resources, is a question mark 
(compatibility with that would be good, if possible)
- security wise, it needs to be verified if the security manager 
prevents usage of the feature (normally it should, there are no 
privileged actions)



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

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-14 Thread Tim Funk


Hopefully I can get all the concerns in one email ...
[Pardon me if this is not the most coherent - I been on vacation this 
week and I was staining and putting sealer or some wood furniture and 
got too many fumes to the head ... but don't let that reflect badly on 
the patch ... that was done weeks ago .. I finally got around to 
cleaning up the rough edges on it before the final commit]


* Security by allowing new path exposure *
1) Its just as "easy" to write a wrapper to accomplish the same thing if 
one wishes to bypass the security.


2) If a deploy tool is used which is doing checks - adding an extra 
check to allow/deny/restrict scope should not be too hard to do. Since 
users can disable symlink checks in the same class (FileDirContext) - 
the same exposure could be had with a little more effort.


I'm not trying to hand wave the concerns away with the previous 2 
points. I've thought a while about how I can exploit this patch and most 
examples relied on assumptions which if the assumption were true - your 
system would have already been compromised.


* Servlet API Portability *
I chose this route since it is more portable. Other app servers provide 
the ability to do aliases. It really becomes a configuration exercise 
from appserverA to appserverB.


(Ignoring the alias issue at the moment) The beautiful thing about using 
JNDI as the method of serving resources is one can swap in WARDircontext 
instead of FileDirContext and the webapp code is none the wiser. In 
fact, I could create a JDBCDirContext which houses all resources as 
clobs/blobs and its STILL spec compliant and the webapp code is none the 
wiser.


(Now back on topic .. And history of the project that uses the patch - 
well not this exact patch but one darn near close since the original 
patch was done against 5.0)
The reason for aliases is I had static resources that needed to be 
served securely as part of a webapp. I can easily secure them via a 
web.xml security constraint or ServletFilter but the resources needed to 
appear as part of a webapp. But these resources are sourced by a 
different Enterprise system. I cannot drop a WEB-INF and child 
directories into a legacy Enterprise directory. (nor mirror it via a 
copy of the files) I also wanted to use the DefaultServlet as the means 
to serve the files. These were just pdfs and similar binary assets. 
Nothing magically, but potentially messy with If-Modified-Checks and 
partial content requests. I'd rather not reinvent (or copy) the wheel. 
So in a nutshell I needed a way for the Enterprise sourced content to 
look like it was part of the webapp. I would think this would not be an 
isolated case particular to me.


* Portability *
So depending on your point of view - this is portable or not portable. 
My vantage point is it is portable since I am writing user land code 
which assumes everything is contained inside my webapp. I can then rely 
on the servlet container to pull from other areas of the file system 
when need be to make the webapp appear as one logical unit. In this case 
- the user code is extremely portable but the configuration is dependent 
on the servlet container providing support for aliases.


* Summary *
I wanted a way for resources from various areas in the filesystem to 
appear as part of the webapp such the ServletContext.getResource() 
didn't know or care that the some content while being served from a 
directory sourced by some Enterprise system looked like part of the webapp.


At the end of the day - I could have relied on symlinks to implement the 
 project that dealt with this issue - but then when I needed to mirror 
content to our cluster of servers - I would've needed special setup to 
create the symlink as well as special rules to ensure that file 
replication excluded the symlink and its contents. Adding a symlink was 
a "much easy" alternative.


Yes - this is potentially bloaty and I tried on my first pass to 
subclass FileDirContext but the the number of touch points was to high 
that doing it right inside FileDirContext felt like the better alternative.


I have noticed other projects in the past few years at my employer where 
aliases would've come in handy instead of relying on symlinks.



* PS Summary *
I'm glad I didn't try to bring up the topic of asking how we can somehow 
detect OS so for the case sensitive OS's we can have the case checks 
turned off automagically ... and in other cases provide a switch to turn 
off symlink checking globally since these 2 checks can involve a lot of 
extra stat() calls. ;)


-Tim


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

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Tim Funk


Remy Maucherat wrote:

I tested with the security manager, and it doesn't behave correctly.

If the context.xml inside a webapp is:

  


The docBase hack attempt doesn't do anything (it's overwritten, I 
think), but the security manager does not prevent browsing the HD as the 
policy grants all permissions to all JARs in lib.


I'm not too sure about the "portability" argument. If it was valid, then 
we should add all proprietary features from all appservers right away. I 
am not aware of JBoss having such a feature either (it does have 
extensive CL configuration, though, but that is necessary due to its 
default behavior).


In your test example - you need to use C:/ instead of c:/ for the drive 
name. The case sensitive check was looking for C: instead of c:


>   docBase="c:/foo" aliases="/mysecretpath/=C:/" />


IIRC, docBase is set by its container *after* the XML attributes are 
set. (otherwise - we have a larger issue that a user can set a different 
doc base via the Resources directive independent of the aliases directive)


So you are saying if the security manager is turned on (which restricts 
file access) - it is ignored since FileDirContext is granted all 
permissions? If that is the case - do we have a related issue with 
AccessLogValve since absolute paths may be used there? (writing to 
inappropriate places or files)


I mentioned in an earlier thread that I can add a check to see if there 
is a security manager - and if one is present - then the alias option 
would be disabled. Does this sound like something worth pursuing?


I am still relatively young to the community and haven't been around for 
the 3.x - 4.x flame wars (or enough to get the full impact) but I guess 
we should document somewhere that the mission of Tomcat "is to provide a 
minimal set of functionality to service the Servlet and JSP 
specification. It is designed to be easily to be easily embedded and 
extended but core functionality will be minimal." With the  above 
statement - it is easily justified to then mark INVALID various feature 
requests in Bugzilla. As well as advertise that the project will be 
minimalist and encourage the use of the outside community to extend it 
as needed. Or maybe everyone knew thus all along and this is one of 
those days that I'm a little dense.


-Tim

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

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.

2007-09-15 Thread Tim Funk

As everyone will see ... I reverted. Its not the end of the world if 
this gets in since I can easily maintain a private version with alias 
support for myself. I thought it was a helpful bloatage for others. It 
might be worthwhile keeping the discussion active for the moment if 
anyone else has opinions.


-Tim

Costin Manolache wrote:

My understanding was that veto can only be against a patch.

And for a feature - some majority would do it.

Regarding feedback on patch - I think I expressed my concerns:
- more analysis and understanding of security implications
- if possible to do it at a different (higher) level
- if it can be done in a modular fashion, i.e. keeping the default impl the
way it is,
without this feature, and adding a way to configure a different module with
this or
other features. ( bonus points if the add-on module is a separate release
and very easy
to add )

In other words - bloat ( same as Remy's concern I guess) and understanding
if this is the
best possible implementation if the bloat is deemed acceptable.

Costin




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

Re: Review model take 2

2007-09-18 Thread Tim Funk


+1

-Tim



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

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

2007-09-22 Thread Tim Funk

Can we have a new VOTE with the six bullets (if it is that many - I'm 
losing track with all the responses).


I'm not quite sure what I'm voting for.

-Tim


I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).

   [ ] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


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

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

2007-09-22 Thread Tim Funk


Jim Jagielski wrote:

   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:



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

Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

2007-10-08 Thread Tim Funk


I would think a link is a must. So step 2 can be any of
2a) Upload a patch to /home/`whoami`/public_html/patches
2b) Add a patch to BZ
2c) Link to SVN patch
2d) If the patch is an attachment in an email to tomcat-dev - there is 
some public record of the email - link to that



-Tim

Filip Hanik - Dev Lists wrote:
since the STATUS file is also a voting forum, there must be a reference 
to an absolute patch/diff. otherwise, the implementation can change 
during the voting phase.

so what I suggest you do is

1. create a .patch file, with your proposed solution
2. upload it to your /home/pero/public_html/patches/ directory
3. put the URL reference to the .patch file in the STATUS file



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

Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS

2007-10-17 Thread Tim Funk

There was a request in bugzilla to pass in a new env variable called 
JAVA_EXE (or similar).


Could that be an acceptable alternative? Then it would make the bug 
submitter happy since he can symlink my_program_that_i_can_see_in_ps to 
java.


-Tim

Rémy Maucherat wrote:

On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote:

Hi Remy,

I think the patch is incomplete

this line seem not correct:

+else
+  JRE_HOME=/usr
+fi

better
+else
+  JRE_HOME=/usr/bin/java
+fi


The path to the Java executable is $JRE_HOME/bin/java, so /usr is the
correct value. However, on older distributions (just tested with my F7),
it will also pick up gij if it is installed (it does not really work).



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

Re: [LOBBYING] Add nio connector to configuration validation

2007-10-19 Thread Tim Funk


For java/org/apache/coyote/http11/Http11NioProtocol.java

Is it me or does this look odd after the patch (as well as before) ...
public void setProperty(String name, String value) {
setAttribute(name, value);
if (/*omitted for word wrap since it doesn't matter */) {
return ep.setProperty(name, value);
} else {
return ep.setProperty(name, value); /*commit omitted for ww*/
}
}

Should this be simplified too:
public void setProperty(String name, String value) {
setAttribute(name, value);
return ep.setProperty(name, value);
}

-Tim

Filip Hanik - Dev Lists wrote:
Ok, sending a little email to lobby for a useful change. To the contrary 
of comments and vetoes to this change, it doesn't change existing 
behavior, it simplifies it, and also adds the NIO connector to the 
validation of server.xml attributes.


It'd be nice to get one more vote, so that we can get it in before the tag.

 From STATUS
* Make server.xml parsing warnings more generic, add support for the NIO 
connector
* Connector is no longer an exception case. Any new component can still 
use setProperty and return a boolean

* to accept or reject the property
 http://people.apache.org/~fhanik/patches/digester-attribute-warnings.patch




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

Re: [PROPOSAL] Move Tomcat 5.0.x to the archive

2007-10-19 Thread Tim Funk


+1

-Tim



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

Re: Just an opinion

2007-10-30 Thread Tim Funk

After the 6.0.15 tag - I was hoping on looking at all the bugs with 
patches marked and (if valid) add them to the status (after first 
testing them). (Not sure how fast I can do that - I'll be picking the 
"easy" bugs first)


I'm sure there is great interest in speeding up the jsp compiling when 
tag files are included. I have done a tiny bit of research on this to 
see why it was happening - but realized thescope of change to make was 
beyond my time available. If someone else tackles it and does a good 
writeup (patch and performance numbers) - I'll take a look at it.



-Tim

Lucas Galfaso wrote:

Hi everybody,
  The first one is something that every and then there is a user that
writes about it in the user mailing list, and is related to how Tomcat
handles the compilation of .tag(x) files and how this is unbearably
slow. The second one is on how Tomcat addressed .jsps and .tagx files.
  With this in mind, I would like to start working on these two
issues, but would like to know your opinion. These might be "Great, I
think that these are things that we should take care about", "There is
no way we would allow such a refactoring", "As long as I do not have
to work on it, I have no issue" or "Just do not waste your time,
everybody here thinks that what we are doing is the best" :-p



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

Re: A high school student is taking on the task of moving our FAQ to the wiki

2007-11-28 Thread Tim Funk

It'd be better to police ourselves to not update it during the 
transition. Then when the FAQ is moved - we can have the FAQ archived 
(or chucked ... preferably archived)


Since the FAQ is rarely changed - its highly unlikely any changes were 
going to be made in the near future.


-Tim

Yoav Shapira wrote:

Hi,

One of the tasks we put out for the Google Highly Open Participation
contest (http://code.google.com/opensource/ghop/2007-8/) is Tim's
idea, to move our FAQ from static files to the wiki.

A student, Gianluca Varisco, is taking on that task.  He has just started work.

This is just an FYI for you all.  But in addition, I want to make no
further commits on the FAQ in Subversion.  Can we lock down that SVN
directory and make it read-only?




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

Re: GHOP #23

2007-11-29 Thread Tim Funk


(I swamped with other projects this week)

Hopefully here is enough detail:

For the site
1) In site/trunk/xdocs/stylesheets/tomcat-site.xsl - this is the file to 
change.

Below

add
rel="stylesheet" media='printer'/>


2)
In tomcat-printer.css - add a style
.noPrint {display:none}

3) Back in site/trunk/xdocs/stylesheets/tomcat-site.xsl - sprinkle 
class='noPrint' as needed


---
For tomcat {version} its a little more involved. Preferably this is done 
on trunk.


There is some XSL to chuck in webapps/docs/tomcat-docs.xsl which has 
some if/else logic to decide when to hide stuff in printer freindly 
versions. Since those physical docs will go away - many of those if 
checks can go away and be altered with class='noPrint'


For example:


  LEFT SIDE NAVIGATION
  

  

Becomes:
LEFT SIDE NAVIGATION

  



Also in webapps/docs/build.xml there will be some code to trim out since 
 the style task doesn't need run additional times for printer friendly 
versions.



One gotcha about the style task, if you change the xsl file and re-run 
the build - typically nothing happens. You need to chuck the generated 
files (or touch the xml files)



I'll try to get more details this evening if I was too vague about the 
above.


-Tim

Yoav Shapira wrote:

On Nov 29, 2007 12:33 PM, Vitezslav Smid <[EMAIL PROTECTED]> wrote:

I've just claimed GHOP Issue #23 so I'm writing for more information.
How should the printer-friendly version look? Should it simply copy the
current layout?

I know CSS very well, but with XSLT I'm rather a beginner.


Tim, I believe this was your idea.  Can you please share some details
with Vitezslav?



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

Re: GHOP#23 Review

2007-12-04 Thread Tim Funk

This can be marked complete. I tried to update the html files but on 
commit I get a collision with whoarewe.html so I gave up for the moment 
to at least get the good stuff applied.


I applied the opther printer stuff to trunk with some tweaks. I also 
discovered we don't use webapps/docs/build.xml [or at least from the 
main build.xml].



-Tim

Yoav Shapira wrote:

Vitezslav,

On Dec 4, 2007 8:12 AM, Vitezslav Smid <[EMAIL PROTECTED]> wrote:

http://code.google.com/p/google-highly-open-participation-asf/issues/detail?id=23).
It has been ready for review for two days and until it is resolved I can't
work on other tasks.


Thank you for your help.  I'm not sure when we'll have time to review
the work, but if you'd like to work on other tasks I can reclaim #23,
opening it up again.



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

FAQ chucking alternatives

2007-12-04 Thread Tim Funk


To chuck the FAQ from the site we can do this in one of a few ways
1) Delete the files and watch lots of 404's appear (yuck)
2) Change each faq with a META refresh (ok short term, crappy longer term)
3) Other??

Personally I'd like to archive them and 301 redirect the appropriate 
pages to the wiki. But with the current config, is .htaccess turned on 
anywhere where I (or anyione with the right karma) can add rewrite rules 
or appropriate?


-Tim

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

Re: FAQ chucking alternatives

2007-12-05 Thread Tim Funk

Cool. Then if no one objects, I'll add this /faq/.htaccess (Should be 
coming as txt attachement)


I noticed http://tomcat.apache.org/faq/development.html didn't get 
ported over. Thats in the attachment - but not done yet.


-Tim



RedirectPermanent /faq/bugs.html http://wiki.apache.org/tomcat/FAQ/Bugs
RedirectPermanent /faq/classnotfound.html 
http://wiki.apache.org/tomcat/FAQ/Class_Not_Found
RedirectPermanent /faq/cluster.html http://wiki.apache.org/tomcat/FAQ/Clustering
RedirectPermanent /faq/connectors.html 
http://wiki.apache.org/tomcat/FAQ/Connectors
RedirectPermanent /faq/database.html http://wiki.apache.org/tomcat/FAQ/Database
RedirectPermanent /faq/deployment.html 
http://wiki.apache.org/tomcat/FAQ/Deployment
RedirectPermanent /faq/development.html 
http://wiki.apache.org/tomcat/FAQ/Developing
RedirectPermanent /faq/fda-validation.html 
http://wiki.apache.org/tomcat/FAQ/FDA_Validation
RedirectPermanent /faq/logging.html http://wiki.apache.org/tomcat/FAQ/Logging
RedirectPermanent /faq/memory.html http://wiki.apache.org/tomcat/FAQ/Memory
RedirectPermanent /faq/meta.html http://wiki.apache.org/tomcat/FAQ/About
RedirectPermanent /faq/misc.html http://wiki.apache.org/tomcat/FAQ/Miscellaneous
RedirectPermanent /faq/otherOperatingSystems.html 
http://wiki.apache.org/tomcat/FAQ/Other_Operating_Systems
RedirectPermanent /faq/performance.html 
http://wiki.apache.org/tomcat/FAQ/Performance_and_Monitoring
RedirectPermanent /faq/security.html http://wiki.apache.org/tomcat/FAQ/Security
RedirectPermanent /faq/tomcatuser.html 
http://wiki.apache.org/tomcat/FAQ/Tomcat_User
RedirectPermanent /faq/unix.html http://wiki.apache.org/tomcat/FAQ/Linux_Unix
RedirectPermanent /faq/windows.html http://wiki.apache.org/tomcat/FAQ/Windows
RedirectPermanent /faq/index.html http://wiki.apache.org/tomcat/FAQ
RedirectPermanent /faq/ http://wiki.apache.org/tomcat/FAQ


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

FAQ Chucking last step

2007-12-07 Thread Tim Funk


The last step is to archive or delete the existing faq pages ..
site/trunk/xdocs-faq
site/trunk/docs/faq (except for .htaccess)

I'm unsure which svn commands to run
svn delete
- or -
svn move TO_WHERE?


-Tim

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

Re: FAQ Chucking last step

2007-12-07 Thread Tim Funk

I'm all done with the FAQ chucking now. I think I got everything. Just 
yell if I missed anything big.


-Tim

Mark Thomas wrote:

Yoav Shapira wrote:

On Dec 7, 2007 9:36 AM, Tim Funk <[EMAIL PROTECTED]> wrote:

The last step is to archive or delete the existing faq pages ..
site/trunk/xdocs-faq
site/trunk/docs/faq (except for .htaccess)

I'm unsure which svn commands to run
svn delete
- or -
svn move TO_WHERE?

Not sure.  Maybe tag with a label like "FAQ_MOVING_TO_WIKI" and then
svn delete from trunk?


+1

Mark



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

Re: svn commit: r603074 - /tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java

2007-12-11 Thread Tim Funk

But is name a string constant or is it built by using concatenation (via 
reading XML via digester or other)? If its the latter, then name is not 
a string constant.


-Tim

Filip Hanik - Dev Lists wrote:

if String objects are kept in a constants pool, then one would

   synchronized (name) {
   clazz = super.findClass(name);
   }

to allow concurrent loading of different classes,



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

Re: svn commit: r467989 - in /tomcat/tc6.0.x/trunk/java: javax/servlet/ServletException.java org/apache/catalina/core/StandardWrapper.java org/apache/catalina/valves/ErrorReportValve.java

2006-10-26 Thread Tim Funk


Adding this to both loops may be helpful too:
if (rootCause == rootCause.getCause()) {
break;
}


-Tim

[EMAIL PROTECTED] wrote:

Author: remm
Date: Thu Oct 26 06:08:58 2006
New Revision: 467989

URL: http://svn.apache.org/viewvc?view=rev&rev=467989
Log:
- Refactor exception reporting using Throwable.getCause, since TC 6 does not 
have the restrictions for modifications
  to the API implementation classes.
- ServletException.getRootCause now calls getCause.
- Also add some tweaks for robustness to cap recursion.
- Let me know if I did it wrong.



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

Re: svn commit: r467989 - in /tomcat/tc6.0.x/trunk/java: javax/servlet/ServletException.java org/apache/catalina/core/StandardWrapper.java org/apache/catalina/valves/ErrorReportValve.java

2006-10-26 Thread Tim Funk


Its specifically to address bad user code. For example:

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

Its the case where ServletException.getCause() returns something an 
instance of "user's custom Throwable" .. then the "user's custom 
Throwable" returns itself as the root cause.


-Tim

Remy Maucherat wrote:

Tim Funk wrote:

Adding this to both loops may be helpful too:
if (rootCause == rootCause.getCause()) {
break;
}


Throwable.getCause does return null in that case, so the loop should get 
out:

public Throwable getCause() {
return (cause==this ? null : cause);
}



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

Re: [VOTE] Tomcat 6.0.2

2006-11-21 Thread Tim Funk


Its time for beta. More folks will kick the tires.

-Tim

Remy Maucherat wrote:

Hi,
6.0.2 is:
[ ] Alpha
[X] Beta



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

Re: [TC6] Minimum coding style

2006-11-28 Thread Tim Funk

+1 trailing spaces always annoy me and text editors can easily be 
configured to strip them out.


An alternative is to change the email diffs to diff ignoring whitespace 
changes. Then lines can have all the trailing spaces they want and we 
won't see those diffs.


-Tim

Mladen Turk wrote:

Hi,

Just committed two files, and again I've bumped
upon the coding style.
Although it seems we are quite good relating to the
tabs, the trailing spaces are a real mess in some files.
There are lots of files where we have
if (...) {
followed with the one or more spaces.
Also there are lots empty lines that contains only
one more space chars.

I propose I make a simple script that will remove
all the trailing spaces from all files in the repository,
and after that we should take care on that just like
we take care on tabs.

I know it's not something critical, but neither are
unused imports, etc...
IMHO, it's better to do that at once rather then
having commits changing lots of irrelevant coding style
related issues.



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

Re: svn commit: r491995 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/loader/VirtualWebappLoader.java naming/resources/VirtualDirContext.java

2007-01-03 Thread Tim Funk


True - but helping developers develop code faster is typically a good thing.

I'd be OK if we created a bloat [I mean optional] package for things 
like this.


-Tim

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: funkman
Date: Tue Jan  2 16:51:31 2007
New Revision: 491995

URL: http://svn.apache.org/viewvc?view=rev&rev=491995
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41260
[Contribution] WebAppLoader and DirContext implementations for 
handling with expanded webapp during development


Hmmm. I've always thought this sort of functionality was dangerous bloat 
(= people will use it, esp in prod, and ruin into trouble).




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

Re: Escaping EL doesn't work in Tomcat 6?

2007-01-03 Thread Tim Funk


Is this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=41257
and http://issues.apache.org/bugzilla/show_bug.cgi?id=41258

I think these are the trouble:

Lines 2776-2777 in org.apache.jasper.compiler.Generator

TagAttributeInfo tai = attr.getTagAttributeInfo();
String type = tai.getTypeName();
  ^^^ <-- Is null

But the snippet above is contained in a if/else which wraps too many 
pages for me at the moment to try to determine a fix.



-Tim

Remy Maucherat wrote:

arjan tijms wrote:
We're using a number of custom tags that accept JSF (deferred) EL 
through dynamic attributes. In JSP 2.1 this is illegal. I therefore 
tried to deactivate expression evaluation by escaping the #{ pattern, 
but it seems that Tomcat 6.0.7 ignores this?


Please provide a test war if you can. Tag with dynamic attribute names 
are supposed to accept EL.




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

Re: svn commit: r496022 - in /tomcat: container/tc5.5.x/webapps/docs/changelog.xml jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java

2007-01-14 Thread Tim Funk


Is this screaming XSS attack?

Since javadocs in getRequestURI() say ... "The web container does not 
decode this String"



-Tim

[EMAIL PROTECTED] wrote:

Author: markt
Date: Sat Jan 13 18:45:48 2007
New Revision: 496022

URL: http://svn.apache.org/viewvc?view=rev&rev=496022

Modified: 
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java?view=diff&rev=496022&r1=496021&r2=496022
==
--- tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java 
(original)
+++ tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java 
Sat Jan 13 18:45:48 2007
@@ -301,7 +301,7 @@
 // creating unnecessary directories and files.
 if (null == context.getResource(jspUri)) {
 response.sendError(HttpServletResponse.SC_NOT_FOUND,
-   jspUri);
+   request.getRequestURI());
 return;
 }
 boolean isErrorPage = exception != null;



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

Re: svn commit: r496022 - in /tomcat: container/tc5.5.x/webapps/docs/changelog.xml jasper/tc5.5.x/src/share/org/apache/jasper/servlet/JspServlet.java

2007-01-14 Thread Tim Funk


Sweet - I thought that was the case. [But wanted to make sure.]

-Tim

Mark Thomas wrote:

Tim Funk wrote:

Is this screaming XSS attack?

Since javadocs in getRequestURI() say ... "The web container does not
decode this String"


It would be if it wasn't for line 177 of o.a.c.valves.ErrorReportValve
which does:
String message = RequestUtil.filter(response.getMessage());



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

Re: Build with Maven?

2007-01-18 Thread Tim Funk


There has been no desire to use maven to build tomcat.

Actually - there was interest but the answer turned to a quick no. See 
the mail list archives for details. (Many months ago)


-Tim

Ole Ersoy wrote:

Hi,

Does anyone know if there is a Maven build available
for Tomcat and whether there is any interest in
building Tomcat with Maven?


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

Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java

2007-01-22 Thread Tim Funk

Does this introduces a new dependency on the jsp-api - which could be a 
regression for people who embed tomcat without using jsp's.


Also the checking is not that aggressive any more in the case of nested 
exceptions. This may leave the root cause still unexposed.


This patch seems better:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?r1=466608&r2=496117&diff_format=h


-Tim

[EMAIL PROTECTED] wrote:

Author: markt
Date: Fri Jan 19 19:07:36 2007
New Revision: 498053

URL: http://svn.apache.org/viewvc?view=rev&rev=498053
Log:
Put the fix back for 39088 now the build is fixed. Sorry for the noise.

Modified:
tomcat/container/tc5.5.x/catalina/build.xml

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java



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

Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java

2007-01-22 Thread Tim Funk


I guess one could do this:

Create instance variable called JspException which is initialized to
protected jspExceptionClazz =
   Class.forName("javax.servlet.jsp.JspException");


Then findRootCause could be this (missing the exception checking) - in 
this version theRootCause is unneeded but can be kept for binary compat. 
Sorry for the line wraps


private static final Throwable findRootCause(Throwable theException,
Throwable theRootCause) {

  while (theException!=null) {
Throwable deeperRootCause  = null;
if (theException == theException) {
  return theException;
} else if (theException instanceof ServletException) {
  deeperRootCause = ((ServletException) theException).getRootCause();
} else if (jspExceptionClazz!=null && 
jspExceptionClazz.isAssignableFrom(theException)) {
  deeperRootCause = 
(Throwable)IntrospectionUtils.getProperty(rootCause, "rootCause");

}
if (deeperRootCause==null) {
  return theException;
}
if (theException == deeperRootCause) {
  return theException;
}
theException = deeperRootCause;
  }
  // In case theException was null in the first place
  return theException;
}




-Tim

Mark Thomas wrote:

Tim Funk wrote:

Does this introduces a new dependency on the jsp-api - which could be a
regression for people who embed tomcat without using jsp's.


Yes, it does add an additional dependency. I didn't consider the
embedded use case.


Also the checking is not that aggressive any more in the case of nested
exceptions. This may leave the root cause still unexposed.


My bad. I missed the recursion part of the patch.
 

This patch seems better:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?r1=466608&r2=496117&diff_format=h



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

Re: [VOTE] 6.0.x release process update

2007-02-05 Thread Tim Funk


+1

-Tim

Remy Maucherat wrote:

Hi,

I propose the following release process for Tomcat 6.0.x:

1. create tarball and unofficial binaries, put them on 
people.apache.org/~remm/tomcat-6

2. announce candidate binaries are available for testing
3. wait 2-3 days for testing
4. call for alpha/beta/stable vote on build
5. 3 +1's later publish previously created tarball and binaries to 
www.apache.org/dist/tomcat/tomcat-6

6. wait 2-3 days for voting to complete and/or for more testing
7. announce release after sync of the website




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

Re: Weekly builds

2007-02-12 Thread Tim Funk


Does this mean bringing back the automated builds?

+1 to automated weekly builds
-0 to manual weekly builds

-Tim

Remy Maucherat wrote:

Hi,

Since Tomcat 6 is still not stable, I propose producing a weekly Monday 
build, starting with one today.




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

Re: [VOTE] Release build 6.0.10

2007-02-22 Thread Tim Funk

I'll give it a whirl. I'm in the process of getting some new servers 
which can actually run java5. (Thus modernizing me to 2003)


-Tim

Remy Maucherat wrote:

Remy Maucherat wrote:
Candidate binaries are available here: 
http://people.apache.org/~remm/tomcat-6/v6.0.10/


According to the (slightly) updated release process, the 6.0.10 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable


So far, there are 3 binding votes for stable (with one from an inactive 
committer), and 1 for beta. While a beta or stable release could legaly 
be made, I don't feel comfortable with it without more votes.





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

Re: [VOTE] Release build 6.0.10

2007-02-22 Thread Tim Funk


Minor (non show stopper) issues:
- /manager/html-manager-howto.html is missing
- /manager/manager-howto.html is missing
- The default welcome page has a bad link to /tomcat-docs instead of docs

I'm OK with stable since it looks suitable for production use in many 
scenarios.


-Tim

Remy Maucherat wrote:

Remy Maucherat wrote:
Candidate binaries are available here: 
http://people.apache.org/~remm/tomcat-6/v6.0.10/


According to the (slightly) updated release process, the 6.0.10 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable


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

Re: Accepted meaning of 'should' in spec documents

2007-02-28 Thread Tim Funk


Typically its:

http://www.faqs.org/rfcs/rfc2119.html

-Tim

C. Halstead wrote:

Hi,

Just a quick clarification question, and sorry if it's a basic one.  When 
interpreting various spec documents is the qualifier 'should' always taken to 
indicate that something is optional?

Two cases in point:

Bug 41718 was marked as an enhancement request with the explanation of "should == 
optional"

Bug 41722 pertains to a web.xml element that is referred to in the spec once with (emphasis mine) 
"A security-role-ref element *should* contain a role-link sub-element..." and then later 
with "...an optional link to a security role(role-link)."

I'm just trying to understand the standards applied when interpreting the spec.



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

Re: [VOTE] New committer: Fabian Carrion

2007-03-01 Thread Tim Funk


+1

-Tim

Remy Maucherat wrote:

Hi,

I'd like to nominate Fabian Carrion as a committer on the Apache Tomcat 
project. Fabian contributed many useful patches, including helping add 
support for Servlet 2.5 in Apache Tomcat 6.0.



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

Re: svn commit: r513601 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/StandardContext.java webapps/docs/changelog.xml

2007-03-02 Thread Tim Funk

Re-reading the 2.4 spec - most references to load-on-startup state any 
non-negative number gets loaded in order lowest to highest. (Starting at 0)


BUT in the 2.2 DTD - there is this gem:
"The load-on-startup element indicates that this servlet should be
loaded on the startup of the web application.
The optional contents of these element must be a positive integer
indicating the order in which the servlet should be loaded.
Lower integers are loaded before higher integers.
If no value is specified, or if the value specified is not a positive
integer, the container is free to load it at any time in the startup
sequence."

So an older version of the spec had 0 special case where zero meant load 
on startup - but don't care when. (Since zero is not a positive 
integer). That special case disappeared starting in spec version 2.3.


-Tim

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: markt
Date: Thu Mar  1 18:38:26 2007
New Revision: 513601

URL: http://svn.apache.org/viewvc?view=rev&rev=513601
Log:
Port fix for bug 41739. Servlets with a load-on-startup value of zero 
should be loaded first.


I am not convinced by this (and the other non issues reported by this 
person), since this code was apparently present on purpose.



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

Re: svn commit: r529442 - /tomcat/tc6.0.x/trunk/webapps/manager/sessionDetail.jsp

2007-04-17 Thread Tim Funk

Looks good - the only thing I'd recommend to add is exception handling 
when displaying session values. For example - if someone places the 
following into their session: (A rather simplistic example)


new Object() {
  public String toString() {
  String s = null;
  return s.toString();
  }
  });


-Tim

[EMAIL PROTECTED] wrote:

Author: remm
Date: Mon Apr 16 16:30:03 2007
New Revision: 529442

URL: http://svn.apache.org/viewvc?view=rev&rev=529442
Log:
- Add session browser capabilities in the manager. Let me know if it creates 
problems (I checked XSS to some extent to,
  but please double check if you can).



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

Re: Binary build procedures

2006-05-23 Thread Tim Funk


The release manager  (RM)
- creates a binary from his copy of source.
- Generates a checksum key to allow validation of no tampering of the RM's 
build.

The RM could insert malicious code into the build. If that were to happen - 
the RM would probably be kicked out of the project in a hurry.


Its not valid to trust a source release download either. Its easy to tamper 
with the source just as it is the binary. But having the source at this point 
does allow for easy audits.


If you are really paranoid - build your binary from the appropriate TAG would 
be safest since you are getting the original source - not repackaged versions.


-Tim

Mark Claassen wrote:

My boss has implemented some new procedures with regard to open source
projects.  He believes the source distributions are trustworthy, but he is
not sure if he trusts the binary distributions.  I think the reasoning is
that he is uncertain if the binary distributions are controlled as well as
the source ones are.  And if they are not, someone could inject some
malicious code to expose customer data or something.

Can someone give me a brief explanation on how the binary distributions are
created for 5.5?  Are the binary distributions created automatically from
the repository, leaving no chance for nefarious tampering?



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

Miletones missing from tomcat 6

2006-07-11 Thread Tim Funk

Has anyone been able to update tomcat 6 bugs? It appears the milestone field 
is blank and because of that - tomcat 6 bugs can't be updated. Or I can't 
close the one I just opened because I'm just acting like an idiot today.


-Tim


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

Re: Out of Threads error

2006-08-04 Thread Tim Funk


For tomcat 5:
find . -type f |xargs grep "Increase maxThreads"
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/res/LocalStrings.properties


-Tim

James Courtney wrote:

I'm getting this message from my Tomcat 5.0.28 on Linux.

2006-08-02 21:01:19: ERROR All threads (400) are currently busy,
waiting. Increase maxThreads (400) or check the servlet status

Originally I had 200 threads configured and now 400 in an attempt to
avoid it.  Either number seems larger than what should be necessary.  It
seems quite likely that there's an application issue causing all threads
to block and accumulate or something so I need to do a kill -3 next time
it happens to try and see what everyone is up to.  That said, I was
attempting to grep the Tomcat source code for where this message is
logged and thus where I hoped to find and understand better the thread
manager.  I grepped for "Increase maxThreads", "Increase", and "are
currently busy" all to no avail in finding the code doing the logging.
Is the code which logs this message part of a dependency library not in
the tomcat source tree?  If so, which one please.  I just want to
understand the application behavior when the limit is reached.
  



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

Re: JIRA ?

2006-08-18 Thread Tim Funk


I'm indifferent.

It looks like all projects are moving in the direction of using JIRA and 
most likely Bugzilla will stop being supported by infrastructure [like 
CVS was]. So its probably a good time to move.


Is there talk of infrastructure stopping support of bugzilla anytime?

-Tim

Remy Maucherat wrote:

Maybe JIRA should be used for TC 6 ?

Rémy



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

Re: Relation of jasper and servlet API to Tomcat

2006-08-19 Thread Tim Funk

In different versions of Tomcat, Jasper could change "a lot" since its 
not a "public api".


The servlet api could also change in different Tomcat revisions too. But 
these changes are usually VERY minor and due to corrections/errata found 
in the spec.


Typically - when Tomcat changes  - there was usually a change in Jasper 
too. So any Tomcat release would require a Jasper release. But there 
might or might NOT be a servlet api change.


-Tim

William L. Thomson Jr. wrote:

First off, is there any reason Jasper and Servlet-API can't be projects
of their own? With their own binary releases. Reason I ask is that it
seems other apps use Jasper, not just Tomcat. With regard to
servlet-api, it seems to be the only open source implementation. Sun has
yet to release 2.4, only 2.3. So the only 2.4 servlet api I can find is
the one in Tomcat.

On Gentoo we have 3 packages built from the same Tomcat sources. If
Tomcat has a revision bump, does that mean Jasper or Servlet API changes
as well? If so we have to revision bump 3 packages instead of just
Tomcat. Also if I make a patch for servlet-api for Tomcat, the same
patch also applies to the servlet API package as well. So multiple
copies of the same patch. Much less if someone emerges both servlet api
and Tomcat they end up with two copies. Which sorta defeats what we do
on Gentoo. Which is to install a resource like log4j, commons stuff etc,
once, and symlink it where ever it's needed or used. So you don't end up
with different versions and multiple copies of jars and etc all over the
place.

  


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

Re: Bug in JNDIRealm with bindAsUser?

2006-08-30 Thread Tim Funk

IIRC, JNDIRealm can perform its queries in different styles depending on 
configuration (thus allowing for a lot of common, but somewhat 
convoluted code)


You can connect to JNDIRealm with an "admin like" role where you are 
always bound as the admin and you are looking up attributes about the 
suer which needs security rights. Then there is the other way by binding 
as the user to check authentication and roles.


While this doesn't immediately answer the question below - thats how 
JNDIRealm is coded.


-Tim

John Hyun wrote:

Hi all,

I believe there is a bug in the way JNDIRealm performs a bindAsUser. 
When using JNDIRealm and "bind" mode the relevant setting in 
server.xml will look like:




With my tomcat (5.5.15) installation configured this way, I find that 
I am able to authenticate with the server but JNDIRealm is unable to 
enumerate my group memberships. Looking at the source code I see the 
following section in JNDIRealm.java/bindAsUser():


-

// Set up security environment to bind as the user
context.addToEnvironment(Context.SECURITY_PRINCIPAL, dn);
context.addToEnvironment(Context.SECURITY_CREDENTIALS, 
credentials);


// Elicit an LDAP bind operation
boolean validated = false;
try {
if (containerLog.isTraceEnabled()) {
containerLog.trace("  binding as "  + dn);
}
attr = context.getAttributes("", null);
validated = true;
}
catch (AuthenticationException e) {
if (containerLog.isTraceEnabled()) {
containerLog.trace("  bind attempt failed");
}
}

// Restore the original security environment
if (connectionName != null) {
context.addToEnvironment(Context.SECURITY_PRINCIPAL,
 connectionName);
} else {
context.removeFromEnvironment(Context.SECURITY_PRINCIPAL);
}

if (connectionPassword != null) {
context.addToEnvironment(Context.SECURITY_CREDENTIALS,
 connectionPassword);
}
else {
context.removeFromEnvironment(Context.SECURITY_CREDENTIALS);
}

return (validated);

-

What this essentially does is add the user's uid and password to the 
DirContext to perform a bind, but then removes the uid and password 
from the context afterwards. Later on in the code when a getRoles() is 
performed, the lookup fails because the security principal/credentials 
are empty.


As an experiment I supplied the connectionName and connectionPassword 
in the realm config and everything worked. This, however, defeats the 
purpose of using bind mode and not everyone will be able to use this 
workaround (password read restrictions, etc).


I don't know if the solution is to leave the the user's credentials in 
the context but it doesn't seem to be working the way it is now. 
Considering that I haven't seen anyone else with this problem I'm 
assuming either hardly anyone uses LDAP with Tomcat or that nobody 
uses bind mode. Another possibility is that my company's LDAP server 
is breaking the connection between the bind and role search, thus 
causing a reconnect and that's when the lack of credentials exposes 
the problem.



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

Re: svn commit: r447793 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java

2006-09-19 Thread Tim Funk

Is there a reason deferred is spelled 2 different ways? (One with an 
extra f)


setDeferredSyntaxAllowedAsLiteral vs
isDefferedSyntaxAllowedAsLitteral


-Tim

[EMAIL PROTECTED] wrote:

Author: remm
Date: Tue Sep 19 02:47:32 2006
New Revision: 447793

URL: http://svn.apache.org/viewvc?view=rev&rev=447793
Log:
- Pass the two new values to the PageInfo instance.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java?view=diff&rev=447793&r1=447792&r2=447793
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Sep 
19 02:47:32 2006
@@ -129,6 +129,14 @@
 if (jspProperty.getIncludeCoda() != null) {
 pageInfo.setIncludeCoda(jspProperty.getIncludeCoda());
 }
+if (jspProperty.isDefferedSyntaxAllowedAsLitteral() != null) {
+
pageInfo.setDeferredSyntaxAllowedAsLiteral(JspUtil.booleanValue(jspProperty
+.isDefferedSyntaxAllowedAsLitteral()));
+}
+if (jspProperty.isTrimDirectiveWhitespaces() != null) {
+
pageInfo.setTrimDirectiveWhitespaces(JspUtil.booleanValue(jspProperty
+.isTrimDirectiveWhitespaces()));
+}
 



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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

2006-10-03 Thread Tim Funk


Mladen Turk wrote:

[ ] I'm for that proposal
[ ] I'm against that proposal
[X ] I don't care


-Tim

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

Re: Builds from the 6.0 branch

2006-10-10 Thread Tim Funk


+1

-Tim

Remy Maucherat wrote:

Hi,

I think the branch is in a state where builds can start being 
released. Some people asked for them earlier, so I don't think anyone 
will complain if this actually happens.


Given what changes were made, I expect stability to be reasonable.

Would it be ok to do some tweaking (including producing the necessary 
release documents - and learning how to tag properly in SVN as far as 
I am concerned) and then do a first tag at the end of this week ?



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

Re: [VOTE] Tomcat 6 release plan

2006-10-18 Thread Tim Funk



Remy Maucherat wrote:

Hi,

The release plan is located here:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/RELEASE-PLAN-6.0.txt


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




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

Re: question on IP for VirtualContext

2011-11-17 Thread Tim Funk

IIRC: this came into existence via
https://issues.apache.org/bugzilla/show_bug.cgi?id=41260 - it was donated
by the original contributor and the patch provided had the ASL license.

Borrowing features is OK, code is not unless the code is granted. It may be
as simple as contacting  the original author for another code grant and
posting that to bugzilla to keep everything as transparent as possible.

-Tim

Re: Proposal: use tomcat-version-number in server.xml element?

2011-12-02 Thread Tim Funk

Sounds like a job for a LifeCycleListener. (and therefore easy to backport)

-Tim

Re: Using comments.apache.org for our live docs

2012-11-08 Thread Tim Funk

Nice. +1

-Tim

On Wed, Nov 7, 2012 at 5:31 PM, Rainer Jung  wrote:
 


> I prepared a simple demo at:
>
> http://people.apache.org/~**rjung/tomcat-docs-comments/**tomcat-8.0-docs/
>
> It would be nice if you would have a look and we would discuss, whether we
> find it useful or not. The patch for build.xml and the xsl that I applied
> to build the comment enabled docs can be found at
>
> http://people.apache.org/~**rjung/patches/tc-trunk-**comments.patch
>
>

Re: [PROPOSAL] Remove case insensitivity option for Tomcat 7

2009-06-12 Thread Tim Funk


+1

-Tim

Mark Thomas wrote:

After a long discussion on the users the list [1], the question was
asked: "Is this feature required?"

  


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r784083 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/naming/resources/ webapps/docs/config/

2009-06-12 Thread Tim Funk



Typo:

Modified: tomcat/trunk/webapps/docs/config/context.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/context.xml?rev=784083&r1=784082&r2=784083&view=diff
==
--- tomcat/trunk/webapps/docs/config/context.xml (original)
+++ tomcat/trunk/webapps/docs/config/context.xml Fri Jun 12 11:38:29 2009
@@ -251,6 +251,16 @@



+  



Other thoughts:

1) Does the adding and removing of aliases need to be thread safe? Using 
ConcurrentHashMap instead of HashMap 



2) For public void addAlias(String path, BaseDirContext dirContext) {
Do we want to disallow / as the path? Or let the foot shooting be allowed?


3) public void setAliases(String theAliases)
If the file is not a directory (or does not exist) - we should do something.


-Tim


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug 37794 - Parameters, chunked requests and maxPostSize

2009-06-15 Thread Tim Funk


Yes chunked requests on POST are OK. I like option a too.

-Tim

Mark Thomas wrote:

For chunked request bodies, the content length is unknown. We can track
how many bytes we have read. If we read more the maxPostSize, what do we do?
a) Throw an exception that leads to a 500 response?
b) Drop what we have read already and ignore the rest?
c) Process what we have already and ignore the rest (there will almost
certainly be some invalid data at the end of the buffer in this case -
this will be skipped)?
d) Something else?
  



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug 37794 - Parameters, chunked requests and maxPostSize

2009-06-16 Thread Tim Funk

"infinite" size for POST is bad as a default. It would make it trivial 
to DOS the site.


-Tim

Josh Gooding wrote:

Gentlemen,

Let me ask this.  What is the maxPostSize in Tomcat?I'm ok with "a" but
I'm trying to think ahead in how to make an extremely large POST acceptable
maybe for 7.  I have not hit the maxPostSize at all, and I have uploaded
some large (+20MB) files with tomcat.  Let me see if I can successfully
reproduce the bug.  Would there be  way to remove the maxPostSize cap and
accept what ever the user puts in there size wise?
  



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r785381 - in /tomcat/trunk/java/org/apache/catalina/connector: LocalStrings.properties Request.java

2009-06-17 Thread Tim Funk


In tomcat/trunk/java/org/apache/catalina/connector/Request.java

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
Needs to be case insensitive

else if ("chunked".equalsIgnoreCase(

-Tim



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java

2009-06-18 Thread Tim Funk


I think this needs to be volatile ?
In (GetDateBenchmarkTest)
> +private long currentMillis = 0;

Same for (in TimeDateElementBenchmarkTest)
> +private Date currentDate = null;

Of course - since the test is single threaded - it doesn't really matter.

-Tim

ma...@apache.org wrote:

Author: markt
Date: Thu Jun 18 08:32:29 2009
New Revision: 785952

URL: http://svn.apache.org/viewvc?rev=785952&view=rev
Log:
Add some micro-benchmarks that enable the differences between the Sync and 
ThreadLocal approach to be compared



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r786471 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/catalina/loader/ java/org/apache/catalina/manager/ java/org/apache/catalina/servlet

2009-06-19 Thread Tim Funk


Where these meant to be included?
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=786471&r1=786470&r2=786471&view=diff
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/JspRuntimeContext.java?rev=786471&r1=786470&r2=786471&view=diff
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?rev=786471&r1=786470&r2=786471&view=diff


ma...@apache.org wrote:

Author: markt
Date: Fri Jun 19 12:10:05 2009
New Revision: 786471

URL: http://svn.apache.org/viewvc?rev=786471&view=rev
Log:
The servletapi gives us a perfectly good constant for 
'javax.servlet.context.tempdir'. Use it.




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs SVN migration to Tomcat

2009-08-14 Thread Tim Funk


+1

-Tim

Henri Yandell wrote:

Post discussion between Tomcat PMC and Jakarta PMC (with myself as the
go between), the Jakarta Taglibs subproject is going to move over to
Tomcat land. Chiefly this means:



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Testing new website sync process

2009-09-03 Thread Tim Funk

Does that mean the entire site would be in svn? If so - would that also 
mean that all documentation (like javadocs etc) would move into svn?


-Tim

Mark Thomas wrote:

Folks,

As part of the response to the recent compromise of ASF servers [1] the
infrastructure team are introducing a new way to sync web sites from svn
and are looking for PMS to volunteer to test the new process.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug workflow

2009-09-17 Thread Tim Funk

Anyone can change a bug to any status. (Much like in wikipedia - anyone 
can edit any page) Then the community would police people who dont 
behave. Which doesn't happen often.


-Tim

Uwe Günther wrote:
How does this work, if someone identifies a bug as NO BUG, does somebody 
set the status to "Resolved" in Bugzilla or better: How is the work flow 
here and who can close/resolve a bug?


In my case, I did some research in 47760 and IMO it isn't a bug. I but a 
comment there, CC-ed myself but what is the next step?




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug workflow

2009-09-17 Thread Tim Funk


It differs by the person. So here is a wild guess ..

But I would guess bugs are usually fixed 1st by interest. For example: 
Crap that bug affects my stuff too, I should look at that.


Other bugs are fixed by how interesting they. For example: hmmm .. that 
seems odd - I think I'll look at that.


Other bugs are fixed because they are there and its a good thing to do.

I'm not sure about everyone else, but I think the general concensus is 
priority is useful in distinguishing enhancement vs bug. But high 
priority vs low seems ignored.


Security fixes typically don't go into bugzilla. They are reported 
privately to the security list.


-Tim

Uwe Günther wrote:

So I could set this one to resolved! Thanks Tim.

Some other questions are popping up in my head right now:

- How do you guys to choose which bugs to fix first?

  OK there are priorities, you are able to fix some bugs,
  others are more difficult to you, some are security
  relevant, 

- If you pick up a bug for fixing, do you flag that up
  somewhere in Bugzilla?



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: DBCP 1.3/1.4

2009-12-08 Thread Tim Funk

[I know I'm missing something .. but] Would it be worth dropping dbcp 
from 7 and just use jdbc-pool?


-Tim


Mark Thomas wrote:

Commons is close to the next DBCP release.

I have been looking at this and there will, unfortunately, still be some
Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to
work around them without a complete refactoring and/or multiple JARs
and/or use of something like BCEL.

Rather than introduce any of this complexity, I recommend the following
approach.

Continue to ship Tomcat 6 with Java 5 built JDBC 3 support
Ship Tomcat 7 with Java 6 built JDBC 4 support

For the rare occasions where folks using Tomcat 6 want JDBC 4 support
(from the lack of posts on this topic on the users list I don't think
there are that many of them) they can grab the dbcp jar from Tomcat 7
and use that instead.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: DBCP 1.3/1.4

2009-12-09 Thread Tim Funk

If you can swing moving jdbc-pool as the next gen commons-dbcp - that 
would be sweet.


In which case, jdbc-pool would no longer exist and we'd only be left 
with dbcp.


Which leaves us with the tomcat 6 vs no access to JDBC4 - but some faqs 
can point the user on how to download the needed extra software/config.


-Tim

Mark Thomas wrote:

Hence my suggestion to use jdbc-pool as the basis for the commons-pool
and commons-dbcp refactoring. Commons has the developer community
jdbc-pool needs and jdbc-pool has the improvements commons-pool and
commons-dbcp needs.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r889585 - /tomcat/trunk/modules/bayeux/java/org/apache/tomcat/bayeux/request/PublishRequest.java

2009-12-11 Thread Tim Funk


Did you mena PublishRequest.class?

+private static final Log log = LogFactory.getLog(RequestBase.class);


-Tim

ma...@apache.org wrote:

Author: markt
Date: Fri Dec 11 12:14:05 2009
New Revision: 889585

URL: http://svn.apache.org/viewvc?rev=889585&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48370
Remove some unused imports

Modified:

tomcat/trunk/modules/bayeux/java/org/apache/tomcat/bayeux/request/PublishRequest.java




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r890856 - /tomcat/tc6.0.x/trunk/STATUS.txt

2009-12-15 Thread Tim Funk


Typically the proposer will commit with +3 - but its not mandatory.

As long as there are +3 - then it really doesn't matter who does the 
commit since there was a +3 consensus on the change.



-Tim


On 12/15/2009 11:39 AM, Mladen Turk wrote:

On 12/15/2009 05:13 PM, j...@apache.org wrote:

Some votes... those with>=3 I will commit today or so


Shouldn't that be a responsibility of the proposer?



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: BIO performance issues

2011-05-04 Thread Tim Funk

Solution B and disabling keepalive when a threshold is reached looks to be
the way to go. If people have issue with that, that's why the other
connectors exist.

-Tim


On Tue, May 3, 2011 at 4:02 PM, Mark Thomas  wrote:


>
> Solution B
> --
> Return to the Tomcat 6 implementation where maxConnections == maxThreads.
>
> Additional clean-up
> ---
> maxConnections is unnecessary in APR since pollerSize performs the same
> function.
>
> Summary
> ---
> The proposed changes are:
> a) restore disabling keep-alive when threads used >= 75% of maxThreads
> b) remove maxConnections and associated code from the APR connector
> c) remove the configuration options for maxConnections from the BIO
> connector
> d) use maxThreads instead of maxConnections for the BIO connector
> e) update the docs
>
>
>

Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat

2011-05-18 Thread Tim Funk

+1

On Wed, May 18, 2011 at 9:38 AM, Mark Thomas  wrote:

>
> We have the option to move to svnpubsub for managing our releases.
> Rather than copying artefacts to people.a.o and then waiting for rsync
> (every around 2 hours) we would commit the artefacts to svn and a commit
> hook would update the /dist/tomcat area on the www servers immediately.
>
> If folks would like to go this route, I am happy to do the work on our
> end to migrate /dist/tomcat to svnpubsub.
>
>

Re: Fixing bug 33453

2011-05-23 Thread Tim Funk

 How about calling it getDependantsMap() instead of getDependants() ?

Then catch the NoSuchMethodException (I in the case where the compiled jsp
doesn't have getDependants() and that would force a recompile (and then the
new version would be OK)

-Tim

On 5/20/2011 12:31 PM, Mark Thomas wrote:

All,

I've been looking at [1]. Ignoring the flames, there do appear to be
several use cases where the current time-stamp checks are insufficient
(although there are simple work-arounds). I have a patch [2] but I don't
particularly like the fact that it breaks binary compatibility with JSPs
compiled with an earlier version. My instinct is that this is bad. What
does everyone else think?

I do have an idea for addressing this:
- Leave JspSourceDependent as is in 7.0.14 but deprecate it
- Add a new JspSourceDependent2 interface (better names welcome)
- Compilation always uses JspSourceDependent2
- Isoutdated checked for JspSourceDependent as well as
JspSourceDependent2 and any classes implementing JspSourceDependent are
treated as outdated.

Thoughts?

Mark

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=33453
[2] https://issues.apache.org/bugzilla/attachment.cgi?id=27040&action=diff

Re: Outdated Servlet 3.0 Javadocs available on tomcat.apache.org

2011-06-01 Thread Tim Funk

Is the PDF of the spec which is downloadable up to date with respect to
comments? I don't think the pdf version of the spec is CDDL ... but it may
have other conditions on it. If the PDF version of the spec is up to date,
someone might be able to copy from the PDF and paste into the javadocs and
add the correct formatting.

-Tim

On Wed, Jun 1, 2011 at 4:57 AM, Mark Thomas  wrote:

>
> Those comments are part of CDDL licensed source code. My reading of
> http://www.apache.org/legal/resolved.html#category-b is that we can't
> copy the comments directly into our source code.
>
>

Re: Outdated Servlet 3.0 Javadocs available on tomcat.apache.org

2011-06-01 Thread Tim Funk

Doh - Older specs had the javadocs. I never scrolled to the end to notice it
missing from the current spec.

-Tim

On Wed, Jun 1, 2011 at 11:29 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Tim,
>
> On 6/1/2011 8:35 AM, Tim Funk wrote:
> > Is the PDF of the spec which is downloadable up to date with respect to
> > comments?
>
> The version of the PDF I'm looking at (3.0 Final, 1434610 bytes, dated
> 10 December 2009) does not include the javadoc at all... it does include
> some documentation of certain methods... I have only done a casual
> reading at this point.
>

Re: svn commit: r1131263 - in /tomcat/trunk: java/org/apache/catalina/session/JDBCStore.java java/org/apache/catalina/session/LocalStrings.properties webapps/docs/changelog.xml webapps/docs/config/man

2011-06-03 Thread Tim Funk

If NamingExceptionOccurs - should this instead rethrow a SqlException
instead of letting the logic keep going? Otherwise wouldn't a SqlException
be thrown later in the method?

-Tim

On Fri, Jun 3, 2011 at 6:13 PM,  wrote:

> Author: markt
> Date: Fri Jun  3 22:13:09 2011
> New Revision: 1131263
>
> URL: http://svn.apache.org/viewvc?rev=1131263&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51264
> Allow the JDBC persistent session store to use a JNDI datasource to define
> the database in which sessions are persisted.
> Patch provided by Felix Schumacher.
>
> Modified:
>tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java
>tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties
>tomcat/trunk/webapps/docs/changelog.xml
>tomcat/trunk/webapps/docs/config/manager.xml
>
> Modified: tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java?rev=1131263&r1=1131262&r2=1131263&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java Fri Jun  3
> 22:13:09 2011
> @@ -866,6 +902,24 @@ public class JDBCStore extends StoreBase
> if (dbConnection != null)
> return (dbConnection);
>
> +if (dataSourceName != null && dataSource == null) {
> +Context initCtx;
> +try {
> +initCtx = new InitialContext();
> +Context envCtx = (Context)
> initCtx.lookup("java:comp/env");
> +this.dataSource = (DataSource)
> envCtx.lookup(this.dataSourceName);
> +} catch (NamingException e) {
> +manager.getContainer().getLogger().error(
> +sm.getString(getStoreName() + ".wrongDataSource",
> +this.dataSourceName), e);
> +   }
> +}
> +
> +if (dataSource != null) {
> +dbConnection = dataSource.getConnection();
> +return dbConnection;
> +}
> +
>

1 2 3 >

1 - 100 of 239 matches

Mail list logo