RE: my proposal for re implement tomcat valves as filters
Mark Thomas wrote : Feedback: Good first draft. There are a coupe of areas I would like to see more detail on: 1. Impact of Servlet 3 and async processing. Lack of asynchronous support in the Servlet 2.5 specification has caused server vendors to devise workarounds by weaving proprietary classes and interfaces that promote scalable Comet programming into the Servlet 2.5 API.As Servlet 3 support async processing, I think there is no need to Comet programming (CometEvent, CometFilter, CometFilterChain, CometProcessor, CometEventImpl, CometConnectionManagerValve classes are no longer needed). I think others features like annotations will not be useful 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? My idea to handle this is as follow - tracks other component that can be defined at Context and Host, for example HttpServlet (servlet /servlet tag).- read HttpServlet implantation and specification, then try to make implementation to FilterClass implement Filter interface, same as HttpServlet, so Filter can be defined at host level. Then try to make necessary modification on Filter to wide it at Engine level. 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? still searching , can you explain more. I would also suggest you spend a little time to build Tomcat from source (http://svn.apache.org/repos/asf/tomcat/trunk). Once you have Tomcat building, I'd suggest looking at the AccessLogValve and how that might be converted to a Filter to give you a better ide of the issues involved and how long things might take. i will do but there is no lot time ,Friday is the last day for submit proposal ,what is the necessary modifications to add them to proposal ? finally how many students will work in this project? Thanks Anas Ahmed _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_042009
Re: [Proposal] Remove older of the two BIO AJP connectors
Le 30 mars 09 à 18:00, Mark Thomas ma...@apache.org a écrit : Henri Gomez wrote: Ain't those used for 5.5? You can however just remove them from the build. Other option is to copy them to the 5.5 and not referencing the connectors for those set of classes. Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend changing 5.5.x or 6.0.x What's the state for Tomcat 7 ? Development is happening in trunk. I wonder if they're allready some discussions/plans about it. Not just technical/specs/RI plans but more generally what could/ should Tomcat 7 be ? /trunk/TOMCAT-7-RELEASE-PLAN.txt I could see that many projects (GWT/Eclipse), are now switching to Jetty (which is great container also). Did we miss something at some time ? Ease of embedding? Size? Of course better embedding support, smallest (may be less jars), a faster start mode (with minimal features). And also more openess to new commiters and external projects. I still think that what make httpd success is it's modular approach with a well known internal request process. Many modules raised outside core httpd team/project and some even joined it later. And it get a bigger commiters community with new ideas and constant évolution/révolution. May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. I read it. It's a new spec. Dot. May be being the RI prevents major evolution/révolution ? Tomcat Light is a good idea but only costin works on it. Asf has a great server framework, mina, but it's not used by Tc. Osgi is getting more and more adoption and Eclipse or Felix select Jetty as their http implementation. Maven has never been used as build system and 10 years after Tc is still stick with ant. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. Probably it didn't help/allow new peoples join the project and add some fresh air ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Good but may be too late ;-( If i recall the tomcat story (10 years). Code given by Sun to ASF. Tc 3.0 ? Some ASF refactoring later came Tc 3.1 and then 3.2. First 'fork', tc 3.3 - tc 4.0. One project with individuals, the other with Sun commiters. tc 4.1 and then 5.0 ended the fork. But it became a Jboss commiters driven project. 5.5 and later 6.0 show the switch from Jboss to SpringSource 'leadership'. Today Sun has it's own implementation, Grizzly. Jboss forked tc code in it's own implémentation for AS. Spring Source embed it in it's DM server. Differents historicals leaders, differents commercial purposes/ requierements may explain why evolution/revolution has never been really well accepted ;( That's why i wonder if tc 7.0 will just implements what 3.0 requierements or will be a major evolution ? My wishes for tc 7 and later : A very small core for faster start and better embedded use. Valves/filters/whatever should be just plugable modules. Here also OSGI / Felix / ServiceMixKernel have many good ideas to use. Maven as a build system should be seriously reconsidered, modularity, artifacts depots, osgi support will be easier Tomcat project should use and share components from others ASF projects, Mina, Felix, ServiceMix, Commons have great stuff that could (should) be used. It will even be attractive for new commiters from these ASF project. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
JSR 196 can be implemented only at the service levelIs it true?? -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
Re: Feedback on my project proposal
On Apr 1, 2009, at 9:20 PM, Rahul Saxena wrote: Is Tomcat currently supports JSR 196?? no. I've been planning to work on jsr 196 for tomcat but haven't had much time. I implemented support for jetty. Geronimo has a jsr 196 provider implementation but I haven't been able to pry the tck out of sun yet. I'd doubt there would be a lot of trouble doing the server bits of jsr 196 in a filter. However note that, unlike with web.xml specified filters, authentication occurs once before the request gets to the first web.xml specified filter and does not occur again for dispatches. If you can arrange for this with a filter then the rest of the jsr 196 implementation should not be too hard. thanks david jencks On Thu, Apr 2, 2009 at 3:02 AM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: If we derive several servlets form s generic servlet and then if we specify a filter for that generic servlet, will that filter work for all derived servlets or not??? Filters and servlets are independent. Any filter should work with any servlet. Mark Rahul Saxena B.Tech Part III Computer Science And Engineering IT BHU - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
On Apr 2, 2009, at 12:32 AM, Rahul Saxena wrote: JSR 196 can be implemented only at the service levelIs it true?? not sure exactly what you mean each web app needs something to do its authentication, whether it be a standard FORM/BASIC/DIGEST/ CLIENT_CERT auth thingy or a jsr 196 auth thingy. The auth thingy gets called once per request before the request gets to any filters or servlets. thanks david jencks -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. I read it. It's a new spec. Dot. May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Osgi is getting more and more adoption True. and Eclipse or Felix select Jetty as their http implementation. Back to size / ease of embedding. Maven has never been used as build system and 10 years after Tc is still stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. Probably it didn't help/allow new peoples join the project and add some fresh air ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Good but may be too late ;-( Better late than never. That's why i wonder if tc 7.0 will just implements what 3.0 requierements or will be a major evolution ? My wishes for tc 7 and later : A very small core for faster start and better embedded use. Valves/filters/whatever should be just plugable modules. Here also OSGI / Felix / ServiceMixKernel have many good ideas to use. Maven as a build system should be seriously reconsidered, modularity, artifacts depots, osgi support will be easier Tomcat project should use and share components from others ASF projects, Mina, Felix, ServiceMix, Commons have great stuff that could (should) be used. It will even be attractive for new commiters from these ASF project. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
As you said The auth thingy gets called once per request before the request gets to any filters or servlets.So it means that all the requests will pass through this auth thing and so it would be not be possible to use it for particular hosts or contexts??? On Thu, Apr 2, 2009 at 1:18 PM, David Jencks david_jen...@yahoo.com wrote: On Apr 2, 2009, at 12:32 AM, Rahul Saxena wrote: JSR 196 can be implemented only at the service levelIs it true?? not sure exactly what you mean each web app needs something to do its authentication, whether it be a standard FORM/BASIC/DIGEST/CLIENT_CERT auth thingy or a jsr 196 auth thingy. The auth thingy gets called once per request before the request gets to any filters or servlets. thanks david jencks -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
Re: I Need Your Feedback on my project proposal
Xie Xiaodong wrote: Hello, Dear All, I have posted my revised proposal on the GSOC site for the project Convert current Tomcat valves to Servlet Filters. And I've successfully build the source code Mark provided, and delved myself into it. I'll add the deliverables and timescale to this proposal later. Any comments, feedback and criticism to my proposal are welcomed. GSOC app updated with feedback and repeated here for the archives: Mark Good first draft. Things to consider: 1. Do the StandardEngineValve etc need to be converted to filters? Could the code in these classes just be moved to the StandardEngine etc? 2. For configuration of these filters look at how Tomcat uses a global web.xml (in CATALINA_BASE/conf) and think about how this might be extended. Take a look at how Tomcat does this for global context.xml files, host level context.xml files and per context context.xml files 3. I think you missed my point about ASync support. The question wasn't how/if Tomcat provides the threads to process these requests. The question is what needs to be done to make the filters compatible with ASync support and are there any valves where ASync support may cause issues. Think about the AccessLogValve - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
GSoC questions
Hello, I want to join GSoC project titled Convert current Tomcat valves to Servlet Filters and I just want to ask you some questions about it. 1. Will the work include writing of JUnit tests? If yes, which version? (3, 4) 2. I read that Tomcat uses SVN version control system. Is there any preferred IDE, or can be used NetBeans? 3. In which version of Tomcat (and Java of course) have to be the code implemented? Can I use Java SE 5 features ? (generics, annotations, extended for cycle, extended Java APIs, ...) 4. Which additional technologies I should learn except Java Servlet Filters, Apache Tomcat valves and SVN (I have experience with CVS Eclipse) ? -- View this message in context: http://www.nabble.com/GSoC-questions-tp22843393p22843393.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Some questions about the AccessLogValve
Hello, Dear All, I found that Double-Checked Locking Pattern are heavily used in AccessLogValve to get rid of race condition. But as far as I know, this pattern will not work in Java according to this article: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html. I think this part need to be revised to get rid of race condition for sure. -- Sincerely yours and Best Regards, Xie Xiaodong
Re: [Proposal] Remove older of the two BIO AJP connectors
May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. Up to 2.5/2.1 ? Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. Why should we still get this kind of reply on Tomcat list ? ;-( I won't speak for Costin but I didn't have such time to works on Tomcat. And for such project we need full time people involved. The idea is to attract a community on it and GSoC is a great opportunity. Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. Osgi is getting more and more adoption True. Indeed and Eclipse or Felix select Jetty as their http implementation. Back to size / ease of embedding. Maven has never been used as build system and 10 years after Tc is still stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. That's a reccurent part of the problem on the tomcat-dev list. Why should we change something working ? Maven arguments exist and you just can't say, it works with ant why changing anything ? How many major projects in ASF (and elsewhere) switched to Maven ? It will really help make Tomcat more modular, maven modules will split the complexity in more parts. And modules could became bundles easily via maven-felix-plugin. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. May be but with a big build.xml instead of many small poms ? Probably it didn't help/allow new peoples join the project and add some fresh air ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Good but may be too late ;-( Better late than never. That's why i wonder if tc 7.0 will just implements what 3.0 requierements or will be a major evolution ? My wishes for tc 7 and later : A very small core for faster start and better embedded use. Valves/filters/whatever should be just plugable modules. Here also OSGI / Felix / ServiceMixKernel have many good ideas to use. Maven as a build system should be seriously reconsidered, modularity, artifacts depots, osgi support will be easier Tomcat project should use and share components from others ASF projects, Mina, Felix, ServiceMix, Commons have great stuff that could (should) be used. It will even be attractive for new commiters from these ASF project. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. I'll be happy to spent some personal time (not during my job time), but there should be a real acceptance here. Maven use : I worked some times ago on a mavenised version of Tomcat. As it required a different source structure, I moved all sources to a new layout. And to automatize it, you should use some ant script before so it's clearly unfriendly (and unusual for maven developpers conventions/standardization) Openess : Did the Tomcat community want to share and use components ? Mina could provide some components. Felix could use Tomcat as it HTTP implementation instead of Jetty. ... OSGI : Did Tomcat 7 should use an OSGI core and use it dynamic bundles model to load on demand module (a sort of on demand HTTPd modules) ? The discussion is open and please don't just reply make contributions. Ideas are contributions, not just code. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46950] SSL renegotiation does not occur when resource with CLIENT-CERT auth is requested
https://issues.apache.org/bugzilla/show_bug.cgi?id=46950 Andr an...@cabine.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Andr an...@cabine.org 2009-04-02 03:00:48 PST --- Ok. So now I changed the security-constraint to: security-constraint id=SecurityConstraint_1 web-resource-collection id=WebResourceCollection_1 web-resource-name/ url-pattern/LoginWithCert.do/url-pattern http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodHEAD/http-method /web-resource-collection auth-constraint role-name*/role-name /auth-constraint user-data-constraint id=UserDataConstraint_4 transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Now I get this error when I access the resource: HTTP Status 400 - No client certificate chain in this request BUT no certificate was asked in the SSL (re-)negotiation. -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. Up to 2.5/2.1 ? Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. Why should we still get this kind of reply on Tomcat list ? ;-( Because you are criticizing the direction things are going but making little to no contribution to moving Tomcat forward in the direction you think it should be going. The idea is to attract a community on it and GSoC is a great opportunity. +1. Any help/advice you want to give to the prospective students would be very much appreciated as they as their questions on the dev list. Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. Again, if *you* want to pursue this / think this is a good idea - *you* need to invest the time to pursue this / persuade others that it is worth them pursuing. Maven has never been used as build system and 10 years after Tc is still stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. That's a reccurent part of the problem on the tomcat-dev list. Why should we change something working ? Exactly. If it ain't broke don't fix it. There is always scope to do things better but the reward has to be worth the effort required. That case has yet to be made (in my view) for switching to Maven. Maven arguments exist and you just can't say, it works with ant why changing anything ? They do but the last time someone tried to make them, the argument wasn't compelling. How many major projects in ASF (and elsewhere) switched to Maven ? No idea. It will really help make Tomcat more modular, maven modules will split the complexity in more parts. And modules could became bundles easily via maven-felix-plugin. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. May be but with a big build.xml instead of many small poms ? Which is fine by me right now. If there was a compelling argument to switch to Maven and go through the associated learning curve I would be +1 for the switch. I have yet to see a compelling argument. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. I'll be happy to spent some personal time (not during my job time), Great. but there should be a real acceptance here. You need to make the case for each of these changes. If there is a case then I for one would be +1. Maven use : I worked some times ago on a mavenised version of Tomcat. As it required a different source structure, I moved all sources to a new layout. And to automatize it, you should use some ant script before so it's clearly unfriendly (and unusual for maven developpers conventions/standardization) As I said above, I don't see that the pain is worth the gain. I'm happy to be convinced otherwise. Openess : Did the Tomcat community want to share and use components ? Mina could provide some components. Felix could use Tomcat as it HTTP implementation instead of Jetty. I'm all for code re-use where we can. That is one of the reasons I am working on the Commons components that Tomcat uses. Any re-use is always going to be a trade off. Each case will need to be looked at on it's merits but where it makes sense to do so it will get a +1 from me. OSGI : Did Tomcat 7 should use an OSGI core and use it dynamic bundles model to load on demand module (a sort of on demand HTTPd modules) ? That is an awfully big step from where we are now. How do you propose we get from where we are to a set of bundles running on an OSGI framework? The discussion is open and please don't just reply make contributions. Ideas are contributions, not just code. +1 but without contributions the ideas are unlikely to get anywhere Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: my proposal for re implement tomcat valves as filters
anas Ahmed wrote: Mark Thomas wrote : Feedback: Good first draft. There are a coupe of areas I would like to see more detail on: 1. Impact of Servlet 3 and async processing. Lack of asynchronous support in the Servlet 2.5 specification has caused server vendors to devise workarounds by weaving proprietary classes and interfaces that promote scalable Comet programming into the Servlet 2.5 API.As Servlet 3 support async processing, I think there is no need to Comet programming (CometEvent, CometFilter, CometFilterChain, CometProcessor, CometEventImpl, CometConnectionManagerValve classes are no longer needed). I think others features like annotations will not be useful That wasn't what I meant. What I meant was What needs to be done to make the filters compatible with ASync support and are there any valves where ASync support may cause issues? 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? My idea to handle this is as follow - tracks other component that can be defined at Context and Host, for example HttpServlet (servlet /servlet tag).- read HttpServlet implantation and specification, then try to make implementation to FilterClass implement Filter interface, same as HttpServlet, so Filter can be defined at host level. Then try to make necessary modification on Filter to wide it at Engine level. If I have understood you correctly, you want to modify the Filter interface. This is not possible. The Filter interface is defined by the spec and cannot be changed. Also you appear to indicate that Servlet's can be defined at the Host level. This is not the case. 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? still searching , can you explain more. JSR196 is the Java Authentication Service Provider Interface for Containers. This might be an alternative solution for the authentication valves rather than converting them to filters. Geronimo may already have a solution for this. I haven't checked. http://jcp.org for more info. Mark I would also suggest you spend a little time to build Tomcat from source (http://svn.apache.org/repos/asf/tomcat/trunk). Once you have Tomcat building, I'd suggest looking at the AccessLogValve and how that might be converted to a Filter to give you a better ide of the issues involved and how long things might take. i will do but there is no lot time ,Friday is the last day for submit proposal ,what is the necessary modifications to add them to proposal ? Proposals can be modified after the submission date as you continue to discuss your ideas with us. finally how many students will work in this project? One. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSoC questions
muz.Payne wrote: Hello, I want to join GSoC project titled Convert current Tomcat valves to Servlet Filters and I just want to ask you some questions about it. Great. Welcome to the Tomcat dev community. 1. Will the work include writing of JUnit tests? If yes, which version? (3, 4) Possibly. If so, we are currently using JUnit 3 but that can always be changed if there is a good reason. 2. I read that Tomcat uses SVN version control system. Is there any preferred IDE, or can be used NetBeans? Tomcat does use svn, as do all ASF projects. We can also request a read-only git mirror if that would help. You can use any IDE. 3. In which version of Tomcat (and Java of course) have to be the code implemented? Can I use Java SE 5 features ? (generics, annotations, extended for cycle, extended Java APIs, ...) Tomcat 7. http://svn.apache.org/repos/asf/tomcat/trunk The Servlet 3.0 spec requires Java 6 so any Java 6 features may be used. 4. Which additional technologies I should learn except Java Servlet Filters, Apache Tomcat valves and SVN (I have experience with CVS Eclipse) ? A general familiarization with the Servlet 3.0 specification would be an advantage. I'd also suggest reading the various threads on the dev list that are about this GSOC project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some questions about the AccessLogValve
Xie Xiaodong wrote: Hello, Dear All, I found that Double-Checked Locking Pattern are heavily used in AccessLogValve to get rid of race condition. But as far as I know, this pattern will not work in Java according to this article: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html. I think this part need to be revised to get rid of race condition for sure. Good catch. Looks like we need some volatiles in there. The best thing to do would be: - create a bugzilla entry for this (do it against Tomcat 6) - fix the problems - attach a patch (in diff -u format) to the bugzilla issue - one of the committers will review your patch and apply if it is OK Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Mark Thomas wrote: Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. Again, if *you* want to pursue this / think this is a good idea - *you* need to invest the time to pursue this / persuade others that it is worth them pursuing. The problem with any framework is that with all the benefits you pay the price. One is that it contain things you will absolutely never need or use, and the second is that you depend on the framework, so anything you need to add or fix its other community dependent. Unless at least three of us become the mina's pmc members that can push for a release, we would put ourself is the 'plug and pray' situation. However that doesn't prevent anyone with extra time and will to create the mina based connector, but of course as a separate module not part of the core. In time this would eventually lead to satisfying the first requirement, and eventually use it as core component. IMHO we had a good example in http-client, where two communities even under ASF umbrella simply couldn't cooperate. The guys from http commons simply choose to take a blank sheet of paper and completely break the backward compatibility, leaving us sticked to version 3. Of course we could use version 4 (it was beta for how long, two years or more) since now released, but who can assure us version 4.1 won't make all our work obsolete again. And, regarding maven, I absolutely agree with Mark. There is nothing wrong with ant, and really see no reason why would the switch be needed. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Convert Valves 2 Servlet Filters
1- What is the main idea behind converting Current working Valves to Servlet Filters. 2- What are the benifits from that work to the Tomcat. 3- What will be like Tomcat with having Filters than having Valves.(For what reason Valves should be converted to Filters)
Re: Convert Valves 2 Servlet Filters
buddhi wickramarathne wrote: 1- What is the main idea behind converting Current working Valves to Servlet Filters. Valves are Tomcat specific. Filters can be used with any container. 2- What are the benifits from that work to the Tomcat. Remove duplication. Valve pipeline is very similar to filter chain. 3- What will be like Tomcat with having Filters than having Valves.(For what reason Valves should be converted to Filters) Greater modularity and scope for re-use. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r761257 - /tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java
Author: markt
Date: Thu Apr 2 11:58:51 2009
New Revision: 761257
URL: http://svn.apache.org/viewvc?rev=761257view=rev
Log:
Tabs - 8 spaces
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java?rev=761257r1=761256r2=761257view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/ELNode.java Thu Apr 2
11:58:51 2009
@@ -44,21 +44,21 @@
*/
public static class Root extends ELNode {
- private ELNode.Nodes expr;
+private ELNode.Nodes expr;
private char type;
- Root(ELNode.Nodes expr, char type) {
- this.expr = expr;
+Root(ELNode.Nodes expr, char type) {
+this.expr = expr;
this.type = type;
- }
+}
- public void accept(Visitor v) throws JasperException {
- v.visit(this);
- }
-
- public ELNode.Nodes getExpression() {
- return expr;
- }
+public void accept(Visitor v) throws JasperException {
+v.visit(this);
+}
+
+public ELNode.Nodes getExpression() {
+return expr;
+}
public char getType() {
return type;
@@ -70,19 +70,19 @@
*/
public static class Text extends ELNode {
- private String text;
+private String text;
- Text(String text) {
- this.text = text;
- }
-
- public void accept(Visitor v) throws JasperException {
- v.visit(this);
- }
-
- public String getText() {
- return text;
- }
+Text(String text) {
+this.text = text;
+}
+
+public void accept(Visitor v) throws JasperException {
+v.visit(this);
+}
+
+public String getText() {
+return text;
+}
}
/**
@@ -91,19 +91,19 @@
*/
public static class ELText extends ELNode {
- private String text;
+private String text;
- ELText(String text) {
- this.text = text;
- }
-
- public void accept(Visitor v) throws JasperException {
- v.visit(this);
- }
-
- public String getText() {
- return text;
- }
+ELText(String text) {
+this.text = text;
+}
+
+public void accept(Visitor v) throws JasperException {
+v.visit(this);
+}
+
+public String getText() {
+return text;
+}
}
/**
@@ -113,61 +113,61 @@
*/
public static class Function extends ELNode {
- private String prefix;
- private String name;
- private String uri;
- private FunctionInfo functionInfo;
- private String methodName;
- private String[] parameters;
-
- Function(String prefix, String name) {
- this.prefix = prefix;
- this.name = name;
- }
-
- public void accept(Visitor v) throws JasperException {
- v.visit(this);
- }
-
- public String getPrefix() {
- return prefix;
- }
-
- public String getName() {
- return name;
- }
-
- public void setUri(String uri) {
- this.uri = uri;
- }
-
- public String getUri() {
- return uri;
- }
-
- public void setFunctionInfo(FunctionInfo f) {
- this.functionInfo = f;
- }
-
- public FunctionInfo getFunctionInfo() {
- return functionInfo;
- }
-
- public void setMethodName(String methodName) {
- this.methodName = methodName;
- }
-
- public String getMethodName() {
- return methodName;
- }
-
- public void setParameters(String[] parameters) {
- this.parameters = parameters;
- }
-
- public String[] getParameters() {
- return parameters;
- }
+private String prefix;
+private String name;
+private String uri;
+private FunctionInfo functionInfo;
+private String methodName;
+private String[] parameters;
+
+Function(String prefix, String name) {
+this.prefix = prefix;
+this.name = name;
+}
+
+public void accept(Visitor v) throws JasperException {
+v.visit(this);
+}
+
+public String getPrefix() {
+return prefix;
+}
+
+public String getName() {
+return name;
+}
+
+public void setUri(String uri) {
+this.uri = uri;
+}
+
+public String getUri() {
+return uri;
+}
+
+public void setFunctionInfo(FunctionInfo f) {
+this.functionInfo = f;
+}
+
Re: I Need Your Feedback on my project proposal
Thank you very much for your valuable comments, Mark. I've revised my proposal according to your comments, and added the deliverables and time schedule part. Any more comments, feedback and criticism to my proposal are welcomed. 2009/4/2 Mark Thomas ma...@apache.org Xie Xiaodong wrote: Hello, Dear All, I have posted my revised proposal on the GSOC site for the project Convert current Tomcat valves to Servlet Filters. And I've successfully build the source code Mark provided, and delved myself into it. I'll add the deliverables and timescale to this proposal later. Any comments, feedback and criticism to my proposal are welcomed. GSOC app updated with feedback and repeated here for the archives: Mark Good first draft. Things to consider: 1. Do the StandardEngineValve etc need to be converted to filters? Could the code in these classes just be moved to the StandardEngine etc? 2. For configuration of these filters look at how Tomcat uses a global web.xml (in CATALINA_BASE/conf) and think about how this might be extended. Take a look at how Tomcat does this for global context.xml files, host level context.xml files and per context context.xml files 3. I think you missed my point about ASync support. The question wasn't how/if Tomcat provides the threads to process these requests. The question is what needs to be done to make the filters compatible with ASync support and are there any valves where ASync support may cause issues. Think about the AccessLogValve -- Sincerely yours and Best Regards, Xie Xiaodong
Re: Feedback on my project proposal
It was a mistake I wrote servlet context of this particular servlet . Also as we have default host for a particular engine , we can have a default context for a particular host , then pass its servlet context to the filter , then can we map all servlets in this host to this filter or the servlets in this particular context only can be mapped ??? On Thu, Apr 2, 2009 at 3:55 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
svn commit: r761336 - in /tomcat/trunk/java/org/apache/jasper/compiler: Compiler.java ELFunctionMapper.java Generator.java
Author: markt
Date: Thu Apr 2 16:21:00 2009
New Revision: 761336
URL: http://svn.apache.org/viewvc?rev=761336view=rev
Log:
Misc code clean-up. Remove unused parameters / exceptions etc.
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
tomcat/trunk/java/org/apache/jasper/compiler/ELFunctionMapper.java
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=761336r1=761335r2=761336view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Thu Apr 2
16:21:00 2009
@@ -209,7 +209,7 @@
TextOptimizer.concatenate(this, pageNodes);
// Generate static function mapper codes.
-ELFunctionMapper.map(this, pageNodes);
+ELFunctionMapper.map(pageNodes);
// generate servlet .java file
writer = setupContextWriter(javaFileName);
@@ -398,9 +398,8 @@
+ (ctxt.getOptions().getModificationTestInterval() * 1000)
System
.currentTimeMillis()) {
return false;
-} else {
-jsw.setLastModificationTest(System.currentTimeMillis());
}
+jsw.setLastModificationTest(System.currentTimeMillis());
}
long jspRealLastModified = 0;
Modified: tomcat/trunk/java/org/apache/jasper/compiler/ELFunctionMapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/ELFunctionMapper.java?rev=761336r1=761335r2=761336view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/ELFunctionMapper.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/ELFunctionMapper.java Thu Apr
2 16:21:00 2009
@@ -38,10 +38,9 @@
/**
* Creates the functions mappers for all EL expressions in the JSP page.
*
- * @param compiler Current compiler, mainly for accessing error dispatcher.
* @param page The current compilation unit.
*/
-public static void map(Compiler compiler, Node.Nodes page)
+public static void map(Node.Nodes page)
throws JasperException {
ELFunctionMapper map = new ELFunctionMapper();
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=761336r1=761335r2=761336view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Thu Apr 2
16:21:00 2009
@@ -164,7 +164,7 @@
return b.toString();
}
-private String createJspId() throws JasperException {
+private String createJspId() {
if (this.jspIdPrefix == null) {
StringBuffer sb = new StringBuffer(32);
String name = ctxt.getServletJavaFileName();
@@ -459,7 +459,7 @@
* Generate preamble package name (shared by servlet and tag handler
* preamble generation)
*/
-private void genPreamblePackage(String packageName) throws JasperException
{
+private void genPreamblePackage(String packageName) {
if (!.equals(packageName) packageName != null) {
out.printil(package + packageName + ;);
out.println();
@@ -470,7 +470,7 @@
* Generate preamble imports (shared by servlet and tag handler preamble
* generation)
*/
-private void genPreambleImports() throws JasperException {
+private void genPreambleImports() {
IteratorString iter = pageInfo.getImports().iterator();
while (iter.hasNext()) {
out.printin(import );
@@ -486,7 +486,7 @@
* list, el function map, prefix map. (shared by servlet and tag handler
* preamble generation)
*/
-private void genPreambleStaticInitializers() throws JasperException {
+private void genPreambleStaticInitializers() {
out.printil(private static final JspFactory _jspxFactory =
JspFactory.getDefaultFactory(););
out.println();
@@ -519,7 +519,7 @@
*
* In JSP 2.1, we also scope an instance of ExpressionFactory
*/
-private void genPreambleClassVariableDeclarations() throws JasperException
{
+private void genPreambleClassVariableDeclarations() {
if (isPoolingEnabled !tagHandlerPoolNames.isEmpty()) {
for (int i = 0; i tagHandlerPoolNames.size(); i++) {
out.printil(private org.apache.jasper.runtime.TagHandlerPool
@@ -540,7 +540,7 @@
* Declare general-purpose methods (shared by servlet
svn commit: r761338 - /tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
Author: markt
Date: Thu Apr 2 16:22:13 2009
New Revision: 761338
URL: http://svn.apache.org/viewvc?rev=761338view=rev
Log:
Fix litmus test failure:
MKCOL with weird body must fail with 415 (RFC2518:8.3.1)
Modified:
tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
Modified: tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java?rev=761338r1=761337r2=761338view=diff
==
--- tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java Thu Apr
2 16:22:13 2009
@@ -734,7 +734,7 @@
return;
}
-if (req.getInputStream().available() 0) {
+if (req.getContentLength() 0) {
DocumentBuilder documentBuilder = getDocumentBuilder();
try {
// Document document =
@@ -745,7 +745,7 @@
} catch(SAXException saxe) {
// Parse error - assume invalid content
-resp.sendError(WebdavStatus.SC_BAD_REQUEST);
+resp.sendError(WebdavStatus.SC_UNSUPPORTED_MEDIA_TYPE);
return;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some questions about the AccessLogValve
Hello, Mark, I am greatly with you. After I finish my proposal, I will check carefully what is the best way to solve this problem. 2009/4/2 Mark Thomas ma...@apache.org Xie Xiaodong wrote: Hello, Dear All, I found that Double-Checked Locking Pattern are heavily used in AccessLogValve to get rid of race condition. But as far as I know, this pattern will not work in Java according to this article: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.htmlhttp://www.cs.umd.edu/%7Epugh/java/memoryModel/DoubleCheckedLocking.html. I think this part need to be revised to get rid of race condition for sure. Good catch. Looks like we need some volatiles in there. The best thing to do would be: - create a bugzilla entry for this (do it against Tomcat 6) - fix the problems - attach a patch (in diff -u format) to the bugzilla issue - one of the committers will review your patch and apply if it is OK Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Sincerely yours and Best Regards, Xie Xiaodong
DO NOT REPLY [Bug 46957] New: Memory leak: tags in JSPs don't release Page Context
https://issues.apache.org/bugzilla/show_bug.cgi?id=46957
Summary: Memory leak: tags in JSPs don't release Page Context
Product: Tomcat 6
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: martin.r...@centrum.cz
During investigation of memory leaks in our web-application I was checking heap
using jhat and I found that the biggest memory leak is caused by tomcat itself.
Heap contain big amount of instances of class PageContextImpl (over 1000).
These instances reference JspWriterImpl (property baseOut) which reference huge
buffer (property cb which in our case has 1MB size - in total these buffers use
over 1GB).
This situation happens during big load, my understanding (might be wrong) of
the situation is that pool containing Page Contexts is not big enough which
causes bigger number of page contexts being created and then released. But most
of them stay referenced by jsp classes via tag handlers so they can't be
garbage collected.
Partial fix could be done in method
org.apache.jasper.runtime.TagHandlerPool.reuse(Tag handler)
adding following code line at the begining of the method:
handler.setPageContext(null);
This fixes simple jsp like this:
%...@taglib prefix=c uri=http://java.sun.com/jsp/jstl/core%
c:if test=${true}
Test message
/c:if
I've tested this patch and checked via jhat, reference is removed. But the
problem still remains for jsp with nested tags. My guess is that some fix
should be done in part generating servlet code from JSP to remove all
references to Page Context once the servlet finishes it's service method.
--
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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSoC questions
markt-2 wrote: muz.Payne wrote: Hello, I want to join GSoC project titled Convert current Tomcat valves to Servlet Filters and I just want to ask you some questions about it. Great. Welcome to the Tomcat dev community. 1. Will the work include writing of JUnit tests? If yes, which version? (3, 4) Possibly. If so, we are currently using JUnit 3 but that can always be changed if there is a good reason. 2. I read that Tomcat uses SVN version control system. Is there any preferred IDE, or can be used NetBeans? Tomcat does use svn, as do all ASF projects. We can also request a read-only git mirror if that would help. You can use any IDE. 3. In which version of Tomcat (and Java of course) have to be the code implemented? Can I use Java SE 5 features ? (generics, annotations, extended for cycle, extended Java APIs, ...) Tomcat 7. http://svn.apache.org/repos/asf/tomcat/trunk The Servlet 3.0 spec requires Java 6 so any Java 6 features may be used. 4. Which additional technologies I should learn except Java Servlet Filters, Apache Tomcat valves and SVN (I have experience with CVS Eclipse) ? A general familiarization with the Servlet 3.0 specification would be an advantage. I'd also suggest reading the various threads on the dev list that are about this GSOC project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org I tried to connect to SVN repositories, but it do not work... What are user password? Are they anonymous, blank? -- View this message in context: http://www.nabble.com/GSoC-questions-tp22843393p22853864.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
I wouldn't be that concerned about configuration - tomcat can still instantiate the filter independent of web.xml, like it does with the valve. Or the filter could be used 'user-space', i.e. user adding the filter explicitly and not using the declarative security. One of the problems with tomcat auth interfaces is that it is modeled around 'user database' ( i.e. a store for users/credentials) and pretty tied to basic/form models. This also makes the auth implementation quite dependent of tomcat internals. An alternative would be to just define a small interface that allows the filter to populate Principal and hook into 'isUserInRole' ( this can be independent of tomcat ). You could do cool stuff like support openID/google/etc authentication, have the credentials on an external server (so a tomcat instance will not have access to the user DB ), etc. The good news is that you could do most of the work without change to tomcat source - just plain filters, you can just extract interesting impl. code from the valves. If you get this to work completely user-space ( you can test that by using the filter in jetty for example ), then we can figure out the few HttpServletRequest methods that need extra interaction. Costin On Thu, Apr 2, 2009 at 7:58 AM, Rahul Saxena rahul.saxena.cs...@itbhu.ac.in wrote: It was a mistake I wrote servlet context of this particular servlet . Also as we have default host for a particular engine , we can have a default context for a particular host , then pass its servlet context to the filter , then can we map all servlets in this host to this filter or the servlets in this particular context only can be mapped ??? On Thu, Apr 2, 2009 at 3:55 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
DO NOT REPLY [Bug 34110] The message SEVERE: Error listenerStart should be more explicit
https://issues.apache.org/bugzilla/show_bug.cgi?id=34110 --- Comment #3 from Dan Armbrust daniel.armbrust.l...@gmail.com 2009-04-02 13:48:36 PST --- I ran into this issue where tomcat was not giving me any information to go on with one of my webapps. After a long search, documented here: http://marc.info/?t=12386172052r=1w=2 we discovered that the sequence of events which leads tomcat to not log any debug information about the error is as follows: You deploy a war file to tomcat which includes log4j.jar, and has a listener declared in the web.xml file. The listener in the web.xml file points to a class that doesn't exist. This will cause the deployment to fail. The war file that you deploy does _NOT_ include a log4j.properties or log4j.xml file in the WEB-INF/classes folder - presumably because your webapp dynamically configures log4j in a different manner. The end result is, there is some period of time during deployment of the webapp when tomcat attempts to log deployment messages to log4j which was supplied by your webapp - but since the log4j within the webapp is not yet configured, the messages are lost. I'm not sure if there is anything that can be done to improve this situation. An obvious solution for me is to supply a log4j.properties file which will be used to configure log4j for the short period of time before my dynamic configuration runs. But it seems like Tomcat should always log issues during deployment into its own logging system, rather than trying to send them into the webapps logging system. Here is a vote to re-open this bug. -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 34110] The message SEVERE: Error listenerStart should be more explicit
https://issues.apache.org/bugzilla/show_bug.cgi?id=34110 Dan Armbrust daniel.armbrust.l...@gmail.com changed: What|Removed |Added CC||daniel.armbrust.l...@gmail. ||com -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46958] New: manager XML interface hard-coded path in XSL transformation
https://issues.apache.org/bugzilla/show_bug.cgi?id=46958
Summary: manager XML interface hard-coded path in XSL
transformation
Product: Tomcat 6
Version: 6.0.18
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Manager application
AssignedTo: dev@tomcat.apache.org
ReportedBy: photod...@gmail.com
The manager XML-interface cannot be used if it's installed under any other path
than /manager, failing to find the xform.xsl file needed for XSL
transformation.
Fails:
http://example.com/mymanager/status?XML=true
Works:
http://example.com/manager/status?XML=true
Reason for error, in Tomcat sources
org.apache.catalina.manager.Constants
XML_STYLE returns the constant value
?xml-stylesheet type=\text/xsl\ href=\/manager/xform.xsl\ ?;
The /manager part needs to be modified to match webapp path.
Caller:
org.apache.catalina.util.RequestUtil.StatusTransformer
public static void writeHeader(PrintWriter writer, final String contextPath,
int mode) {
//...
// TODO needs current virtual webapp path as parameter
writer.write(Constants.XML_STYLE);
}
On a sidenote, in org.apache.catalina.manager.host.Constants there is a similar
hard-coded value, which might cause similar problems in the future. It seems to
be unreferenced in the current sources right now (unused value).
--
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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: If i recall the tomcat story (10 years). Today Sun has it's own implementation, Grizzly. Jboss forked tc code in it's own implémentation for AS. Spring Source embed it in it's DM server. It's disturbing that you fail to mention Geronimo altogether. If we can't have cohesion within the ASF - you expect to create it externally? That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. It takes outreach to make that happen. Mark isn't offbase, keep posting your wishes here, but if you want to make it happen, engage these other communities. The ASF isn't about being the only code solution. It's about collaboration to create what the active developers determine is the best solution. If anything is lacking in Tomcat, address it, and work with others to address it, but certainly don't spend your time wishing things were otherwise. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
William A. Rowe, Jr. wr...@rowe-clan.net wrote in message news:49d55f2c.2030...@rowe-clan.net... Henri Gomez wrote: If i recall the tomcat story (10 years). Today Sun has it's own implementation, Grizzly. Jboss forked tc code in it's own implémentation for AS. Spring Source embed it in it's DM server. It's disturbing that you fail to mention Geronimo altogether. If we can't have cohesion within the ASF - you expect to create it externally? I think that where Henri is going is that Tomcat has always been dependant on corporate sponsorship. First on Sun (who forked the code to GlassFish), then on JBoss (whom I understand from messages on the list has forked as well), and currently on SpringSource. Geronimo has historically considered Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has changed recently, and we're getting more patch submissions from Geronimo. But AFAIK, there are still no committers to both Tomcat and Geronimo. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. It takes outreach to make that happen. Mark isn't offbase, keep posting your wishes here, but if you want to make it happen, engage these other communities. The ASF isn't about being the only code solution. It's about collaboration to create what the active developers determine is the best solution. If anything is lacking in Tomcat, address it, and work with others to address it, but certainly don't spend your time wishing things were otherwise. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSoC questions
muz.Payne wrote I tried to connect to SVN repositories, but it do not work... create a folder in your local partition name it as u want check out with the url for the trunk to that folder What are user password? Are they anonymous, blank? no user name password need
Re: Feedback on my project proposal
As you said An alternative would be to just define a small interface that allows the filter to populate ,does that mean defining an interface in the default context for that host , and the filter can be instantiated using servlet context for this default web app(context) and then allow users to explicitely define how and where to map these filtersCan't we make any arrangement so that the filter could work for all contexts in this particular host by default ?? On Fri, Apr 3, 2009 at 1:36 AM, Costin Manolache cos...@gmail.com wrote: I wouldn't be that concerned about configuration - tomcat can still instantiate the filter independent of web.xml, like it does with the valve. Or the filter could be used 'user-space', i.e. user adding the filter explicitly and not using the declarative security. One of the problems with tomcat auth interfaces is that it is modeled around 'user database' ( i.e. a store for users/credentials) and pretty tied to basic/form models. This also makes the auth implementation quite dependent of tomcat internals. An alternative would be to just define a small interface that allows the filter to populate Principal and hook into 'isUserInRole' ( this can be independent of tomcat ). You could do cool stuff like support openID/google/etc authentication, have the credentials on an external server (so a tomcat instance will not have access to the user DB ), etc. The good news is that you could do most of the work without change to tomcat source - just plain filters, you can just extract interesting impl. code from the valves. If you get this to work completely user-space ( you can test that by using the filter in jetty for example ), then we can figure out the few HttpServletRequest methods that need extra interaction. Costin On Thu, Apr 2, 2009 at 7:58 AM, Rahul Saxena rahul.saxena.cs...@itbhu.ac.in wrote: It was a mistake I wrote servlet context of this particular servlet . Also as we have default host for a particular engine , we can have a default context for a particular host , then pass its servlet context to the filter , then can we map all servlets in this host to this filter or the servlets in this particular context only can be mapped ??? On Thu, Apr 2, 2009 at 3:55 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645 -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U. ,Varanasi Contact No.-09452196645
Re: Feedback on my project proposal
On Thu, Apr 2, 2009 at 10:08 PM, Rahul Saxena rahul.saxena.cs...@itbhu.ac.in wrote: As you said An alternative would be to just define a small interface that allows the filter to populate ,does that mean defining an interface in the default context for that host , and the filter can be instantiated using servlet context for this default web app(context) and then allow users to explicitely define how and where to map these filtersCan't we make any arrangement so that the filter could work for all contexts in this particular host by default ?? Sure - there are ways to do this, my point is that this is a secondary issue (IMO). You could write a FilterToValve bridge for example, and any Filter could be used instead of a Valve using current config. Redefining how things are configured can be an interesting project, but it's a different one. Costin On Fri, Apr 3, 2009 at 1:36 AM, Costin Manolache cos...@gmail.com wrote: I wouldn't be that concerned about configuration - tomcat can still instantiate the filter independent of web.xml, like it does with the valve. Or the filter could be used 'user-space', i.e. user adding the filter explicitly and not using the declarative security. One of the problems with tomcat auth interfaces is that it is modeled around 'user database' ( i.e. a store for users/credentials) and pretty tied to basic/form models. This also makes the auth implementation quite dependent of tomcat internals. An alternative would be to just define a small interface that allows the filter to populate Principal and hook into 'isUserInRole' ( this can be independent of tomcat ). You could do cool stuff like support openID/google/etc authentication, have the credentials on an external server (so a tomcat instance will not have access to the user DB ), etc. The good news is that you could do most of the work without change to tomcat source - just plain filters, you can just extract interesting impl. code from the valves. If you get this to work completely user-space ( you can test that by using the filter in jetty for example ), then we can figure out the few HttpServletRequest methods that need extra interaction. Costin On Thu, Apr 2, 2009 at 7:58 AM, Rahul Saxena rahul.saxena.cs...@itbhu.ac.in wrote: It was a mistake I wrote servlet context of this particular servlet . Also as we have default host for a particular engine , we can have a default context for a particular host , then pass its servlet context to the filter , then can we map all servlets in this host to this filter or the servlets in this particular context only can be mapped ??? On Thu, Apr 2, 2009 at 3:55 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rahul Saxena B.Tech Part III Computer Science and Engineering I.T. B.H.U.
