Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Costin Manolache wrote: Aren't we in 'comit then review' mode for the trunk ? Yes. My understanding was that RTC is in effect for the stable releases, but not the trunk, and if there is no controversy ( and so far I think the only major issues was 'don't touch file structure or break ant' ) - he can just submit. Correct. I'd need more convincing to vote +1 to get it into one of the release branches but for trunk - assuming no change to existing file structure - go for it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Costin Manolache wrote: Sorry, I haven't been paying attention to all the rule changes - if someone could post the short version, I'm quite interested - I plan to re-start contributing few things and it would be good to know the process. trunk is CTR - normal veto rules apply all release branches are RTC needing 3 more +1s than -1s to get committed Everywhere else is also CTR - again with normal veto rules although it would have to be pretty drastic (eg license violation) to get a veto in the sandbox. There is also a summary here: http://wiki.apache.org/tomcat/TomcatVersions HTH, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
any Manolache wrote: BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ? being done now. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ? It's quite annoying, after each mail I get an auto-reply from them... I don't think I have karma to do it. Costin On Wed, Apr 30, 2008 at 6:06 PM, Costin Manolache <[EMAIL PROTECTED]> wrote: > On Wed, Apr 30, 2008 at 5:32 PM, Filip Hanik - Dev Lists < > [EMAIL PROTECTED]> wrote: > > > Costin Manolache wrote: > > > > > Aren't we in 'comit then review' mode for the trunk ? > > > > > > My understanding was that RTC is in effect for the stable releases, > > > but not > > > the trunk, > > > and if there is no controversy ( and so far I think the only major > > > issues > > > was 'don't touch file structure or break ant' ) - he can just submit. > > > > > > > > if that was the case, the old trunk would have never been moved to > > sandbox, > > that trunk was moved to sandbox based on code that never got a veto, -1. > > > I'm confused - there is a tomcat6/trunk repo - isn't this the trunk ? > > I know there are different things in sandbox - and that's all fine for > things that are bigger > or controversial changes - but not sure how a project can work without a > trunk ( unless > tomcat is dead and moved to maintainance only - but I don't remember that > announcement ) > > > > > I think the group has been careful lately, and always discussing changes > > to a consensus even before committing to trunk to avoid conflicts like that > > last one, which got quite ugly, even though it was just following CTR. > > > > Well, it is common sense to discuss changes that affect core functionality > before committing, and I think we ( and any other > reasonably active project ) had plenty of conflicts and debates. > > I remember a vote to do RTC for stable - and I think it passed, but I > don't remember any "remove the trunk" > or "RTC on the trunk". If it happened - maybe it's time to have another > discussion and reopen the trunk for CTR > and active development. > > While most of tomcat works 'well enough', I think there is enough interest > in making tomcat more modular - > and I'm planning to propose some sandbox->trunk moves as well. > > > > > > > > > in terms of the maven stuff, I don't fully believe that it is non > > intrusive yet. if it means adding poms everywhere in our java source code > > directory structure, i would consider that intrusive. > > > I would agree - I think what Henri is doing is create a build/maven > directory with poms under it. > > > > > > > > > Sorry, I haven't been paying attention to all the rule changes - if > > > someone > > > could > > > post the short version, I'm quite interested - I plan to re-start > > > contributing few things and it > > > would be good to know the process. > > > > > > > > consensus is always good to have, dont think we have fully recovered > > from the last episode yet to the point where we can just CTR anything > > > Sure - but that doesn't mean every small change needs to follow a formal > process and vote. It's still an open source project > that's supposed to be fun :-). > > Costin > > > > > > > > > and listen to me, I was the one that marked revolutionary :) > > > > > > Filip > > > > Costin > > > > > > On Wed, Apr 30, 2008 at 3:55 PM, Filip Hanik - Dev Lists < > > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > Costin Manolache wrote: > > > > > > > > > > > > > > > > > On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Costin Manolache wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We already have eclipse files checked in AFAIK - that counts > > > > > > > as the > > > > > > > second > > > > > > > build system. > > > > > > > We used to have makefiles too, also in parallel with ant (in > > > > > > > 3.0 > > > > > > > times). > > > > > > > > > > > > > > The goal IMO is that people who like to type mvn can do it - > > > > > > > without > > > > > > > any > > > > > > > guarantee that > > > > > > > the result will be identical with the official release or will > > > > > > > be > > > > > > > maintained > > > > > > > long term, just like > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > isn't that the culprit, including a feature under the pretenses > > > > > > that > > > > > > it > > > > > > wont be maintained? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( > > > > > which > > > > > AFAIK > > > > > is required for > > > > > something to be 'officially' released ). > > > > > > > > > > I'm sure Henri will maintain it - and at some point it may even > > > > > have > > > > > the 3 > > > > > +1s. As long as there is > > > > > no technical reason for a veto ( besides the 'don't break existing > > > > > build' - > > > > > which I think he addressed ), > > > > > I don't see how to stop him. I don't like Maven - but I think > > > > >
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
On Wed, Apr 30, 2008 at 5:32 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > > Aren't we in 'comit then review' mode for the trunk ? > > > > My understanding was that RTC is in effect for the stable releases, but > > not > > the trunk, > > and if there is no controversy ( and so far I think the only major > > issues > > was 'don't touch file structure or break ant' ) - he can just submit. > > > > > if that was the case, the old trunk would have never been moved to > sandbox, > that trunk was moved to sandbox based on code that never got a veto, -1. I'm confused - there is a tomcat6/trunk repo - isn't this the trunk ? I know there are different things in sandbox - and that's all fine for things that are bigger or controversial changes - but not sure how a project can work without a trunk ( unless tomcat is dead and moved to maintainance only - but I don't remember that announcement ) > I think the group has been careful lately, and always discussing changes > to a consensus even before committing to trunk to avoid conflicts like that > last one, which got quite ugly, even though it was just following CTR. Well, it is common sense to discuss changes that affect core functionality before committing, and I think we ( and any other reasonably active project ) had plenty of conflicts and debates. I remember a vote to do RTC for stable - and I think it passed, but I don't remember any "remove the trunk" or "RTC on the trunk". If it happened - maybe it's time to have another discussion and reopen the trunk for CTR and active development. While most of tomcat works 'well enough', I think there is enough interest in making tomcat more modular - and I'm planning to propose some sandbox->trunk moves as well. > > in terms of the maven stuff, I don't fully believe that it is non > intrusive yet. if it means adding poms everywhere in our java source code > directory structure, i would consider that intrusive. I would agree - I think what Henri is doing is create a build/maven directory with poms under it. > > Sorry, I haven't been paying attention to all the rule changes - if > > someone > > could > > post the short version, I'm quite interested - I plan to re-start > > contributing few things and it > > would be good to know the process. > > > > > consensus is always good to have, dont think we have fully recovered from > the last episode yet to the point where we can just CTR anything Sure - but that doesn't mean every small change needs to follow a formal process and vote. It's still an open source project that's supposed to be fun :-). Costin > > > and listen to me, I was the one that marked revolutionary :) > > > Filip > > Costin > > > > On Wed, Apr 30, 2008 at 3:55 PM, Filip Hanik - Dev Lists < > > [EMAIL PROTECTED]> > > wrote: > > > > > > > > > Costin Manolache wrote: > > > > > > > > > > > > > On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Costin Manolache wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We already have eclipse files checked in AFAIK - that counts as > > > > > > the > > > > > > second > > > > > > build system. > > > > > > We used to have makefiles too, also in parallel with ant (in > > > > > > 3.0 > > > > > > times). > > > > > > > > > > > > The goal IMO is that people who like to type mvn can do it - > > > > > > without > > > > > > any > > > > > > guarantee that > > > > > > the result will be identical with the official release or will > > > > > > be > > > > > > maintained > > > > > > long term, just like > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > isn't that the culprit, including a feature under the pretenses > > > > > that > > > > > it > > > > > wont be maintained? > > > > > > > > > > > > > > > > > > > > > > > > I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( > > > > which > > > > AFAIK > > > > is required for > > > > something to be 'officially' released ). > > > > > > > > I'm sure Henri will maintain it - and at some point it may even > > > > have > > > > the 3 > > > > +1s. As long as there is > > > > no technical reason for a veto ( besides the 'don't break existing > > > > build' - > > > > which I think he addressed ), > > > > I don't see how to stop him. I don't like Maven - but I think > > > > as > > > > long > > > > as it doesn't break anything > > > > Henri is perfectly entitled to work on this. > > > > > > > > > > > > > > > > > > > absolutely correct, and it should follow the guidelines of voting just > > > like everything else > > > 1+ means I support and intend to help > > > if you just support it, but are not planning on doing the work, then > > > the > > > vote is +0 :) > > > > > > Henri is more than welcome to make the proposal, no one is stopping > > > him > > > from doing so. > > > > > > Filip > > > > > > > > > > > > > > > > > > > Co
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Costin Manolache wrote: Aren't we in 'comit then review' mode for the trunk ? My understanding was that RTC is in effect for the stable releases, but not the trunk, and if there is no controversy ( and so far I think the only major issues was 'don't touch file structure or break ant' ) - he can just submit. if that was the case, the old trunk would have never been moved to sandbox, that trunk was moved to sandbox based on code that never got a veto, -1. I think the group has been careful lately, and always discussing changes to a consensus even before committing to trunk to avoid conflicts like that last one, which got quite ugly, even though it was just following CTR. in terms of the maven stuff, I don't fully believe that it is non intrusive yet. if it means adding poms everywhere in our java source code directory structure, i would consider that intrusive. Sorry, I haven't been paying attention to all the rule changes - if someone could post the short version, I'm quite interested - I plan to re-start contributing few things and it would be good to know the process. consensus is always good to have, dont think we have fully recovered from the last episode yet to the point where we can just CTR anything and listen to me, I was the one that marked revolutionary :) Filip Costin On Wed, Apr 30, 2008 at 3:55 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < [EMAIL PROTECTED]> wrote: Costin Manolache wrote: We already have eclipse files checked in AFAIK - that counts as the second build system. We used to have makefiles too, also in parallel with ant (in 3.0 times). The goal IMO is that people who like to type mvn can do it - without any guarantee that the result will be identical with the official release or will be maintained long term, just like isn't that the culprit, including a feature under the pretenses that it wont be maintained? I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( which AFAIK is required for something to be 'officially' released ). I'm sure Henri will maintain it - and at some point it may even have the 3 +1s. As long as there is no technical reason for a veto ( besides the 'don't break existing build' - which I think he addressed ), I don't see how to stop him. I don't like Maven - but I think as long as it doesn't break anything Henri is perfectly entitled to work on this. absolutely correct, and it should follow the guidelines of voting just like everything else 1+ means I support and intend to help if you just support it, but are not planning on doing the work, then the vote is +0 :) Henri is more than welcome to make the proposal, no one is stopping him from doing so. Filip Costin Filip the eclipse project can run but it's quite different from the official build. If it's making easier for some people to build tomcat - and it doesn't affect people who use ant in any way - what's the harm ? Costin On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat < [EMAIL PROTECTED]> wrote: The current build scripts are fully tested and work well. Adding additional methods of building or replacing these scripts altogether would only provide ways to create and/or release broken binaries. Again, no one is saying anything about touching the current build scripts, build process, release process, or source structure. All those remain the same. The job of the release manager remains the same. This is just an alternative for those people who want to use a slightly easier / user-friendlier build system. We could do worse than lowering the barrier to entry for new contributors. You mean you type "mvn" instead of "ant" ? I agree te keys are closer together on my keyboard, so it could indeed be easier. Personally, I did have a first hand experience with Maven, and I think it's horrible (you have no clue what it is doing, error reporting is bad, and basically, you have to think and act the tool's way). I disagree with having two separate build systems, there's no guarantee of equivalence. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1404 - Release Date: 4/29/2008 6:27 PM - To unsubscribe, e-mail: [EMAIL PROTEC
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Aren't we in 'comit then review' mode for the trunk ? My understanding was that RTC is in effect for the stable releases, but not the trunk, and if there is no controversy ( and so far I think the only major issues was 'don't touch file structure or break ant' ) - he can just submit. Sorry, I haven't been paying attention to all the rule changes - if someone could post the short version, I'm quite interested - I plan to re-start contributing few things and it would be good to know the process. Costin On Wed, Apr 30, 2008 at 3:55 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > > On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < > > [EMAIL PROTECTED]> wrote: > > > > > > > > > Costin Manolache wrote: > > > > > > > > > > > > > We already have eclipse files checked in AFAIK - that counts as the > > > > second > > > > build system. > > > > We used to have makefiles too, also in parallel with ant (in 3.0 > > > > times). > > > > > > > > The goal IMO is that people who like to type mvn can do it - without > > > > any > > > > guarantee that > > > > the result will be identical with the official release or will be > > > > maintained > > > > long term, just like > > > > > > > > > > > > > > > > > > > isn't that the culprit, including a feature under the pretenses that > > > it > > > wont be maintained? > > > > > > > > > > > > I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( which > > AFAIK > > is required for > > something to be 'officially' released ). > > > > I'm sure Henri will maintain it - and at some point it may even have > > the 3 > > +1s. As long as there is > > no technical reason for a veto ( besides the 'don't break existing > > build' - > > which I think he addressed ), > > I don't see how to stop him. I don't like Maven - but I think as > > long > > as it doesn't break anything > > Henri is perfectly entitled to work on this. > > > > > absolutely correct, and it should follow the guidelines of voting just > like everything else > 1+ means I support and intend to help > if you just support it, but are not planning on doing the work, then the > vote is +0 :) > > Henri is more than welcome to make the proposal, no one is stopping him > from doing so. > > Filip > > > > > Costin > > > > > > > > > > > Filip > > > > > > the eclipse project can run but it's quite different from the > > > official > > > > > > > > > > build. > > > > > > > > If it's making easier for some people to build tomcat - and it > > > > doesn't > > > > affect people who use > > > > ant in any way - what's the harm ? > > > > > > > > Costin > > > > > > > > > > > > On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat < > > > > > > [EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > The current build scripts are fully tested and work well. > > > > > > Adding > > > > > > > > > > > > > > > > > > > additional methods of building or replacing these scripts > > > > > > > altogether > > > > > > > would only provide ways to create and/or release broken > > > > > > > binaries. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again, no one is saying anything about touching the current > > > > > > build > > > > > > scripts, build process, release process, or source structure. > > > > > > All > > > > > > those remain the same. The job of the release manager remains > > > > > > the > > > > > > same. > > > > > > > > > > > > This is just an alternative for those people who want to use a > > > > > > slightly easier / user-friendlier build system. We could do > > > > > > worse > > > > > > than lowering the barrier to entry for new contributors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You mean you type "mvn" instead of "ant" ? I agree te keys are > > > > > closer > > > > > together on my keyboard, so it could indeed be easier. Personally, > > > > > I > > > > > did > > > > > have a first hand experience with Maven, and I think it's horrible > > > > > (you > > > > > have no clue what it is doing, error reporting is bad, and > > > > > basically, > > > > > you have to think and act the tool's way). > > > > > > > > > > I disagree with having two separate build systems, there's no > > > > > guarantee > > > > > of equivalence. > > > > > > > > > > Rémy > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Costin Manolache wrote: On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < [EMAIL PROTECTED]> wrote: Costin Manolache wrote: We already have eclipse files checked in AFAIK - that counts as the second build system. We used to have makefiles too, also in parallel with ant (in 3.0 times). The goal IMO is that people who like to type mvn can do it - without any guarantee that the result will be identical with the official release or will be maintained long term, just like isn't that the culprit, including a feature under the pretenses that it wont be maintained? I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( which AFAIK is required for something to be 'officially' released ). I'm sure Henri will maintain it - and at some point it may even have the 3 +1s. As long as there is no technical reason for a veto ( besides the 'don't break existing build' - which I think he addressed ), I don't see how to stop him. I don't like Maven - but I think as long as it doesn't break anything Henri is perfectly entitled to work on this. absolutely correct, and it should follow the guidelines of voting just like everything else 1+ means I support and intend to help if you just support it, but are not planning on doing the work, then the vote is +0 :) Henri is more than welcome to make the proposal, no one is stopping him from doing so. Filip Costin Filip the eclipse project can run but it's quite different from the official build. If it's making easier for some people to build tomcat - and it doesn't affect people who use ant in any way - what's the harm ? Costin On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote: The current build scripts are fully tested and work well. Adding additional methods of building or replacing these scripts altogether would only provide ways to create and/or release broken binaries. Again, no one is saying anything about touching the current build scripts, build process, release process, or source structure. All those remain the same. The job of the release manager remains the same. This is just an alternative for those people who want to use a slightly easier / user-friendlier build system. We could do worse than lowering the barrier to entry for new contributors. You mean you type "mvn" instead of "ant" ? I agree te keys are closer together on my keyboard, so it could indeed be easier. Personally, I did have a first hand experience with Maven, and I think it's horrible (you have no clue what it is doing, error reporting is bad, and basically, you have to think and act the tool's way). I disagree with having two separate build systems, there's no guarantee of equivalence. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1404 - Release Date: 4/29/2008 6:27 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43147] Tomcat source does not compile with javac 1.6. 0_01
https://issues.apache.org/bugzilla/show_bug.cgi?id=43147 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-30 15:47:09 PST --- This is a 'feature' of using commons-DBCP. The issue is being tracked at https://issues.apache.org/jira/browse/DBCP-191 Essentially, the problem is caused by the JDBC API in the JDK not being backwards compatible. The workaround we are using for now is to build with 1.5 I am marking this as invalid since the fix needs to be in the DBCP source. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43327] Socket bind fails on tomcat startup when using apr
https://issues.apache.org/bugzilla/show_bug.cgi?id=43327 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-30 15:39:53 PST --- I am having trouble reproducing this error. It may have already been fixed or it may be an issue with your build environment. Please can you re-test with the latest APR, openssl, tomcat-native and 6.0.16 and, if you still see this error, provide the exact version numbers and commands you used to build so I can try and repeat this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Apr 30, 2008, at 10:28 AM, Costin Manolache wrote: On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]> wrote: Regarding HttpService - I don't think it's a good idea for tomcat. One of the major problems with OSGI ( and we need to make sure we don't fall in this trap ) is the re-invention of common APIs - logging, servlet interfaces, etc. As a bit of background. The logging and Http Service API are from 1999. At that time there was no dominant common logging API (neither in Java SE nor in open source), and the Http Service API is 100% based on the, at that time, standard Servlet API (it uses javax.servlet.http), it only provides an API to dynamically register and unregister servlets, which is still lacking in the current Servlet API. Regarding 'dynamic register/unregister' - the servlet API defines one way to do this, i.e. war and the deployment. There is no standard API to install/uninstall/start/stop a .war umm, jsr-88?? david jencks - but HttpService is not that either. Runtime config changes ( adding/removing servlets without web.xml changes and re-deployment ) is not specified, but it's a whole different discussion for the JSR people to solve, I'm pretty sure it'll be different from HttpService. It would be quite inappropriate for tomcat to not use the standard deployment/configuration mechanism for servlets. So using or implementing any of the OSGI-re-defined service interfaces in tomcat would be a hard sale IMO. Well, I do not see that this is an dichotomy. By nature of being the RI, you must follow the JSR. However, it would not be hard to provide the Http Service as an additional component. If Tomcat provides an API to dynamically register servlets, it would be trivial for someone to provide an OSGi compatibility bundle, just like people are doing it today. But it would be a nice service to get this from the horse's mouth. I am sure people are willing to provide this code. A lot of people would like for tomcat to provide more jetty-like APIs for programmatic configuration ( and in a way it is already possible - just not easy ). As an API, HttpService is way off - in '99 and servlet 2.1 it may have been valuable. Let's keep HttpService for a different discussion :-) In reality, this is a rather crude approach because in well designed systems the coupling between bundles is minimal. At this point in time, services usually start to look more attractive because they provide an API to allow dynamic updates without crudely stopping all bundles in the module dependency graph (which in non-service based systems, and especially require- bundle based systems tends to become the whole system). And a service is just a POJO that is registered under one or more interfaces. By allowing it to withdrawn at any moment in time, as well as registered by multiple independent parties, OSGi provides a good abstraction of this dynamism. And there is no Java counterpart for this. Actually - JMX provides a lot of this dynamism. Tomcat is using a lot of JMX ( and hopefully will use more ), and provide very similar model with OSGI services. they fell in love and the service layer was a major part of their infatuation. They realized very quickly how they could leverage the services as beans in their model and the advantages of dynamism without rebooting. To clarify: updating webapps in tomcat without rebooting has been around for many years :-). Webapps are quite similar with the bundles - it would be interesting to see if we could use OSGI classloader instead of ours, but I don't think that's a real problem. People are looking for 'gapless' restart, i.e. users who have an active session continuing to use the old version ( or some magic way to migrate the session - but that's likely impossible in most real cases, i.e. if code changes happen ). OSGi alone can't solve this. A whole different class of users would like to see _less_ dynamism - i.e. embedding tomcat as a jar and using simple APIs and no class loaders or config files. In both high-end servers and low-end embedding this is a very important use case. The problem I would like to see solved in tomcat is breaking it up in modules - i.e. separating all the optional parts and having a way to ship a really minimal core and a good way to release and deploy add-on bundles. OSGi may be a good way to do this. I think the requirements are: - provide a way for different tomcat components and core to be packaged as OSGi bundles, using manifests and maybe optional activators if it can't be avoided ( as long as tomcat doesn't depend on it ). I think this is an easy sell, I can't think of any good technical reasons not to do it. - break tomcat release ( for 7.0 or 6.5 or whatever trunk will be released as ) into just core ( minimal servlet impl ) and bundles - find a easy way for people to download/install all modules they
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists < [EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > > We already have eclipse files checked in AFAIK - that counts as the > > second > > build system. > > We used to have makefiles too, also in parallel with ant (in 3.0 > > times). > > > > The goal IMO is that people who like to type mvn can do it - without any > > guarantee that > > the result will be identical with the official release or will be > > maintained > > long term, just like > > > > > isn't that the culprit, including a feature under the pretenses that it > wont be maintained? I meant 'maintained' in the apache-sense, of having 3 +1, etc. ( which AFAIK is required for something to be 'officially' released ). I'm sure Henri will maintain it - and at some point it may even have the 3 +1s. As long as there is no technical reason for a veto ( besides the 'don't break existing build' - which I think he addressed ), I don't see how to stop him. I don't like Maven - but I think as long as it doesn't break anything Henri is perfectly entitled to work on this. Costin > > Filip > > the eclipse project can run but it's quite different from the official > > build. > > > > If it's making easier for some people to build tomcat - and it doesn't > > affect people who use > > ant in any way - what's the harm ? > > > > Costin > > > > > > On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: > > > > > > > > > > On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> > > > > > > > > > > > wrote: > > > > > > > > > > The current build scripts are fully tested and work well. Adding > > > > > additional methods of building or replacing these scripts > > > > > altogether > > > > > would only provide ways to create and/or release broken binaries. > > > > > > > > > > > > > > Again, no one is saying anything about touching the current build > > > > scripts, build process, release process, or source structure. All > > > > those remain the same. The job of the release manager remains the > > > > same. > > > > > > > > This is just an alternative for those people who want to use a > > > > slightly easier / user-friendlier build system. We could do worse > > > > than lowering the barrier to entry for new contributors. > > > > > > > > > > > You mean you type "mvn" instead of "ant" ? I agree te keys are closer > > > together on my keyboard, so it could indeed be easier. Personally, I > > > did > > > have a first hand experience with Maven, and I think it's horrible > > > (you > > > have no clue what it is doing, error reporting is bad, and basically, > > > you have to think and act the tool's way). > > > > > > I disagree with having two separate build systems, there's no > > > guarantee > > > of equivalence. > > > > > > Rémy > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > No virus found in this incoming message. > > > Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1404 - > > > Release Date: 4/29/2008 6:27 PM > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
Costin Manolache wrote: We already have eclipse files checked in AFAIK - that counts as the second build system. We used to have makefiles too, also in parallel with ant (in 3.0 times). The goal IMO is that people who like to type mvn can do it - without any guarantee that the result will be identical with the official release or will be maintained long term, just like isn't that the culprit, including a feature under the pretenses that it wont be maintained? Filip the eclipse project can run but it's quite different from the official build. If it's making easier for some people to build tomcat - and it doesn't affect people who use ant in any way - what's the harm ? Costin On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote: The current build scripts are fully tested and work well. Adding additional methods of building or replacing these scripts altogether would only provide ways to create and/or release broken binaries. Again, no one is saying anything about touching the current build scripts, build process, release process, or source structure. All those remain the same. The job of the release manager remains the same. This is just an alternative for those people who want to use a slightly easier / user-friendlier build system. We could do worse than lowering the barrier to entry for new contributors. You mean you type "mvn" instead of "ant" ? I agree te keys are closer together on my keyboard, so it could indeed be easier. Personally, I did have a first hand experience with Maven, and I think it's horrible (you have no clue what it is doing, error reporting is bad, and basically, you have to think and act the tool's way). I disagree with having two separate build systems, there's no guarantee of equivalence. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1404 - Release Date: 4/29/2008 6:27 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]> wrote: > Regarding HttpService - I don't think it's a good idea for tomcat. > > One of the major problems with OSGI ( and we need to make sure we don't > > fall > > in this trap ) is the re-invention of common APIs - logging, servlet > > interfaces, etc. > > > As a bit of background. The logging and Http Service API are from 1999. At > that time > there was no dominant common logging API (neither in Java SE nor in open > source), > and the Http Service API is 100% based on the, at that time, standard > Servlet API (it > uses javax.servlet.http), it only provides an API to dynamically register > and unregister > servlets, which is still lacking in the current Servlet API. Regarding 'dynamic register/unregister' - the servlet API defines one way to do this, i.e. war and the deployment. There is no standard API to install/uninstall/start/stop a .war - but HttpService is not that either. Runtime config changes ( adding/removing servlets without web.xml changes and re-deployment ) is not specified, but it's a whole different discussion for the JSR people to solve, I'm pretty sure it'll be different from HttpService. It would be quite inappropriate for tomcat to not use the standard > > deployment/configuration mechanism for > > servlets. So using or implementing any of the OSGI-re-defined service > > interfaces in > > tomcat would be a hard sale IMO. > > > > Well, I do not see that this is an dichotomy. By nature of being the RI, > you must follow the > JSR. However, it would not be hard to provide the Http Service as an > additional component. If > Tomcat provides an API to dynamically register servlets, it would be > trivial for someone > to provide an OSGi compatibility bundle, just like people are doing it > today. > But it would be a nice service to get this from the horse's mouth. I am > sure people are willing > to provide this code. > A lot of people would like for tomcat to provide more jetty-like APIs for programmatic configuration ( and in a way it is already possible - just not easy ). As an API, HttpService is way off - in '99 and servlet 2.1 it may have been valuable. Let's keep HttpService for a different discussion :-) > In reality, this is a rather crude approach because in well designed > systems the coupling between bundles > is minimal. At this point in time, services usually start to look more > attractive because they provide > an API to allow dynamic updates without crudely stopping all bundles in > the module dependency > graph (which in non-service based systems, and especially require-bundle > based systems tends > to become the whole system). And a service is just a POJO that is > registered under one or more interfaces. By allowing > it to withdrawn at any moment in time, as well as registered by multiple > independent parties, OSGi > provides a good abstraction of this dynamism. And there is no Java > counterpart for this. > Actually - JMX provides a lot of this dynamism. Tomcat is using a lot of JMX ( and hopefully will use more ), and provide very similar model with OSGI services. > they fell in love and the service layer was a major part of their > infatuation. They > realized very quickly how they could leverage the services as beans in > their model and the > advantages of dynamism without rebooting. To clarify: updating webapps in tomcat without rebooting has been around for many years :-). Webapps are quite similar with the bundles - it would be interesting to see if we could use OSGI classloader instead of ours, but I don't think that's a real problem. People are looking for 'gapless' restart, i.e. users who have an active session continuing to use the old version ( or some magic way to migrate the session - but that's likely impossible in most real cases, i.e. if code changes happen ). OSGi alone can't solve this. A whole different class of users would like to see _less_ dynamism - i.e. embedding tomcat as a jar and using simple APIs and no class loaders or config files. In both high-end servers and low-end embedding this is a very important use case. The problem I would like to see solved in tomcat is breaking it up in modules - i.e. separating all the optional parts and having a way to ship a really minimal core and a good way to release and deploy add-on bundles. OSGi may be a good way to do this. I think the requirements are: - provide a way for different tomcat components and core to be packaged as OSGi bundles, using manifests and maybe optional activators if it can't be avoided ( as long as tomcat doesn't depend on it ). I think this is an easy sell, I can't think of any good technical reasons not to do it. - break tomcat release ( for 7.0 or 6.5 or whatever trunk will be released as ) into just core ( minimal servlet impl ) and bundles - find a easy way for people to download/install all modules they want. - integrate this with the JMX layer and the manager servlet - a
DO NOT REPLY [Bug 43153] Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws org.apache.tomcat.jni.Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=43153 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-30 08:31:21 PST --- This was fixed in svn back in Feb 2008 and will be included in native 1.1.14 onwards -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
We already have eclipse files checked in AFAIK - that counts as the second build system. We used to have makefiles too, also in parallel with ant (in 3.0 times). The goal IMO is that people who like to type mvn can do it - without any guarantee that the result will be identical with the official release or will be maintained long term, just like the eclipse project can run but it's quite different from the official build. If it's making easier for some people to build tomcat - and it doesn't affect people who use ant in any way - what's the harm ? Costin On Wed, Apr 30, 2008 at 2:23 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: > > On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> > wrote: > > > The current build scripts are fully tested and work well. Adding > > > additional methods of building or replacing these scripts altogether > > > would only provide ways to create and/or release broken binaries. > > > > Again, no one is saying anything about touching the current build > > scripts, build process, release process, or source structure. All > > those remain the same. The job of the release manager remains the > > same. > > > > This is just an alternative for those people who want to use a > > slightly easier / user-friendlier build system. We could do worse > > than lowering the barrier to entry for new contributors. > > You mean you type "mvn" instead of "ant" ? I agree te keys are closer > together on my keyboard, so it could indeed be easier. Personally, I did > have a first hand experience with Maven, and I think it's horrible (you > have no clue what it is doing, error reporting is bad, and basically, > you have to think and act the tool's way). > > I disagree with having two separate build systems, there's no guarantee > of equivalence. > > Rémy > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Assuring Security by testing
Mark, I agree with all of your comments 100%. If you really wanted to conduct an in-depth security analysis, the best bet is to hire a dedicated application security company to conduct a targeted code review. Most automated application security tools are crap. But for the sake of academic research, the Fortify Tomcat report might be a little interesting. -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com Jim Manico wrote: The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com A great example of why I have don't have much faith (hope for the future yes - faith for the current crop no) in these tools. In summary: - they are looking at 4.1.10, 5.5.20 and 6.? - I don't know which TC6 version they analysed (but I suspect it is quite old) since they never responded to my requests to add me to that project and I lost interest - there are so many false positives I got fed up looking at them - the bug reporting is way to clunky compared to just using Eclipse or any other decent IDE - it missed most (all if I recall correctly - I don't have the time or inclination to check) of the XSS issues we know were in 4.1.10 onwards I maintain that you will get greater benefit for time invested just by clearing the issues flagged by a decent IDE. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
Jim Manico wrote: The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com A great example of why I have don't have much faith (hope for the future yes - faith for the current crop no) in these tools. In summary: - they are looking at 4.1.10, 5.5.20 and 6.? - I don't know which TC6 version they analysed (but I suspect it is quite old) since they never responded to my requests to add me to that project and I lost interest - there are so many false positives I got fed up looking at them - the bug reporting is way to clunky compared to just using Eclipse or any other decent IDE - it missed most (all if I recall correctly - I don't have the time or inclination to check) of the XSS issues we know were in 4.1.10 onwards I maintain that you will get greater benefit for time invested just by clearing the issues flagged by a decent IDE. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com Hi devs, I've been investigating Apache Tomcat within my Bachelor's thesis "Application of security test tools in open source" at the Free University of Berlin (FU Berlin) [1]. Basically, I am looking for security measures which have been taken to prevent security leaks/vulnerabilities especially with security test tools Apache Tomcat is a extremely popular servlet engine. The nature of the application offers to compromise the web apps and reveal sensitive data. It does not seem that Tomcat cannot be tested the classic way web apps are, e.g. testing with fuzzer for SQL injection, parameter tampering, path traversal etc. So far, I have search the repository and the ant build.xml, the homepage and the mailing list.The homepage and mailing list revealed no information at all to me. I did find that you refer to security audit conducted against the 5.0 codebase [2]. Unfortunately, no information was given what was found and what measures have been taken afterwards. Security advisories are taken up by a security team [3]. Does this team or any other group/person take any measures to assure security with testing tools, with a special test plan or functional requirements? Thanks in advance, Michael [1] https://www.inf.fu-berlin.de/w/SE/ThesisFOSSSecurityTools [2] http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html [3] http://tomcat.apache.org/security-6.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
Michael Osipov wrote: Mark Thomas wrote: We do occasionally receive reports to the security team that provide outputs from various security testing tools. In short, the output is nearly always complete garbage. For example, on one occasion a handful of XSS issues were reported all of which were invalid whilst valid XSS issues (later reported by others) were completely missed. Were you reported the name of the tools with which the garbage out has been produced? Yes we were, but I am not prepared to name the tools. Getting off topic a little, where I think automated tools do have something to offer is in the area of finding bugs. Checking for unused variables etc often highlights (usually minor) bugs. Find bugs, PMD, checkstyle, the stuff built in to Eclipse all have something to offer in this area. I am aware of all the tools you cited, but they don't do necessarily security testing (e.g. checkstyle). Did you ever come across LAPSE [1]? I have investigated some tools, maybe they are in your interest to some extent. Check this article [2] on different tools, nikto [3], and Wfuzz [4]. As I said, automated tools for finding general bugs can work. I haven't (and wouldn't) used them to find security issues. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
On Tue, Apr 22, 2008 at 11:45 AM, Henri Gomez <[EMAIL PROTECTED]> wrote: > Hi to all, > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? Quotes from http://www.infoq.com/news/2008/04/springsource-app-platform "...the SpringSource Application Platform, an application server built on Spring, OSGi, and Apache Tomcat" "Tomcat is included as an OSGi bundle to support web functionality." "SpringSource will also be submitting patches back to projects such as Tomcat for any changes they have made to enable a library to be OSGi bundle compatible." Niall > Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
Mark Thomas wrote: Michael Osipov wrote: Security advisories are taken up by a security team [3]. Does this team or any other group/person take any measures to assure security with testing tools, with a special test plan or functional requirements? Hello Mark, I did not expect such a quick and long answer. Thanks first of all! We do occasionally receive reports to the security team that provide outputs from various security testing tools. In short, the output is nearly always complete garbage. For example, on one occasion a handful of XSS issues were reported all of which were invalid whilst valid XSS issues (later reported by others) were completely missed. Were you reported the name of the tools with which the garbage out has been produced? I have yet to see an automated security test tool that offers any useful output against the Tomcat code base. I am investigating some tools too but their are still evolving. If you want to test a security audit tool then you can run it against an old 4.1.x, 5.5.x or 6.0.x tag and see if it identifies any of the the issues listed on the security pages. Yes, that's probably what I can do but I am just a developer using tomcat as a servlet engine. I guess, due to tomcats complexity it'd take some time to understand how to run an attack at all. The majority of our security reports come: - from security researches who review, for whatever reason, parts of the code they believe to be vulnerable to attack - users that discover a security issue through normal use We also review every issue to see if there may be other places in the codebase that are affected that the reporter did not mention. For example we had a couple of XSS in the examples and when we looked at the rest of the examples code we found a few more. Every commit is reviewed by three committers before it is applied. Security is one of the considerations when reviewing a patch. Getting off topic a little, where I think automated tools do have something to offer is in the area of finding bugs. Checking for unused variables etc often highlights (usually minor) bugs. Find bugs, PMD, checkstyle, the stuff built in to Eclipse all have something to offer in this area. I am aware of all the tools you cited, but they don't do necessarily security testing (e.g. checkstyle). Did you ever come across LAPSE [1]? I have investigated some tools, maybe they are in your interest to some extent. Check this article [2] on different tools, nikto [3], and Wfuzz [4]. Thanks again. I have to process you answers first before I proceed asking if you don't mind being asked. Mike [1] http://suif.stanford.edu/~livshits/work/lapse/ [2] http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/ [3] http://www.cirt.net/nikto2 [4] http://www.edge-security.com/wfuzz.php -- OOXML - Say NO To Microsoft Office broken standard http://www.noooxml.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
Michael Osipov wrote: Security advisories are taken up by a security team [3]. Does this team or any other group/person take any measures to assure security with testing tools, with a special test plan or functional requirements? We do occasionally receive reports to the security team that provide outputs from various security testing tools. In short, the output is nearly always complete garbage. For example, on one occasion a handful of XSS issues were reported all of which were invalid whilst valid XSS issues (later reported by others) were completely missed. I have yet to see an automated security test tool that offers any useful output against the Tomcat code base. If you want to test a security audit tool then you can run it against an old 4.1.x, 5.5.x or 6.0.x tag and see if it identifies any of the the issues listed on the security pages. The majority of our security reports come: - from security researches who review, for whatever reason, parts of the code they believe to be vulnerable to attack - users that discover a security issue through normal use We also review every issue to see if there may be other places in the codebase that are affected that the reporter did not mention. For example we had a couple of XSS in the examples and when we looked at the rest of the examples code we found a few more. Every commit is reviewed by three committers before it is applied. Security is one of the considerations when reviewing a patch. Getting off topic a little, where I think automated tools do have something to offer is in the area of finding bugs. Checking for unused variables etc often highlights (usually minor) bugs. Find bugs, PMD, checkstyle, the stuff built in to Eclipse all have something to offer in this area. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assuring Security by testing
Hi devs, I've been investigating Apache Tomcat within my Bachelor's thesis "Application of security test tools in open source" at the Free University of Berlin (FU Berlin) [1]. Basically, I am looking for security measures which have been taken to prevent security leaks/vulnerabilities especially with security test tools Apache Tomcat is a extremely popular servlet engine. The nature of the application offers to compromise the web apps and reveal sensitive data. It does not seem that Tomcat cannot be tested the classic way web apps are, e.g. testing with fuzzer for SQL injection, parameter tampering, path traversal etc. So far, I have search the repository and the ant build.xml, the homepage and the mailing list.The homepage and mailing list revealed no information at all to me. I did find that you refer to security audit conducted against the 5.0 codebase [2]. Unfortunately, no information was given what was found and what measures have been taken afterwards. Security advisories are taken up by a security team [3]. Does this team or any other group/person take any measures to assure security with testing tools, with a special test plan or functional requirements? Thanks in advance, Michael [1] https://www.inf.fu-berlin.de/w/SE/ThesisFOSSSecurityTools [2] http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html [3] http://tomcat.apache.org/security-6.html -- OOXML - Say NO To Microsoft Office broken standard http://www.noooxml.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44908] LoggerConfigurationException Caused by session-timeout Setting in web.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=44908 --- Comment #1 from Edwin Lee <[EMAIL PROTECTED]> 2008-04-30 03:02:22 PST --- Created an attachment (id=21885) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=21885) WAR file to replicate issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44908] New: LoggerConfigurationException Caused by session-timeout Setting in web.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=44908 Summary: LoggerConfigurationException Caused by session-timeout Setting in web.xml Product: Tomcat 4 Version: 4.1.37 Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JDK version 1.4.2_16 A LoggerConfigurationException would occur if the default web.xml (in the conf directory) or the web.xml in the web-app (in WEB-INF) contains the session-timeout entry i.e. 30 AND the WEB-INF/classes directory contains a commons-logging.properties file with the entry org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger. The console would display 30-Apr-2008 17:44:17 org.apache.commons.digester.Digester endElement SEVERE: End event threw exception org.apache.commons.logging.LogConfigurationException: User-specified log class ' org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable. at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) at org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:130) at org.apache.commons.beanutils.BeanUtilsBean.(BeanUtilsBean.java:110) at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:80) at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78) at org.apache.commons.beanutils.ConvertUtilsBean.getInstance(ConvertUtilsBean.java:115) at org.apache.commons.beanutils.ConvertUtils.convert(ConvertUtils.java:217) at org.apache.commons.digester.CallMethodRule.end(CallMethodRule.java:561) at org.apache.commons.digester.Rule.end(Rule.java:253) at org.apache.commons.digester.Digester.endElement(Digester.java:1222) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endNamespaceScope(UnknownSource) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1745) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:488) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:579) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3644) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:777) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:760) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:538) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:265) at org.apache.catalina.core.StandardHost.install(StandardHost.java:731) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:649) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:379) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:808) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:335) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1156) at org.apache.catalina.core.StandardHost.s
Re: Mavenizing Tomcat : Was: Osgifing Tomcat
On Tue, 2008-04-29 at 22:28 -0400, Yoav Shapira wrote: > On Tue, Apr 29, 2008 at 10:09 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > The current build scripts are fully tested and work well. Adding > > additional methods of building or replacing these scripts altogether > > would only provide ways to create and/or release broken binaries. > > Again, no one is saying anything about touching the current build > scripts, build process, release process, or source structure. All > those remain the same. The job of the release manager remains the > same. > > This is just an alternative for those people who want to use a > slightly easier / user-friendlier build system. We could do worse > than lowering the barrier to entry for new contributors. You mean you type "mvn" instead of "ant" ? I agree te keys are closer together on my keyboard, so it could indeed be easier. Personally, I did have a first hand experience with Maven, and I think it's horrible (you have no clue what it is doing, error reporting is bad, and basically, you have to think and act the tool's way). I disagree with having two separate build systems, there's no guarantee of equivalence. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Regarding HttpService - I don't think it's a good idea for tomcat. One of the major problems with OSGI ( and we need to make sure we don't fall in this trap ) is the re-invention of common APIs - logging, servlet interfaces, etc. As a bit of background. The logging and Http Service API are from 1999. At that time there was no dominant common logging API (neither in Java SE nor in open source), and the Http Service API is 100% based on the, at that time, standard Servlet API (it uses javax.servlet.http), it only provides an API to dynamically register and unregister servlets, which is still lacking in the current Servlet API. On top of that, all these service APIs are optional. If you look in more detail, than many services are similar: providing a possibility to -dynamically- use Java APIs. I.e. XML parsers, IO Connectors (J2ME), Servlets, URL stream and content handlers, Preferences, etc. We are not looking for work and try to leverage the existing Java environment to the utmost extent. This said, I agree that you want the core of a product like Tomcat to be as decoupled as possible of any frameworks, including OSGi. Decoupling is the guiding principle behind OSGi and the raison d'etre for most of its functionality. Not using a service is better than coupling to it. But sometimes not using a service is more expensive than using it, that decision is what design is all about. It would be quite inappropriate for tomcat to not use the standard deployment/configuration mechanism for servlets. So using or implementing any of the OSGI-re-defined service interfaces in tomcat would be a hard sale IMO. Well, I do not see that this is an dichotomy. By nature of being the RI, you must follow the JSR. However, it would not be hard to provide the Http Service as an additional component. If Tomcat provides an API to dynamically register servlets, it would be trivial for someone to provide an OSGi compatibility bundle, just like people are doing it today. But it would be a nice service to get this from the horse's mouth. I am sure people are willing to provide this code. A bit more background. 4 years ago IBM started to like the OSGi modularity (class loaders on steroids) and the silly, unnecessary life cycle and service layer. Actually, we had no visible layers back then. At that time, there were raging debates about modularity with lots of competition. This was actually the trigger for R4 to put the 4 layers into place: security, execution environment, modularity, life cycle, service. Key idea was that people could pick the modularity layer without dragging in the life cycle and service layer. I think the dislike for these layers was based on lack of familiarity because what happened was that people started to use the modularity, then found out how convenient the life cycle layer is in development. You can keep your app server running while debugging and updating code. However, getting hooked to the life cycle layer (if only for development) means things are coming and going. Coupling through the module layer (i.e. factories, Class.forName, etc) means you create import wires to other modules that can not be dynamically withdrawn because Java lacks an API for this. In OSGi, it is not a big deal because you can still stop a bundle, update it, and refresh all the import wires. This is feasible because bundles can be started and stopped and the OSGi framework is intricately aware of these import wires. In reality, this is a rather crude approach because in well designed systems the coupling between bundles is minimal. At this point in time, services usually start to look more attractive because they provide an API to allow dynamic updates without crudely stopping all bundles in the module dependency graph (which in non-service based systems, and especially require- bundle based systems tends to become the whole system). And a service is just a POJO that is registered under one or more interfaces. By allowing it to withdrawn at any moment in time, as well as registered by multiple independent parties, OSGi provides a good abstraction of this dynamism. And there is no Java counterpart for this. With JSR 291 we had the same situation. There was a requirement to get rid of the service layer because it was deemed unnecessary. We puzzled with the interfaces in OSGi so that we could be backward compatible and still have this separation. We got some solution but it felt awkward. Worse, there are a number of optional APIs in the OSGi framework to manage the modularity layer (PackageAdmin), the security (PermissionAdmin and ConditionalPermissionAdmin), startlevels, and URL stream and content handling. By removing the service layer we had to find an alternative way to provide these APIs to the bundles. Factories? Dependency Injection? Class.forName? They all felt far inferior to the service model, all lacking the dynamics
[Tomcat Wiki] Trivial Update of "SSLWithFORMFallback" by JamesGoodger
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by JamesGoodger: http://wiki.apache.org/tomcat/SSLWithFORMFallback -- Fire up your browser and install the client certificate and private key in your certificate store. - Now change your auth-method from "FROM" to "CLIENT-CERT" and restart/redeploy your web-app. If you access your protected page you should now be prompted for a certificate by your browser. Select the installed certificate. If everything was configured correctly you should be authenticated based on your certificate, and taken to the protected page. + Now change your auth-method from "FORM" to "CLIENT-CERT" and restart/redeploy your web-app. If you access your protected page you should now be prompted for a certificate by your browser. Select the installed certificate. If everything was configured correctly you should be authenticated based on your certificate, and taken to the protected page. If things go wrong, here's some places to look: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43174] EOFException was thrown repeatedly from StandardManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=43174 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-30 00:26:37 PST --- Deleting the file doesn't give a system admin any chance to examine it to see why it failed. We have seen serialisation bugs that this fix would make much harder to investigate. The corrupted file will be over-written when Tomcat shutsdown so the exceptions will only be seen once anyway. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
