Re: CVS-SVN Schedule
Henri Yandell wrote: http://svn.apache.org/repos/asf/tomcat/container/catalina/ http://svn.apache.org/repos/asf/tomcat/container/tc5/ There seems to be a problem with those two. http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/ contains what was in jakarta-tomcat-catalina, and jakarta-tomcat-5 appears to be gone. Great job anyway ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.12 Stability
Henri Gomez wrote: Should we post-pone to 5.5.13 the fixes to Jasper2 ? Yes, it seems like it. I don't even know if they are fixable at this point. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Schedule
Remy Maucherat wrote: There seems to be a problem with those two. http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/ contains what was in jakarta-tomcat-catalina, and jakarta-tomcat-5 appears to be gone. I found jakarta-tomcat-5, which is now at http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x/. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New repository org
Hi, Since the previous naming scheme has jakarta everywhere, I propose we change it to (I'll do the updating of the build scripts): http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x - build http://svn.apache.org/repos/asf/tomcat/connectors/trunk - connectors http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x - container http://svn.apache.org/repos/asf/tomcat/jasper/trunk - jasper http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x - servletapi If I misunderstood about how Subversion should be used and this is not a good way to organize things, let me know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Bill Barker wrote: A big -1 to the reorg, since then it won't be possible to checkout Trunk without also checking out all of the branches as well. I don't understand your answer. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.12 Stability
Allistair Crossley wrote: i take this back, it's only 5.5.9 that is exhibiting this behaviour, 5.5.12 fully explodes the war correctly. I don't see any relevant changes. Who knows ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Bill Barker wrote: It occurs to me that I may have misunderstood, and you were just talking about setting up the svn:externals for tomcat/current. If that's the case, then +0 (I don't really care, but I'm glad that somebody does :). svn:externals sounds like a cool feature, I guess I'll have to look it up to know what it does. Mark Thomas wrote: If by this you mean do a checkout of http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x to a directory called build in the build scripts then +1. If it involves any form of svn move -1 since I don't understand what you are planning to move to where and I have concerns about complications that might be created for checkouts, future branches and future tags. No, I don't want to do any change to the repository. The problem is that svn isn't like CVS, so someone (like me, I tried it) which would checkout http://svn.apache.org/repos/asf/tomcat would be in trouble. It would be better to organize the developer environment. Right now, it organizes things using jakarta-tomcat-5, and all the other jakarta folders. CVS was simpler ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Yoav Shapira wrote: Hi, You can also look at how Struts is organized. There, if you do: svn co http://svn.apache.org/repos/asf/struts/current struts You get all of the little bits and pieces all checked out to one place. That's pretty cool, especially when cutting out a new release. Can we get something like that done? Is it difficult to setup? The Struts trick does what I want. I see magic things in the .svn/dir-props, but obviously I don't know how to set it up properly. Adding a current magic folder doing the same would be good, and I think you can add some release/vX.Y.Z folders as well. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.12 Stability
Yoav Shapira wrote: Tomcat 5.5.12 is: [X] Stable - no major issues, It looks good enough to me. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.12 / Jasper2 - showstoppers ?
Henri Gomez wrote: Hi to all, I don't know if they should be considered showstopper but while playing with 5.5.12 for some of our new applications, I see these problems : When using Jasper2 in JSP precompilation step, it load needed taglibs jars defined in web.xml, but didn't release all of them after build (here is how it's invoked) Does this mean JARs are locked ? Another serious problem in Jasper2 precompilation is when web.xml contains external entites living in the webapp. We fixed Jasper2 in 5.5.9 to fixe this behaviour at runtime, but it appears it's also needed in precompilation step. I actually forgot what the fix was. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.12 Stability
Allistair Crossley wrote: Hi, I've tested our intranet app on 5.5.12. Our application uses the following extensively; NTLM authentication via IIS5/JK1.2 META-INF/context.xml configuration 8 JNDI datasources (mix of various SQL Server 2K databases and JavaMail) Log4J Hibernate Spring Struts CMS Seems a touch faster than usual to me but this is speculation. The only issue that was reported is lots of these: org.xml.sax.SAXParseException: URI was not reported to parser for entity [document] at gnu.xml.aelfred2.SAXDriver.warn(SAXDriver.java:934) I don't see how this is Tomcat related, at this point. These are only WARN level and do not appear to have affected the operation of the web app, however there are at least 10 of these stack traces in the logs which *may* confuse some users to think Tomcat is failing. These only occur for Spring's applicationContext file which has a DTD of !DOCTYPE beans PUBLIC -//SPRING//DTD BEAN//EN http://www.springframework.org/dtd/spring-beans.dtd; My verdict based on testing is [X] Stable - no major issues Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Releasing something
Hi, Are there plans to make any new releases, as well as launching tomcat.apache.org along with it ? Tomcat 5.5.9 was released in March, and nothing non alpha has been released since then. I don't see any voting for 5.5.12 being announced, so it's a bit worrying. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
[EMAIL PROTECTED] wrote: +/* + * Clear the IntrospectionUtils cache. + * + * Implementation note: + * Any reference to IntrospectionUtils which may cause the static + * initalizer of that class to be invoked must occur prior to setting + * the started flag to FALSE, because the static initializer of + * IntrospectionUtils makes a call to + * org.apache.commons.logging.LogFactory.getLog(), which ultimately + * calls the loadClass() method of the thread context classloader, + * which is the same as this classloader, whose impl throws a + * ThreadDeath if the started flag has been set to FALSE. + */ +IntrospectionUtils.clear(); + This commit does not make sense to me. The static initializer is called when loading the class, and obviously the webapp CL is not going to load IntrospectionUtils. You should forget that the CVS exists, as we're in the middle of migrating to SVN (of course, losing that commit will not be a problem). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Jan Luehe wrote: We have seen the ThreadDeath in our callstacks, hence this fix. Nobody is reading what I am writing anymore ... I wrote: The static initializer is called when loading the class, and obviously the webapp CL is not going to load IntrospectionUtils. IntrospectionUtils will be loaded once, and its static initializer run once. So I am ok with your fix, but I don't understand how it can occur in regular Tomcat. The big comment block is quite pointless, as it tries to be informational, but doesn't correspond to reality (I am personally against this kind of commit message duplication comment). As a reminder, CVS shound't be used anymore. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Jan Luehe wrote: No, I did. Cool, there's one, at least :) Yes, but with lazy resolution, it will be loaded when the IntrospectionUtils symbol is first encountered, which may be inside WebappClassLoader.stop(). Normally, it's used by plenty of things, like the digester. Who knows anyway, I find the classloading behavior to be weird sometimes. So I am ok with your fix, but I don't understand how it can occur in regular Tomcat. It's probably not occurring in standalone Tomcat, but only in embedded Tomcat. In standalone Tomcat, IntrospectionUtils is probably getting resolved (and its static initializer invoked) prior to calling WebappClassLoader.stop(), whereas in embedded mode, IntrospectionUtils is first referenced and loaded by WebappClassLoader.stop(). The big comment block is quite pointless, as it tries to be informational, but doesn't correspond to reality (I am personally against this kind of commit message duplication comment). Sure, I just thought this line might be an easy candidate for being moved around if there was no comment. Stuff won't get moved around for no reason ;) It would actually be good to move the 3 cleanup calls to StandardContext.stop. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Yoav Shapira wrote: Hi, Reminder that this is about 90 minutes from now ;) All done ? If so, the migration is now ready :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 5.5.12-alpha Released
Yoav Shapira wrote: This release is the last one to be done using the CVS repository at Apache. The Tomcat team is moving to the Subversion (SVN) repository as part of the overall Apache initiative to do so. Access instructions for the SVN repository are available at http://www.apache.org/dev/version-control.html. The move is expected to be complete within the next week. The plan is that the next stable release be made from tomcat.apache.org (which is ready thanks to Mark). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.xml
Mark Thomas wrote: [EMAIL PROTECTED] wrote: remm2005/09/22 03:39:37 Modified:.build.xml Log: - Fix build by excluding tagPlugins.xml. - This file shouldn't be in the standard examples, but rather copied there before precompiling (once it works again, of course). This should be unnecessary. Bill has already removed the file from SVN. Yes, I saw it after my commit, you're completely right. I'm still using the CVS repository however, and it doesn't hurt much ;) Will Yoav tag the CVS or SVN for the upcoming release ? For the record, all members of the tomcat pmc have karma for all modules including the specs. This allows us to fix issues with the examples. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Yoav Shapira wrote: Hi, I'm fine with this WE, or the end of this week. I mean, the previous build was decent already. I just looked at the changelog for 5.5.12, it's a nice collection of stuff. Is Friday OK with everyone? If not, I can do Saturday, but I'd prefer Friday to keep my weekend more free. How about Friday, September 23rd, 2005, at 9am my time (EDT), which is 1300h UTC? (http://www.timeanddate.com/worldclock/converted.html?month=9day=23year=2005hour=9min=0sec=0p1=43p2=0) That should give people a couple of days for scratching any last-minute itches. No problem with that. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: precompile failure for jsr152 examples
Tim Funk wrote: With the new tag plugins patch, precompiling the jsp examples fails. The root cause seems to be jsr152/examples/WEB-INF/tagPlugins.xml has the old classes. When I removed the file - everything compiled fine. When I updated jsr152/examples/WEB-INF/tagPlugins.xml with the tagPlugins.xml from jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/tagplugins/jstl/tagPlugins.xml I get weird compile errors: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:832: The following error occurred while executing this line: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:426: org.apache.jasper.JasperException: Unable to compile class for JSP Generated servlet error: pageContext cannot be resolved I guess at a minimum, jsr152/examples/WEB-INF/tagPlugins.xml needs fixed by removing it or fixing it with the correct classes but I think that requires someone with jsr152 karma. I didn't have time to look into the cause of Generated servlet error: pageContext cannot be resolved Thoughts? I can't fix it, I don't have karma either. I agree that the best is for now to remove the file. Worst case if nobody has karma, we can exclude the file when building. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Mark Thomas wrote: Yoav Shapira wrote: If possible, it'd be nice to establish a quiet window, say 24 hours, during which we shall not commit anything, and infra will do the real repository move. That will help eliminate the possibility of lost/clashed commits and related wasted time. Good idea. Weekends are usually quiet but it depends on the availability of infrastructure to do the migration. I'll keep the list informed of timings as they become clear. Do we do a new Tomcat 5.0.12 build (which will be voted on this time) before the migration ? We'll have to change build scripts after that, and I also would have to change the way I work with the repository, which could introduce problems. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Yoav Shapira wrote: Hi, Do we do a new Tomcat 5.0.12 build (which will be voted on this time) before the migration ? We'll have to change build scripts after that, Yes, I'd like to do a new 5.5.12. That's one of the reasons I asked for timings, once they're known, so we can work with nice margins. Alternatively, we can just cut 5.5.12 this weekend. I'm fine with this WE, or the end of this week. I mean, the previous build was decent already. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Mark Thomas wrote: All, The plan for the last phase is slightly different since these repositories are in pretty much constant use. The CVS repos that will be migrated are: jakarta-tomcat-connectors jakarta-tomcat-catalina jakarta-tomcat-5 jakarta-tomcat-jasper The plan is: - Submit migration request to infrastructure - Once the test migration has been done, I'll write a script to do the necessary restructuring - Run the script on the test repo - Announce that the test repo is ready for review - 48 hours later, assuming that there have been no objections I'll give the go ahead to infrastructure to do the live migration - Shortly after this, CVS will be locked, the live SVN migration will take place (including the restructuring script) and the migration to SVN will be complete I know there is a plan to do a JK release this week. If there is a timing clash, JK takes priority. Just shout and I'll delay giving infra the go-ahead to do the final migration. Good. The SVN structure you chose to use seems good (although it's not detailed in this email). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java
[EMAIL PROTECTED] wrote: costin 2005/09/14 23:04:01 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java Log: Support for corner case, when all tomcat is in a single jar and no fancy classloaders are used. That's nice functionality :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
William A. Rowe, Jr. wrote: Bugs [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Commits [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commit 1.153 on jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
William A. Rowe, Jr. wrote: Mladen (and everyone) ... could you please provide more descriptive commit log messages? At least, one sentence of what the commit fixes? This one wasn't too helpful, and wastes extra time reviewing commits. Very funny. It even links the bug report, the diff is 3 chars long, and even I can understand it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
William A. Rowe, Jr. wrote: Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports Right now, we have dev, user, and that's it. We need pmc too. I don't care personally about commits and issues (personally, I don't care, I have separate mail filters for the commits). I don't monitor the bugzilla noise This takes a whole new meaning for me now. as an email stream much, but want to continue to actively monitor cvs commits, and development chatter. I can see some [EMAIL PROTECTED] types who would be interested in following [EMAIL PROTECTED], but who have little to no interest in watching commits@ fly by. So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Of course, but also fewer people will care about bug reports. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36534.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36534
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-07 19:47 ---
Good point about toString(). I have a solution for that as well. Just override
org.apache.naming.resources.DirContextURLStreamHandler.toExternalForm() and have
it ignore the authority part of the URL, as follows (this is copied from
java.net.URLStreamHandler.toExternalForm(), with authority part ignored):
/**
* Converts a codeURL/code of a specific protocol to a
* codeString/code.
*
* @param u the URL.
* @return a string representation of the codeURL/code argument.
*/
protected String toExternalForm(URL u) {
// pre-compute length of StringBuffer
int len = u.getProtocol().length() + 1;
if (u.getPath() != null) {
len += u.getPath().length();
}
if (u.getQuery() != null) {
len += 1 + u.getQuery().length();
}
if (u.getRef() != null)
len += 1 + u.getRef().length();
StringBuffer result = new StringBuffer(len);
result.append(u.getProtocol());
result.append(:);
if (u.getPath() != null) {
result.append(u.getPath());
}
if (u.getQuery() != null) {
result.append('?');
result.append(u.getQuery());
}
if (u.getRef() != null) {
result.append(#);
result.append(u.getRef());
}
return result.toString();
}
It is important that URLs returned by ServletContext.getResource() that are
equal have equals() return TRUE. This works for all other kinds of URLs.
I hadn't noticed you were the one who filed the bug. Besides skipping
the result.append(:);, you should simply apply the fix, it's a very
good solution.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 23:43 --- I strongly agree with Craig, et al to error on the side of a more robust implemention by using synchronization on the side of Tomcat. I think doing otherwise would be doing a high-wire act without a net. There are too many places for a developer to miss handling the threading correctly to leave this as is. Somehow, I cannot access bugzilla right now. DNS failure or something. Can someone close this as invalid and end this pointless debate ? Otherwise, I'll do it first thing when I have access :) Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 21:29 --- After we finish clarifying who's is bigger (and mine is best case average), we could return to the bug. 1. The bug isn't invalid, so I reopen it. You can set it to WONTFIX, but not to INVALID. Indeed, WONTFIX looks to me like a reasonable resolution. 2. Applications working well with tomcat 4, resin or probably any other servlet container do not work with tomcat 5.0.x or tomcat 5.5.x. Thus tomcat 5 seems to be not compatible to the servlet spec (or be the only one compatible), if not in the language of the specification itself, but in the intension of it. So tomcat 5 can be considered BROKEN. Fine with me. 3. The bug applies to tomcat 5.5.x as well, because ... added back synchrnozation on write operations to the map in the 5.5 branch... doesn't fix anything, since the read operation are the problem and MUST be synchronized. Well, actually, I think you should bring that up with Sun, which have made a questionable/unsafe implementation of the collection IMO. A reasonable fix I would consider, however (showing I am not saying no to your bug report just for fun), is using another collection implementation, or tweaking that one, whatever works. After all, all that is missing is something like an e != e.next in HashMap.get. But of course, we're the OSS project, so we're always the ones being bugged to death, rather than proprietary software vendors :( Synchronizing the writes will also fix problems, since I think the underlying structure of the hashmap went bad due to a concurrency of reads. Try it before whining. Thanks. 5. The idea of removing synchronization to gain performance is absurd. Who needs the performance? People like us, who have 2000-3000 concurrent users on each webserver. But people who have 2000-3000 concurrent users, have also many concurrent requests, even from the same user, so instead of gaining performance we are gaining CRASHES. This bug killed 8 (!!!) webservers yesterday. I have extremely few problems with this. 6. Consider the flurry in the tomcat users community, if the above points + your refusal to provide a three LOCs fix gonna make tomcat 5 UNUSEABLE. Funny. The only flurry is the one you have created, and that I will have to ignore. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: I'm not even sure if I've been bitten by this either, but I have seen on the list numerous people speaking of running out of Tomcat threads and setting their connections to the max. If this issue were causing problems they might be having it and not even realize it. It's trivial to see using a thraed dump. Please, don't try lame FUD. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Mark Thomas wrote: Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Not in the 5.0.x build he's using. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 01:08 --- I wonder if the new java.util.concurrent classes could be used instead of simple HashMap? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html but that would mean total dependence on j2se 1.5 and that would be a problem for supporting j2se 1.4, though a backport is being worked on here http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/ other reading here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html I think that sort of thing would provide a nice solution for speed + reliability. Using this as the underlaying base would/should fix issues with EL access too. This would be a bad solution, because there are too many writes in many cases. From what I see, the regular HashMap.get will return null without further trouble (since that is all that is needed) as long as no resize occurs. This makes the problem fixable by creating a non resizable HashMap. Another possibility, which I consider very likely, is that concurrent resizes are the only problem, and in that case syncing only on writes is already enough. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Mark Thomas wrote: Remy Maucherat wrote: Indeed. But do we need to sync the reads in 5.5.x as well or is it enough just to do the writes? I am confused as you said concurrent reads were the issue but syncing the writes would fix it. No, concurrent reads are not the issue. The problem is that when the HashMap structure is corrupted by concurrent writes (either a put causing a resize, or a remove), then any read might loop. I believe as long as the HashMap structure remains consistent, all the next fields for the entries (which is the problematic field) will have a correct value at the end of the resize/remove, so an infinite loop on get is then not possible. What this issue tells me, also, is that using the default size for the attributes HashMap may be inappropriate (it is best to avoid resizes, and the question is how much they happen - if at all, maybe it is remove which is most often used). Sorry if I am being dense here ;) No problem :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
Jan Luehe wrote:
Remy Maucherat wrote:
I hadn't noticed you were the one who filed the bug. Besides skipping
the result.append(:);
Not sure I understand: the : following the protocol is necessary,
so that the printable representation of the context generated URLs
starts with jndi:.
Right, it's not related to the port number. Doh.
you should simply apply the fix, it's a very
good solution.
I'm still having problems with CVS, which are preventing me from
committing my fix.
If you can commit this on my behalf, I'd appreciate it.
The complete fix consists of the above diff and the following patch
in org.apache.catalina.core.ApplicationContext:
try {
resources.lookup(path);
return new URL
-(jndi, null, 0, getJNDIUri(hostName, fullPath),
- new DirContextURLStreamHandler(resources));
+(jndi, , 0, getJNDIUri(hostName, fullPath),
+ new DirContextURLStreamHandler(resources));
} catch (Exception e) {
// Ignore
}
Ok.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Servlet and JSP APIs have moved to subversion
Mark Thomas wrote: The following CVS modules have been migrated to subversion jakarta-servletapi jakarta-servletapi-4 jakarta-servletapi-5 These modules are now read only in CVS. The new SVN locations are: http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.2-jsp1.1-tc3.x/ http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/ http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/ NB Committers wishing to make changes to these modules will need to use https as per http://www.apache.org/dev/version-control.html#https-svn TC34 will move next (phase 4), followed by TC5, Connectors and Jasper2 (phase 5). A more detailed schedule, particularly for phase 5 since this is the focus of development, will be posted on the tomcat-dev list nearer the time. It seems to work well ! What's the next step ? I looked into the website work, and I think it should be enough to simply add a page for mailing lists and downloads (for starters, other pages can be added as needed). For the latter, what are the preferences ? One like jakarta.apache.org, or a much simpler one like httpd.apache.org ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Servlet and JSP APIs have moved to subversion
Allistair Crossley wrote: Hi Remy, I've been thinking about the Tomcat online documentation for quite a long time now, and have wanted to do something to enhance them for the community. I think I am going to be able to get back to doing this shortly. I've been looking at how other open-source projects that I consider to be very well documented approach documentation, and was most impressed with Christian Bauer's use of DocBook for Hibernate's HTML and PDF documentation. DocBook is a schema for defining books and one uses XSL to translate to HTML or PDF renditions. I've set this up on my PC and have purchased a decent XML editor for the task, but I'm keen to learn whether you would consider even approaching the documentation differently. Ok, feel free to experiment. The main drawback is that the DTD is more complicated. Besides that, it would produce better results. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Yoav Shapira wrote: Yup. 5.5.11 should be a good step in that direction: I'll download and play around with it, but I think the changelog looks great in that it's mostly fixes to known issues, nothing crazy, and therefore should make a good build. I also think 5.5.11 looks good (assuming people did test it; please test it, I fixed all the bad APR bugs in 5.5.10 that I was aware of, and the Windows installer also installs an APR/OpenSSL binary is the native option is checked), but the stable build should have the tomcat.apache.org branding. How about doing that this week and then releasing a 5.5.12 build ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r264883 - /tomcat/site/branches/pre-tlp/
[EMAIL PROTECTED] wrote: Author: markt Date: Tue Aug 30 15:38:30 2005 New Revision: 264883 URL: http://svn.apache.org/viewcvs?rev=264883view=rev Log: Development of the tomcat.apache.org site will take place in ../tomcat/site/trunk Add a download page (like this one, maybe: http://httpd.apache.org/download.cgi), end of story ? Or are there plans for something more ambitious ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site repository cleanup
Mark Thomas wrote: Any objections to deleting the following? http://svn.apache.org/repos/asf/tomcat/site/branches/TOMCAT_5_0/ http://svn.apache.org/repos/asf/tomcat/site/branches/tomcat-site/ http://svn.apache.org/repos/asf/tomcat/site/tags/start/ http://svn.apache.org/repos/asf/tomcat/site/tags/PRE-ANAKIA-REMOVAL/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_0_26/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_0_27/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_10/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_2/ http://svn.apache.org/repos/asf/tomcat/site/tags/TOMCAT_5_5_8/ I don't see what purpose any of the above might serve. I know copies are cheap. My primary concern isn't space (and deleting things doesn't save space anyway) but making our repository easy for newcomers to navigate. We can get these back easily if we find we need them later. Ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Mark Thomas wrote: I think the spec team get to decide this. I had assumed they would do something similar to the servletapi-5 and have jsr154 and jsr245 directories under the root directory (which in svn would be \tomcat\servletapi\trunk - the current trunk having been moved to \tomcat\servletapi\branches\tc5.x.x\). I don't know if the spec team is actually still responsible for these repositories, such as if they intend to add the Servlet 2.5 / JSP 2.1 API source there. If the don't, we can switch to a more OSS friendly access and management style. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Mark Thomas wrote: Remy Maucherat wrote: Mark Thomas wrote: I think the spec team get to decide this. I had assumed they would do something similar to the servletapi-5 and have jsr154 and jsr245 directories under the root directory (which in svn would be \tomcat\servletapi\trunk - the current trunk having been moved to \tomcat\servletapi\branches\tc5.x.x\). I don't know if the spec team is actually still responsible for these repositories, such as if they intend to add the Servlet 2.5 / JSP 2.1 API source there. If the don't, we can switch to a more OSS friendly access and management style. Who do we need to talk at the spec team about this? At least Jan would know, and he seems to be reading the list. Maybe they haven't quite decided what to do. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Yoav Shapira wrote: Hi, You know, come to think of it, who's on the Spec team for 2.5? I don't even see a formal JSR for it, only the preliminary changelog URL Remy originally posted, which is hanging off the JSR 154 / Servlet Spec 2.4 site. I am now on the expert group, and it's only a maintenance release (so no new JSR). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Yoav Shapira wrote: Hola, I'm virtually back from vacation ;) Still traveling, but now for business, and therefore lugging my laptop along. Thank you for the inquiry ;) --- Ashly Mathew Varghese [EMAIL PROTECTED] wrote: Just out of context.. What happened to Yoav? - Migrate to tomcat.apache.org. IIRC, we were going to do that after the SVN migration. Mark is doing a great job with the SVN task, with Henri and infra's help. I'd estimate no more than another month to complete the SVN migration, right? The SVN migration for site should now be in progress. - Release a new stable 5.5.x. Yup. 5.5.11 should be a good step in that direction: I'll download and play around with it, but I think the changelog looks great in that it's mostly fixes to known issues, nothing crazy, and therefore should make a good build. - Implement Servlet API 2.5: http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/servlet-2_5-changelog.html There are few changes, except support for some annotations (which are optional, but as Tomcat supports all web related optional J2EE features ...). The result would be very similar with Tomcat 5.5, with the possibility of Java 5 related code cleanups (Servlet API 2.5 mandates Java 5). Yes. I have to say I'm happy with the current Servlet 2.5 draft: from our perspective, it's not much serious new work, we can remove a couple of annoying special case paths through the code, and we get to dismiss the compat package. We may want to continue making 5.5 releases for a little while after Tomcat 6.0 is out, as I expect a bunch of users will still using JDK 1.4. Side note on this: the name for the CVS (or actually, SVN) area for Servlet API 2.5. I'd prefer servletapi-2.5 for clarity, even though it breaks the pattern of jakarta-servletapi and then jakarta-servletapi-5 that we have used to date. I agree, it's a very good idea. - Implement JSP 2.1: it's a significant effort, and the issue is that there doesn't seem to be anyone available. Any ideas ? The biggest unaddressed issue on the table at the moment, I agree. I need to look through the spec draft myself. Are the gurus (kin-man, etc.) not around and not available to help out? No idea, but it seems not. MyFaces is going to need the new EL as well. Also, similar side note on CVS/SVN location: perhaps we put it in jspapi-2.1 instead of servletapi-6? Right. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Yoav Shapira wrote: Howdy, I am now on the expert group, and it's only a maintenance release (so no new JSR). Ah, good. That's a good point of synergy for us. So it's a new maintenance release, no new JSR, but it will be called Servlet Specification v2.5? And accordingly, Tomcat 6.0... Pretty much. There's JSP 2.1 which is more significant, and given my level of expertise in JSP, it's a problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Henri Yandell wrote: On 8/17/05, Mark Thomas [EMAIL PROTECTED] wrote: 2. j-t-service, j-t-site, j-t-tools Ready to do phase-2? Where should they go in svn:tomcat/? Which need tags/branches? So it would be tomcat/service, tomcat/site, tomcat/tools, etc ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Upcoming work
There are quite a few tasks ahead: - Migrate to tomcat.apache.org. - Release a new stable 5.5.x. - New SVN repositories. - Implement Servlet API 2.5: http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/servlet-2_5-changelog.html There are few changes, except support for some annotations (which are optional, but as Tomcat supports all web related optional J2EE features ...). The result would be very similar with Tomcat 5.5, with the possibility of Java 5 related code cleanups (Servlet API 2.5 mandates Java 5). - Implement JSP 2.1: it's a significant effort, and the issue is that there doesn't seem to be anyone available. Any ideas ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upcoming work
Ashly Mathew Varghese wrote: Just out of context.. What happened to Yoav? He's on vacation. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging infinite loop w/5.5.9
Nathan Bubna wrote: hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example applications to use an adapter between commons-logging and Velocity's LogSystem. this way, those of our tools which require logging are able to send messages to commons-logging and they get passed of to the LogSystem that the rest of Velocity is using (without having to pass that LogSystem around). We also, by default, configure our VelocityViewServlet (the core class of VelocityTools) to automatically send LogSystem messages to the servlet log. so, messages sent to c-l are sent the the Velocity LogSystem which sends the messages to the servlet log. this works just dandy for everyone in Tomcat 5.0.x, but when we deploy our very minimal example applications in Tomcat 5.5.9, we promptly receive stack overflows and out of memory errors that appear to be a nasty little commons-logging loop. can somebody help me figure out what change between 5.0 and 5.5 is causing this? and further, what can be done about it? i'm still not even sure whether to consider this a bug in our design or in Tomcat. any help would be much appreciated! In Tomcat 5.5, everything is logged to commons-logging, so the loop you get is to be expected. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat v5.5.11-alpha Released
The Apache Tomcat team is proud to announce the immediate availability of Apache Tomcat 5.5.11-alpha, which includes bugfixes over Apache Tomcat 5.5.10-alpha. The Release notes are available at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES Please refer to the change log for the list of changes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Temp RM
Remy Maucherat wrote: Hi, Yoav has granted me temp RM powers while he's away on vacation. I plan to use them and release a new 5.5.11 test build early next week (let's say monday) for further testing of the new features introduced in 5.5.10, which unfortunately had serious bugs which should have been addressed. I don't think this new test build will be the subject of a stability vote given that too many key people may be out of reach until september. Any problems with this plan ? I still plan to put out a new 5.5.11 test build today, as described above. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Mark Thomas wrote: Not having been around when we have done this before, do we just branch the previous version? If so, the simplest thing to do would be to create 5.5.x branches for each component and develop 6.0 (assuming we call it that) in trunk. I can do this as soon as we are ready. Yes, it has to be called 6.0 because of the new specifications release. Given the said specification schedule, I don't see anything new being included (besides code cleanup thanks to the mandated Java 5 support) unless components get donated or something. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tag plugin
wing lee wrote:
I've tried the generateBody method, but it just generate such code
write.out(body content), don't return the value of the body content.
That's odd: it's supposed to continue evaluation and code generation for
the body, not consider nested stuff as static text. There's a good
example with the if tag plugin (although, as I said, I didn't test it
at all, so maybe it's broken).
public final class If implements TagPlugin {
public void doTag(TagPluginContext ctxt) {
String condV = ctxt.getTemporaryVariableName();
ctxt.generateJavaSource(boolean + condV + =);
ctxt.generateAttribute(test);
ctxt.generateJavaSource(;);
if (ctxt.isAttributeSpecified(var)) {
String scope = PageContext.PAGE_SCOPE;
if (ctxt.isAttributeSpecified(scope)) {
String scopeStr = ctxt.getConstantAttribute(scope);
if (request.equals(scopeStr)) {
scope = PageContext.REQUEST_SCOPE;
} else if (session.equals(scopeStr)) {
scope = PageContext.SESSION_SCOPE;
} else if (application.equals(scopeStr)) {
scope = PageContext.APPLICATION_SCOPE;
}
}
ctxt.generateJavaSource(_jspx_page_context.setAttribute();
ctxt.generateAttribute(var);
ctxt.generateJavaSource(, new Boolean( + condV + ), + scope +
););
}
ctxt.generateJavaSource(if ( + condV + ){);
ctxt.generateBody();
ctxt.generateJavaSource(});
}
}
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Temp RM
Hi, Yoav has granted me temp RM powers while he's away on vacation. I plan to use them and release a new 5.5.11 test build early next week (let's say monday) for further testing of the new features introduced in 5.5.10, which unfortunately had serious bugs which should have been addressed. I don't think this new test build will be the subject of a stability vote given that too many key people may be out of reach until september. Any problems with this plan ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration update
Mark Thomas wrote: Mark Thomas wrote: snip The performance comparison between CVS and SVN is in the early stages and I will post some results once I have a more complete set. Tests performed on WinXP SP2, with Tortoise CVS 1.8.18 and Tortoise SVN 1.2.1 using the Watchdog repository. For tests using a single file I used build.xml. The results are (averages in seconds): Operation CVS SVN checkout 38 51 history 45 blame 47 diff42 revert 71 Also, SVN does not support revision graphs. Some tools can derive the graph but for the ASF repository this will take hours, possibly days. See http://subversion.tigris.org/ for a list of other SVN benefits. I am +1 for moving the remaining Tomcat CVS modules to SVN. I'm +10^-60 or something. Assuming everyone else is happy to move the remaining tomcat modules to SVN I would suggest the following stages (Watchdog was stage 1). I'll give people at least a week to comment on this proposal and assuming no -1's start the phase 2 towards the end of next week. 2. j-t-service, j-t-site 3. j-servletapi, j-servletapi-4, j-servletapi-5 4. j-tomcat, j-tomcat-4.0 5. j-t-catalina, j-t-5, j-t-jasper, j-t-connectors Do we need an OK from the spec team before we do stage 3? I don't think so, we're not changing the code. Any other comments/concerns? Right after that, we'll need new repositories to implement the new Servlet 2.5 / JSP 2.1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tag plugin
wing lee wrote: Hi all, I'm working on the JSTL tag plugin for jasper. I don't fin any method in the interface TagPluginContext to get the body content of the tag. But I have to use it. Anyone can help me? Isn't that supposed to be TagPluginContext.generateBody ? I didn't try it, though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vacation
Hi, I'll be away until the 16th. Later ! Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java
[EMAIL PROTECTED] wrote:
billbarker2005/08/03 23:07:46
Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
Log:
Fix CNFE when starting in a sandbox.
After the last refactoring, the Jk-Java Connector no longer has need of PAs. If this changes, the method can always be added back.
This reminds me I need to test security more often.
I look in the preload list for HTTP, and I see a few PAs there. One of
them is:
// End the response status line
if (System.getSecurityManager() != null){
AccessController.doPrivileged(
new PrivilegedAction(){
public Object run(){
buf[pos++] = Constants.CR;
buf[pos++] = Constants.LF;
return null;
}
}
);
} else {
buf[pos++] = Constants.CR;
buf[pos++] = Constants.LF;
}
I think this is fairly funny code. The contents of the PA were a bit
different originally, but I don't see why a PA was ever needed.
Similarly, the other PA is needed because the HttpMessages is a bundle
which will need to be loaded, while the loading should be done during
the init of the connector (like HttpMessages.getMessage(200)).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error? bug?
Oto Bossert wrote: Yoo, Currently we are running tomcat 5.5.9 on Debian Sarge, with Java JDK 1.5.0.04 http://1.5.0.04, together with apache, apache-common 1.3.33-6 support files for all Apache webservers apache2 2.0.54-4 next generation, scalable, extendable web se apache2-common 2.0.54-4 next generation, scalable, extendable web se apache2-mpm-pr 2.0.54-4 traditional model for Apache2 apache2-utils 2.0.54-4 utility programs for webservers libapache-mod- 4.3.10-15 server-side, HTML-embedded scripting languag libapache2-mod 4.3.9-2 Apache 2 module for MySQL authentication libapache2-mod 2.0.4-3 Apache 2.0 connector for the Tomcat Java ser libapache2-mod 4.3.10-15 server-side, HTML-embedded scripting languag libapache2-mod 0.5.2-3 Apache2 module to run php scripts with the o Unfortunatly tomcat does not respond on monitor check any/every day between 06:26:00 and 06:27:00. message : [CEST Aug 4 06:26:30] 'tomcat' failed, cannot open a connection to INET[pzzl04.pzzl.com:80/manager http://pzzl04.pzzl.com:80/manager] first message from catalina.out log [Aug 4, 2005 6:26:31 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080] Now our monitoring system, notices the stop and restarts tomcat, but this is not acceptable in the long run Also restarting tomcat at any moment in the day does not change the time it goes down Any suggestions? It should be quite obvious: edit the file from where the log is coming, add a trace dump there, and recompile the said class. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 InternalAprOutputBuffer.java Http11AprProcessor.java
Bill Barker wrote: It looks like you did the same thing I did with JK: Remove the useless PAs, and then don't bother to test on a clean build (so that SecurityClassLoad can still find the removed classes and doesn't complain). If you don't want BZ 35894 re-opened, you also need to remove the reference to the removed PAs in SecurityClassLoad ;-). I made the changes only to the APR versions, so it looks ok to me. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standart Sessions included in the SSO Session expire
Dominik Drzewiecki wrote: I have a conceptual question wrt the Single Sign On behaviour. Let's assume there are two applications /app1 and /app2, and there is a SSO setup on them both. Now, user logs into the /app1 (which requires authentication) and /app2 (which uses SSO Cookie, no authentication then), and later on makes use of only one of them (say: /app1) for quite a long time, so that this period outlives the session expiry date of the unused application (/app2). Provided that both applications establish their own sessions the one created in the scope of constantly used application (/app1) wouldn't expire, while the second one definitely would. Now the question: As both sessions are gathered into a higher-level SSO session, would it be against the specification if *all* standard sessions were aged (eg. by calling session.access()) on each request containing valid SSO cookie? I suggest that there should be a flag on the SSO Valve, that is org.apache.catalina.authenticator.SingleSignOn allowing users to specify the behaviour. If nobody objects, I could try to provide apropriate patch. The purpose of single sign on is to deal with authentication issues, not modify session lifecycle. Overall, you really need to design your web applications as if they were independent. Of course, it is fine to implement your own custom behavior should you need it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing MemoryUserDatabase on Startup
Rainer Jung wrote:
Hi,
I wonder, why
/org/apache/catalina/users/MemoryUserDatabaseFactory.java
saves the MemoryUserDatabase directly after opening it:
public Object getObjectInstance(Object obj, Name name, Context
nameCtx, Hashtable environment) throws Exception {
...
// Return the configured database instance
database.open();
database.save();
return (database);
}
That means, the runtime user of tomcat needs write permissions on the
directory, the file is in (see the implementation of
MemoryUserDatabase.save()).
Ogf course in case one likes to administer the user database the save
function is necessary. But there are two cases where one would prefer to
have tomcat not trying to save the database during startup:
1) Running tomcat from CD
2) Having a very secure setup of tomcat, where all the configs are write
disabled.
The call to database.save() is in the code since the very first version
in TC 4, but I can't really see, why it is necessary.
Another possibility would be to catch the Exception thrown when there is
no write permission and to simply log a warning.
Also: there is a save() done in close(). I don't know, where the close
is called from, but it looks like nowhere in catalina code (eventually
in admin).
Any comments? Thanks!
The problem is (mostly) the save in close: the database can't know for
sure if its stuff was updated so it always saves.
I understand the need for 1), which can be achieved with the other
equivalent-but-not-management-friendly memory realm. 2) seems unlikely IMO.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: yoavs 2005/08/02 11:12:06 Modified:.tomcat.nsi webapps/docs changelog.xml Log: Bugzilla 33261: http://issues.apache.org/bugzilla/show_bug.cgi?id=33261 Can you fix the EOLs ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing MemoryUserDatabase on Startup
Rainer Jung wrote: Hi Remy, so would it be OK, if I produce a patch, that cares about the Exception and logs a message instead? I could make that configurable if you think there is too much danger for a user to loose changes because he was able to start tomcat and didn't notice the database was not writable. I will propose a patch later that week and you can have a look at it. Catching and logging a warning would be good, I think. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav Shapira wrote: Hey, Done. Thanks for catching that, Yoav PS -- Is the 1.1.0 native coming any time soon? The build is broken since build.xml and build.properties.default were updated, but archive.apache.org/dist/[jtc]/native does not exist... Syncing takes a lot of time with the new architecture, sorry. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: El jue, 28-07-2005 a las 01:09 +0200, Remy Maucherat escribió: Mauricio Nuñez wrote: Apparently , my report was useful! :-) The issue turned out to be really basic. Any other problems besides that ? Rémy Thanks. I'm begining to recompile the CVS connector to try. Now I'm fighting with the jakarta jar hell :-) . There's no hell involved ... There's one source file involved (actually, only one line). What you need to do is javac that one class (which only depends only on JARs which are in the Tomcat bundle in server/lib: tomcat-apr, tomcat-util, tomcat-coyote, tomcat-ajp). Even getting the full thing is easy as long as you know Ant (ant download; ant). Now I'm testing the NIO connector. After the compilation, I'will send you my results. Well, for the log, the test case about the APR AJP loosing data is to configure apache2 + mod_jk + Tomcat woth Apr AJP13 socket, and try any page with size 8192. Tested with Linux Centos 4, Sun JDK 1.5.0_03. I noticed that after trying random stuff. While it's good to send details, it's less useful to send them after the bug has been fixed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.10 cluster exception
Dennis wrote: I'm working with the cvs tagged 5.5.10 version of tomcat to check out some clustering fixes. When I bring a 2nd server into the pool, I get this exception repeated every time an mcast packet is received: ==CUT== java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source) at org.apache.catalina.cluster.mcast.McastMember.getMember(McastMember.java:181) at org.apache.catalina.cluster.mcast.McastServiceImpl.receive(McastServiceImpl.java:209) at org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(McastServiceImpl.java:253) ==END CUT== Here are the relevant lines of code from McastMember.java: ==CUT== byte[] domaind = new byte[dlen]; System.arraycopy(data, nlen + 24, domaind, 0, domaind.length); ==END CUT== I added some debugging to figure out the length of the data. The exception occurs because data.length is 23. Obviously 23+24 is going to throw an ArrayIndexOBE. My question is.. is there a configuration thing that is causing data to be sent to be less than the desired length? It appears the data is not coming in in the format expected. Thoughts? Your post is OT on this mailing list, but I thought I would play a little with the clustering. This works for me, with this config: Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=true notifyListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=500 mcastClusterDomain=dev mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=auto tcpListenPort=4002 tcpSelectorTimeout=100 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ ClusterListener className=org.apache.catalina.cluster.session.ClusterSessionListener/ /Cluster The domain feature for membership is new in this release (which caused the data packets sent to change). I recommend trying tomcat-user, or filing a bug if you can give working instructions on how to reproduce the problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: El jue, 28-07-2005 a las 14:25 +0200, Remy Maucherat escribió: OK. But may be more easy, It's not very out of the box . Since the out of the box version has a bug, the out of the box experience is going to suck, there's nothing I can do about it. I noticed that after trying random stuff. While it's good to send details, it's less useful to send them after the bug has been fixed. OK. The test case is for the list archive, not only for you. The smart people search the archives before send a bug. Ok. I'm testing your change, all is working again. 65 ajp workers on machine 1, 95 ajp workers on machine 2. The heap usage grow smoothly. My sample is about 20 min. What kind of data may be relevant for you ? That it's working is pretty good already, but you should mention your OS. I built the AJP APR implementation using lots of cut paste of the existing AJP code, and for the most part, just to have it, as I don't expect major benefits (except in one special case where the amount of request processors on the front end is huge compared to the amount of request processors that can realistically be used on the back end - often it's the other way around, so there's no problem). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: Hi developers! Well, I was testing the experimental APR AJP connector, with 2 web pages at my site. Using Tomcat 5.5.10 Both pages are loosing 16368 bytes. Bad luck. Hopefully it's just irrelevant data ;) I'm attaching the pages. Using kompare under linux , you can check clearly where is the diff. And that will help me a lot, thanks. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: Well, the files are equals for the first 8112 - 8185 bytes, aprox . May be 8192 (2 ^ 13), but the lines pre y post data loss are too similarly :-) I was being sarcastic ;) Your report is not a test case I can use, so I can't do much. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat build failed
Xingbo Gao wrote: Hi, I follow the steps listed in http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html, and try to build the tomcat source codes. I was able to build successfully before, but now get the errors below each time. It seems the link http://umn.dl.sourceforge.net doesn't work any more. setproxy: testexist: [echo] Testing for /usr/share/java/mx4j-3.0.1/lib/mx4j.jar downloadgz: [get] Getting: http://umn.dl.sourceforge.net/sourceforge/mx4j/mx4j-3.0.1.tar.gz [get] To: /usr/share/java/file.tar.gz [get] Error getting http://umn.dl.sourceforge.net/sourceforge/mx4j/mx4j-3.0.1.tar.gz to /usr/share/java/file.tar.gz BUILD FAILED /home/xbgao/tomcat/build.xml:49: The following error occurred while executing this line: /home/xbgao/tomcat/jakarta-tomcat-5/build.xml:1834: The following error occurred while executing this line: /home/xbgao/tomcat/jakarta-tomcat-5/build.xml:1928: java.net.ConnectException: Connection refused Maybe the sourceforge mirror is gone or something. There's a list to choose from in the default build.properties (I just updated it). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat build failed
Xingbo Gao wrote: Remy, Where can I find the default build.properties file? It's build.properties.default in jakarta-tomcat-5. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: Apparently , my report was useful! :-) The issue turned out to be really basic. Any other problems besides that ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Remy Maucherat wrote:
Scott Marlow wrote:
Anyway, my point is that this could be a worthwhile enhancement for
applications that run on Tomcat. What I don't understand yet is whether
the same functionality is already in Tomcat.
I should point out that some applications shouldn't limit the max number
of concurrent requests (long running requests won't benefit but maybe
those applications shouldn't run on the web tier anyway :-)
I agree with the intent, but this is not implemented properly. I think
the idea is to restrict concurrency in the application layer, rather at
the low level (where, AFIK, concurrency isn't that expensive, and is
better addressed using a little non blocking IO). The performance
benefits for certain types of applications will be the same, but without
introducing any unwanted limitations or incorrect behavior at the
connector level.
I think you should write a ConcurrencyValve instead, which would do
something like:
boolean shouldRelease = false;
try {
concurrencySemaphore.acquire();
shouldRelease = true;
getNext().invoke(request, response);
} finally {
if (shouldRelease)
concurrencySemaphore.release();
}
As it is a valve, you can set it globally, on a host, or on an
individual webapp, allowing to control concurrency in a fine grained
way. In theory, you can also add it on individual servlets, but it
requires some hacking. Since it's optional and independent, I think it
is acceptable to use Java 5 for it.
As you pointed out, some applications may run horribly with this (slow
upload is the most glaring example).
It took forever (given it's only 10 lines of code), but I added the
valve. The class is org.apache.cataline.valves.SemaphoreValve.
So you can add it at the engine level to add a concurrency constraint
for the whole servlet engine, without constraining the connector (which
might not be low thread count friendly).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat API doc, where?
Yoav Shapira wrote: Hi, This is actually a bit more interesting than I thought ;) jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSE15SocketF actory.java breaks the JDK 1.4 javadoc (lines 33 and 62 have fatal JavaDoc errors). Since we build with JDK 1.4, the Catalina API JavaDocs weren't generated. I've recorded this in Bugzilla as 35880, http://issues.apache.org/bugzilla/show_bug.cgi?id=35880. The question is what's the best fix. Should we exclude that file (or that whole package) from the JavaDoc target? I don't see any choice other than to filter out any Java 5 code at the moment. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag ?
Jason Brittain wrote: On 7/23/05, Mark Thomas [EMAIL PROTECTED] wrote: I have been doing some quick tests and my totally unscientific, statistically invalid results are that cvs annotate seems to be about 7 to 8 times faster than svn blame (50s compared with 7s) and cvs log seems to be about 2 to 3 times faster than svn log (16s compared to 7s). I've heard the subversion developers remind people that there are at least a few different network protocols for accessing svn. In the http:// case, it will be the slowest. IIRC they say using the svn:// protocol is the fastest. It looks as if the Apache svn installation does not support svn:// URLs. The page that shows the URLs doesn't mention it: http://jakarta.apache.org/site/cvsindex.html#Subversion And when I try to connect to the svn port (tcp 3690) I get a connection refused. So, maybe the infrastructure people could set up a svnserve server as well as serving these repositories through Apache httpd? http://svnbook.red-bean.com/en/1.1/ch06s03.html I use svn and I'm looking forward to having Tomcat hosted in it. Remy: isn't svn blame what you're looking for? I have looked a little at the command line tool now. It's actually more like the regular svn log. It looks like the thing missing is good UI support. It indeed seems a bit sluggish overall, but it's very usable :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 5.5.10...
Yoav Shapira wrote: … right now. The build will be uploaded to minotaur for mirroring in about 90 minutes. Cool. For the next build, Mladen will add a new source bundle for the APR JNI wrapper library, and there should also be some real documentation. I think it should end up in the bin folder of the distribution, like the jsvc.tar.gz archive (similarly, it will include a ready to run configure). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.10 tag time and tester failures
Yoav Shapira wrote: Hi, When should we tag and cut 5.5.10? I originally proposed tomorrow (Saturday) and that seems to be OK with everyone. So unless I hear back, let’s do it tomorrow at 2pm my time (EDT), which is 1800h UTC: http://www.timeanddate.com/worldclock/converted.html?month=7day=23year=2005hour=14min=0sec=0p1=43p2=0 http://www.timeanddate.com/worldclock/converted.html?month=7day=23year=2005hour=14min=0sec=0p1=43p2=0. I tested the build and release, they work fine with the latest CVS HEAD, with the exception of two strange tester failure. One is on the very first tester test, for /index.jsp, and while I don’t know why it fails, I don’t think it’s a big deal because virtually all the other tests pass. The other failure is more intriguing: it’s the 4^th session test, and I also don’t know why it fails, but it’s worth looking into I think. Session failures could be related to the IAE that is thrown for getId if the session is invalid. This could break a lot of stuff. Usually, failure at session tests means serious problems, however, and these two failures seem suspicious. The first test on index.jsp works for me. What do you get ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.10 tag time and tester failures
Remy Maucherat wrote: Session failures could be related to the IAE that is thrown for getId if the session is invalid. This could break a lot of stuff. Usually, failure at session tests means serious problems, however, and these two failures seem suspicious. I confirm the two failures are indeed caused by a listener using getId and calling invalidate on the session, so the tests are now invalid (the listeners should be careful when using getId). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support JSS in Tomcat
Christine Ho wrote: Thanks. It works. JSS can be used under either Mozilla Public License (MPL) or LGPL. Is MPL or LGPL compatible with ASF license? The good thing about JSS is that it is FIPS-140 compliant. First, the Tomcat portion of the code needs to be donated to the ASF. The code cannot import LGPL packages, but I don't know about MPL (I'd say it's ok). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag ?
Peter Rossbach wrote: Yes, I also think we can build a 5.5.10 release with all the new stuff. The new cluster redesign version is yet only tested under small load. Better I commit my new jkstatus task after my three week holiday for next release (5.5.11). Sounds good. I have add a new lib (catalina-jmx-ant.jar) for jmx ant tasks to server/lib and two ant scripts include at bin, but I have not test the release included this things also. It should be included, no problem (it uses patterns like server/**, and the installer uses server/lib). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag ?
Yoav Shapira wrote: Hi, I'm OK with cutting 5.5.10 tomorrow or Saturday. If that's too early, let's pick a different time. I don't have further code changes to add in this build, it seems. After 5.5.10, I want to talk about SVN migration again ;) I'm aware of the lack of satisfaction among the CVS GUI users, but infra is cutting off CVS on January 1st, and for me personally, August seems like a great time to do the transition since it's traditionally a low-activity period. It's not really a UI thing for me. One feature I use often are revision lists for a particular file, to be able to tell where a bug has been introduced (I then do diffs between revisions). It seems with SVN I have to retrieve the full revision list for the repository (which will take hours). If someone can offer a workaround for this problem, then I'll support a move to SVN :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New tag ?
Hi, I think the APR capabilities that we added are now sufficiently stable to warrant testing. If the other areas that saw changes recently (clustering, JK) are ok too, then it could be a good idea to release a new build. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag ?
Bill Barker wrote: Hi, I think the APR capabilities that we added are now sufficiently stable to warrant testing. If the other areas that saw changes recently (clustering, JK) are ok too, then it could be a good idea to release a new build. JK should be fine. I've been pretty careful with the changes. I was referring to the NIO channel which is marked as experimental in the changelog. It would be nice to fix BZ 35696 (since it's a spec issue). I'll see if I can get some time to look at it. Ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
William A. Rowe, Jr. wrote: At 01:25 PM 7/11/2005, you wrote: William A. Rowe, Jr. wrote: It's important for students involved with SoC to learn to use the tools of our organization; I don't agree with you. The Tomcat is not place for some 'sandbox' projects. If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. The ASF didn't agree with Google that 'we need more code' (many projects seem overwhelmed at times by the amount of code they manage already, no slight intended...) The ASF agreed that Open Source needs to continue to grow in contributors. The only way to grow more contributors is to have them learn in-place. The mentor's job is to help them set up, avoid the usual foibles, help them participate in the community, and do a bit of steering of the project. Because the entire pace is 'accelerated' it is humanistically challenging, but far from impossible to bring an individual up to speed over a month or few. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Ok, so if we say it's the mentor's responsability, then it should be fine. I'll let the persons I'm mentoring know about the infrstructure we chose, then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Connector Benchmark
Vicenc Beltran Querol wrote: Hi, I would like to know if there is an official benchmark to compare the scalability/throughput of the new connectors (APR, Grizzly, ...) and Coyote. If not, maybe it's a good time to define one. I am confident you are going to be willing to contribute rigged results. BTW, Grizzly is not a Tomcat connector, it is a component of a separate product. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ((Urgent)) Which one is better: JSP or PHP with tomcat
jean-frederic clere wrote: You should compare httpd+mod-ssl and Tomcat+JSSE or + PureSSL, again that is hard to tell (but I prefer httpd+mod-ssl). How about that new Tomcat + mod_ssl-like ? ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
Tim Funk wrote: As part of the Google SOC. Google accepted the tomcat-reverse-proxy project to be executed by Anders Nyman ( anders.nyman at gmail d ot com ) The scope of the project is to let Tomcat act a reverse proxy by extending the balancer webapp. To make it easier to get the job done this summer while not relying on an intermediate committer, I propose granting commit access for only the following module: jakarta-tomcat-catalina/webapps/balancer/ The apache id granted would be prefixed with soc and be temporary. A CLA has already been signed and submitted. The vote is for commit access only for the module listed above. Voting rights will not be granted. [X] Sounds good to me [ ] I'm indifferent [ ] I don't like it. Here's why There are a few ways this could be handled, and this seems the easiest. I have had satisfactory email discussions with the two students I plan to mentor on Jasper, so I feel confident they will not screw things up (at least not too much ;)). I will propose them as temp committers as well if the vote passes. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Session Replication Portlets
Peter Rossbach wrote: Hey Eric, which tomcat release you use? I have change a lot inside the current 5.5 cvs head and hope your work is compatible with this changes. I thing your changes is not easy and you must reflect that other Valves and Listener must also reflect your API deprecated CrossContext feature. Why the Portlet API need CrossContext? Because the portlet specification is stupid, and is 100% based on cross context, which is *the* non portable feature. Implementatation help: Your must rewrote the complete ReplicationValve and JvmRouteBinderValve Look inside ReplicationValve.invoke and get from Container the Cluster CatalinaCluster cluster = (CatalinaCluster) getContainer.getCluster(); Currently you can get the complete list of the registerted application managers It is not easy to detected changes coordinate the startup and restart manager phase.. ( Look inside DeltaManager :-) I thing you must coordinate your replication with other threads ... ( very bad sync blocks). Since he's using portlets, he'll have to use emptySessionPath, which solves problems related with session ID handling. I though there would be no big problem with keeping a list (thread local) of sessions which have been accessed during a request, and have the replication valve take care of them. Either that or the request dispatcher will have to integrate the functionality of the replication valve (to some extent; I suppose this means adding a callback or something on Cluster). It's definitely not a piece of code to start on if someone doesn't know Tomcat well, that's for sure. Given the initial email, my advice is to forget about it for now and be a bit patient (or I'll just say happy hacking, but it's very unlikely I'll integrate any submitted changes). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Session Replication Portlets
Eric Dalquist wrote: I am prepared to do the work for this task but would like to get some feed back from the tomcat developer community on recommendations and in what way the work could be done to ensure its eventual inclusion in the tomcat codebase. We're not going to need much help here, as I assume that there will be at least two persons interested in fixing this eventually. Probably registering sessions for checking in access or endAccess would be a decent solution. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jni error
jean-frederic clere wrote: Hi, I have the following error when compiling: +++ src/file.c 502: [error]: CFE1136 struct JNINativeInterface_ has no field GetDirectBufferAddress char *bytes = (char *)(*e)-GetDirectBufferAddress(e, buf); ^ +++ My java version is 1.3.1, why are we requiring a very new one? NIO is used a lot, so I think it will require JDK 1.4+. I started some documentation, but it is not based on first hand experience, so feel free to fix it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Vicenc Beltran Querol wrote: That sounds great! Nice idea. Never thought about it. Let's say... something like a hybrid solution... that would be interesting. I got used to useless statements coming from you. I see a trend now. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
[EMAIL PROTECTED] wrote: billbarker2005/06/29 19:49:38 With a 16K bufferSize, the APR connector is no longer the clear winner in performance. For BC, it's currently disabled by default, but it's easy enough to change that after some more testing. Yes, I can see performance is better too. It's also possible that taking the APR code, and rewriting it with regular Java IO would also yield slightly better results (regular HTTP is still a little faster than APR HTTP - some VMs make the difference very small, but the VM I use for testing is definitely not the best for JNI). Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. Lol, sure, I'll think about it ;) Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Well, face it: the only thing which saves all this code is that it's there, and working (ChannelSocket is, at least). Besides this, a lot of it is complexity which didn't turn out to be needed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Yes, I do like parts of it: I'd say 80% of it is just a cool cut paste of my HTTP code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: LOL :-) Don't know what formula you used to get 80% (might be more :-)) , but why would I re-write something that works pretty well :-). Coyote/http11 was well designed, so was easy to extends. I got rid of the thread pool and replaced the front end with an nio non blocking approach, similar to what you did for APR. Well, all I know is that I only very casually looked at it, and that I should probably not do anything more. For all I know of Sun, you guys might well have patents for it in the pipe, and even if you don't, I am not allowed to reuse the code (and likely not reimplement it after looking at it either). So you can tease me all you want about looking at it in depth: forget it, I will not :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
[EMAIL PROTECTED] wrote: jfclere 2005/06/29 09:20:15 Modified:jk/tools jkrelease.sh Log: Allow to use http_proxy if available. This is unfait: I am without email (I switched to using a forward as an emergency measure), CVS access, etc. How did you do a commit ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
jean-frederic clere wrote: I am using the lastest version of ssh and have forced protocol 2. I'm using Putty. Neither me or Mladen can see a CVS server actually running, so we get a connection error. I'm using pserver auth over my regular SSH tunnel. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I have some new FormAuthenticator code for Tomcat.
Mark Thomas wrote: I am -1 for this for the following reasons (in order of importance): 1. Your reference to sending an encrypted user certificate file to the server demonstrates a lack of understanding of PKI that undermines my confidence that you know what you are doing when it comes to security. 2. JAAS provides plug-in authentication. 3. Password hashing is already supported. 4. The implementation is Tomcat specific and hence is non-portable. I agree with the arguments. I'll be the first to admit, however, that FORM (and the other auth methods from the spec) are insufficient and not flexible enough, and I am not completely against adding additional custom auth-methods. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
