Re: [Proposal] Remove older of the two BIO AJP connectors

[Henri Gomez]

Le 30 mars 09 à 18:00, Mark Thomas  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

[Rahul Saxena]

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

[David Jencks]

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

[David Jencks]

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

[Rahul Saxena]

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

[Mark Thomas]

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

[Rahul Saxena]

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

[Mark Thomas]

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

[muz.Payne]

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

[Xie Xiaodong]

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

[Henri Gomez]

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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=46950


Andr  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Comment #2 from Andr   2009-04-02 03:00:48 PST ---
Ok. So now I changed the security-constraint to:



/LoginWithCert.do
DELETE
GET
POST
PUT
HEAD


*


CONFIDENTIAL



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

[Mark Thomas]

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"

[Mark Thomas]

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

[Mark Thomas]

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

[Mark Thomas]

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

[Mark Thomas]

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

[Mladen Turk]

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

[buddhi wickramarathne]

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

[Mark Thomas]

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

[markt]

Author: markt
Date: Thu Apr  2 11:58:51 2009
New Revision: 761257

URL: http://svn.apache.org/viewvc?rev=761257&view=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=761257&r1=761256&r2=761257&view=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

[Xie Xiaodong]

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 

> 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

[Rahul Saxena]

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

[markt]

Author: markt
Date: Thu Apr  2 16:21:00 2009
New Revision: 761336

URL: http://svn.apache.org/viewvc?rev=761336&view=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=761336&r1=761335&r2=761336&view=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=761336&r1=761335&r2=761336&view=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=761336&r1=761335&r2=761336&view=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() {
 Iterator 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 method

svn commit: r761338 - /tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java

[markt]

Author: markt
Date: Thu Apr  2 16:22:13 2009
New Revision: 761338

URL: http://svn.apache.org/viewvc?rev=761338&view=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=761338&r1=761337&r2=761338&view=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

[Xie Xiaodong]

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 

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


-- 
Sincerely yours and Best Regards,
Xie Xiaodong

DO NOT REPLY [Bug 46957] New: Memory leak: tags in JSPs don't release Page Context

[bugzilla]

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"%>

   Test message


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

[muz.Payne]

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

[Costin Manolache]

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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=34110





--- Comment #3 from Dan Armbrust   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=12386172052&r=1&w=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

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=34110


Dan Armbrust  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

[bugzilla]

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 
"";

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

Tomcat website IRC address

[Photodeus]

Hello,
as I was reading on how to submit a bug report, I noticed that the page
http://tomcat.apache.org/bugreport.html links to a non-existing IRC server.

On the left hand side navigation there's a separate link to Freenode, so the
broken link should be removed.
Didn't seem appropriate to open up a full bug report for such a minor thing.


Regards,
-- 
Seppo Vuolteenaho
Photodeus.com

Re: [Proposal] Remove older of the two BIO AJP connectors

[William A. Rowe, Jr.]

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

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

[billbarker]

Author: billbarker
Date: Fri Apr  3 02:29:16 2009
New Revision: 761506

URL: http://svn.apache.org/viewvc?rev=761506&view=rev
Log:
remove objection and votes

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=761506&r1=761505&r2=761506&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr  3 02:29:16 2009
@@ -68,14 +68,7 @@
   http://svn.apache.org/viewvc?rev=721886&view=rev (original)
   http://svn.apache.org/viewvc?rev=746425&view=rev (to address Bill's concerns)
   http://svn.apache.org/viewvc?rev=757335&view=rev (to remove the Catalina dep)
-  +1: markt
-   0: billbarker: Haven't tried to break it yet, but the 4th patch potentially
-  offers access to static fields in ELContextImpl and ELResolverImpl that 
could 
-  possibly be exploited by a malicious webapp.
-  -1: billbarker: The 5th patch makes Jasper depend on Catalina, rendering 
Jasper useless
-  to any 3rd party that just wants a JSP compiler.  Removing the Catalina 
dependancy
-  can change my vote to +1 (although, it means trusting modern JVMs to 
clean up after
-  themselves efficiently).
+  +1: markt, billbarker
 
 * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46351
   Build script re-factoring
@@ -96,7 +89,7 @@
 * Use some already existing constants instead of explicit
   numbers in the AJP connectors. Backport of
   http://svn.apache.org/viewvc?rev=757706&view=rev
-  +1: rjung, markt
+  +1: rjung, markt, billbarker
   -1:
 
 * Allow huge request body packets for AJP13.
@@ -144,11 +137,13 @@
 This is not for invalidation, only for displaying
 idle times and making persistance decisions.
   +1: rjung, markt
+   0: billbarker: generally agree with remm that this is too big of a change 
for the stable branch
+ but could agree to some of it if it was split into parts
   -1: remm: no for TC 6.0
 
 * Fix typo in OPTIONS response
   http://svn.apache.org/viewvc?rev=757774&view=rev
-  +1: markt, rjung
+  +1: markt, rjung, billbarker
   -1: 
 
 * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46908
@@ -167,7 +162,9 @@
 * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46866
   http://svn.apache.org/viewvc?rev=758596&view=rev
   Better init of Random objects
-  +1: markt, rjung
+  +1: markt, rjung, billbarker
+  billbarker:  This is more like a +0.5, since Random isn't that secure in 
the first place.
+   But the patch seems harmless, so I'll support 
itch-scraching.
   -1: 
 
 * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46822



-
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

[Bill Barker]

"William A. Rowe, Jr."  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

[buddhi wickramarathne]

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

[Rahul Saxena]

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

[Costin Manolache]

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

Re: Feedback on my project proposal

[Rahul Saxena]

I have made appropriate changes in my application resulting from discussion
in the tomcat dev community. Also I further welcome any more comments on
it.

Thanks



-- 
Rahul Saxena
B.Tech Part III
Computer Science and Engineering
I.T. B.H.U. ,Varanasi
Contact No.-09452196645

[GSOC] Filters & Async Support in Servlet 3.0

[anas Ahmed]

Hello all,
As i have  read from Servlet 3.0 specification about filters "A Filter and the 
target servlet or resource at the end of the filter chain must execute in the 
same invocation thread".

This mean if there are many Async Requests which are connected to filters, many 
filters will be init but  not destroyed until response come back or filter work 
finish.
As we know Tomcat uses thread per request through Java NIO.
More simultaneous requests(connected to filters) cause more threads to be 
consumed, which cancels out the benefit of the thread-per-request approach to a 
high degree.

This is my understanding  please correct to me if there are mistake?
Anas Ahmed

_
Rediscover Hotmail®: Get e-mail storage that grows with you. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage1_042009