test

[Kevin Wang]

Hi,
 test a 
test
 
Regards
-kw

  
  

  


  


  


   
  Qiang(Kevin) WangSoftware 
Engineer Phone: 8610.85281188.1564 Mobile: 
86.13910673958 Yahoo_IM/other: wiseking_wq[EMAIL PROTECTED]
  
  
BEA Systems (China) 
Ltd.11F, China Life Tower No. 16 Chao Wai Da 
Jie,Beijing 100020, China Fax: 86. 
85251008www.bea.com.cn
dev2dev.bea.com.cn
  

  

   
  
 
 
 

DO NOT REPLY [Bug 37351] New: - ORM support in Tomcat

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: ORM support in Tomcat
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


any plans to support ORM?
I suppose ORM is now fundamental part of webapp development.
Its natural that tomcat somehow support ORM in some way by default.
Not to mention Ruby on Rails is gaining reputation.

lot of work needs to be done when using hibernate.
I know its hibernates fault not tomcat, but I guess something can be done on 
the tomcat end.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Persistent "xmlValidation" Problem

[Bob Bronson]

- Original Message - 
From: "Frank W. Zammetti" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Thursday, November 03, 2005 10:53 PM
Subject: Re: Persistent "xmlValidation" Problem


I'm just guessing here, and maybe I'm wrong, but I don't think this 
post is going to get you a whole lot of help in answering your 
questions.


Maybe it will, I don't know, but I'm thinking not.

Frank





Who cares? I'm through w/TC. Good riddence.






Bob Bronson wrote:

Comments below, for any of you who care


- Original Message - From: "Jeanfrancois Arcand" 
<[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Tuesday, November 01, 2005 9:11 AM
Subject: Re: Persistent "xmlValidation" Problem



Hi,

Bob Bronson wrote:


Hello,

Sorry, to bother the developer group with this question but I 
posted twice on the user group and received zero replies. I was 
hoping one of you could offer some quick advice on this question.

-
I'm using TC 5.5.12.
Please look at this snippet from the server.xml that is 
distributed

with TC:

 
  


Can anyone tell me what the 'xmlValidation' attribute on  is 
for?
I realize it has something to do with "XML validation", but what 
XML is

it referring to? Is it the corresponding web.xml?



Yes it is.

And how does the


'xmlNamespaceAware' attribute fit in?



You can decide to validate with or without namespace.



And what's the comment about the Xerces 2.2 parser?



For a long time, Xerces was broken/buggy when used in Tomcat.

'm using Sun's JDK


1.5.0. Does it use Xerces internally?



Yes it does.






Thanks for the mostly useless reply. I was hoping (silly me) that 
since

the 'xmlValidation' attribute is completely undocumented
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html), one of 
the
Tomcat programmers could go into more detail about whether it works 
and
any sublties involved in its use (e.g., any JDK dependecies). 
Setting
it to 'true' results in a lot of stack traces when validating my 
simple

web.xml.

Here's something that illustrates the sloppiness of Tomcat 
programmers:


I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I
went into the server.xml that is distributed with TC and changed the
'xmlValidation' attribute value to "true" on the  attribute. 
What

do you think happened? I got tons of meaningless stack traces. This
tells me one of two things -- either the sloppy Tomcat open sores
programmers released an invalid web.xml that doesn't validate *OR* 
that

the 'xmlValidation' functionality is broken.

The fact that Tomcat 5.5.12 was released with this very basic (admit
it, it's not a subtle issue) problem indicates to me the poor state 
of

testing the Tomcat programmers must do at a system level.








When I set the 'xmlValidation' attribute to 'true' I get a big 
stack
trace. One would think it might be appropriate to offer a nice 
error

message describing the problem.



Blame Xerces ;-). XML error are not always easy to discover.





You say that the lousy XML error messages are something I should 
"blame
on Xerces". That response is a lazy copout which is *SO TYPICAL* of 
the
arrogant programmers working on open sores projects. I don't blame 
the

error messages on Xerces, I blame them on lazy, sloppy open sores
Tomcat programmers -- too lazy to test even basic aspects of their
system (like XML validation), too lazy to keep the documentation of
their product up to date, too lazy to GENERATE VALID, MEANINGFUL 
ERROR
MESSAGES rather than just dumping a stack trace from Xerces, too 
lazy
to look into any problems that don't interest them. (Hey, they're 
not

getting paid, why should they bother with things that don't interest
them? -- That seems to be the Open Source Programmer's Manifesto).






I've looked at the latest TC documentation for  and it makes 
no

mention of the 'xmlValidation' attribute:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html



That's a problem. I will take a look.



Can someone please explain these two attributes? My web.xml is 
getting

unwieldy and I'd like to start validating it.



In short, set those two values to true. If you are seeing 
exception, then it means your web.xml is not properly written. Try 
using Netbeans/Eclipse (or any IDE). It is much more easy.





Another lazy copout!! Even the web.xml that is distributed w/Tomcat
does not validate! Did you even test this before you replied to my 
note

or did you just assume the user was at fault???


When someone criticizes the poor state of an open sores project (as 
I
am doing now), the typical response from the open sores programmer 
is

to shift responsibility to the user -- the user is often told to dig
through the change logs or browse the forum archives or even to fix 
the

bug/documentation themselves instead of "complaining". What an
unprofessional, lazy attitude from programmers! The open sores
programmers try to cast *their* laziness as the u

Re: Persistent "xmlValidation" Problem

[Frank W. Zammetti]

I'm just guessing here, and maybe I'm wrong, but I don't think this post 
is going to get you a whole lot of help in answering your questions.


Maybe it will, I don't know, but I'm thinking not.

Frank

Bob Bronson wrote:

Comments below, for any of you who care


- Original Message - From: "Jeanfrancois Arcand" 
<[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Tuesday, November 01, 2005 9:11 AM
Subject: Re: Persistent "xmlValidation" Problem



Hi,

Bob Bronson wrote:


Hello,

Sorry, to bother the developer group with this question but I posted 
twice on the user group and received zero replies. I was hoping one 
of you could offer some quick advice on this question.

-
I'm using TC 5.5.12.
Please look at this snippet from the server.xml that is distributed
with TC:

 
  


Can anyone tell me what the 'xmlValidation' attribute on  is for?
I realize it has something to do with "XML validation", but what XML is
it referring to? Is it the corresponding web.xml?



Yes it is.

And how does the


'xmlNamespaceAware' attribute fit in?



You can decide to validate with or without namespace.



And what's the comment about the Xerces 2.2 parser?



For a long time, Xerces was broken/buggy when used in Tomcat.

'm using Sun's JDK


1.5.0. Does it use Xerces internally?



Yes it does.






Thanks for the mostly useless reply. I was hoping (silly me) that since
the 'xmlValidation' attribute is completely undocumented
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html), one of the
Tomcat programmers could go into more detail about whether it works and
any sublties involved in its use (e.g., any JDK dependecies). Setting
it to 'true' results in a lot of stack traces when validating my simple
web.xml.

Here's something that illustrates the sloppiness of Tomcat programmers:

I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I
went into the server.xml that is distributed with TC and changed the
'xmlValidation' attribute value to "true" on the  attribute. What
do you think happened? I got tons of meaningless stack traces. This
tells me one of two things -- either the sloppy Tomcat open sores
programmers released an invalid web.xml that doesn't validate *OR* that
the 'xmlValidation' functionality is broken.

The fact that Tomcat 5.5.12 was released with this very basic (admit
it, it's not a subtle issue) problem indicates to me the poor state of
testing the Tomcat programmers must do at a system level.








When I set the 'xmlValidation' attribute to 'true' I get a big stack
trace. One would think it might be appropriate to offer a nice error
message describing the problem.



Blame Xerces ;-). XML error are not always easy to discover.





You say that the lousy XML error messages are something I should "blame
on Xerces". That response is a lazy copout which is *SO TYPICAL* of the
arrogant programmers working on open sores projects. I don't blame the
error messages on Xerces, I blame them on lazy, sloppy open sores
Tomcat programmers -- too lazy to test even basic aspects of their
system (like XML validation), too lazy to keep the documentation of
their product up to date, too lazy to GENERATE VALID, MEANINGFUL ERROR
MESSAGES rather than just dumping a stack trace from Xerces, too lazy
to look into any problems that don't interest them. (Hey, they're not
getting paid, why should they bother with things that don't interest
them? -- That seems to be the Open Source Programmer's Manifesto).






I've looked at the latest TC documentation for  and it makes no
mention of the 'xmlValidation' attribute:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html



That's a problem. I will take a look.



Can someone please explain these two attributes? My web.xml is getting
unwieldy and I'd like to start validating it.



In short, set those two values to true. If you are seeing exception, 
then it means your web.xml is not properly written. Try using 
Netbeans/Eclipse (or any IDE). It is much more easy.





Another lazy copout!! Even the web.xml that is distributed w/Tomcat
does not validate! Did you even test this before you replied to my note
or did you just assume the user was at fault???


When someone criticizes the poor state of an open sores project (as I
am doing now), the typical response from the open sores programmer is
to shift responsibility to the user -- the user is often told to dig
through the change logs or browse the forum archives or even to fix the
bug/documentation themselves instead of "complaining". What an
unprofessional, lazy attitude from programmers! The open sores
programmers try to cast *their* laziness as the user's laziness for
"not digging deeply enough" to resolve their own problem, or even
fixing the problem themselves by going into the source code. The fact
that the Tomcat User mailing list often receives over 150 messages a
day is more a testament to Tomcat's crappy documentation than to its
popularity.

Re: Persistent "xmlValidation" Problem

[Bob Bronson]

Comments below, for any of you who care


- Original Message - 
From: "Jeanfrancois Arcand" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Tuesday, November 01, 2005 9:11 AM
Subject: Re: Persistent "xmlValidation" Problem



Hi,

Bob Bronson wrote:

Hello,

Sorry, to bother the developer group with this question but I posted 
twice on the user group and received zero replies. I was hoping one 
of you could offer some quick advice on this question.

-
I'm using TC 5.5.12.
Please look at this snippet from the server.xml that is distributed
with TC:

 
  


Can anyone tell me what the 'xmlValidation' attribute on  is 
for?
I realize it has something to do with "XML validation", but what XML 
is

it referring to? Is it the corresponding web.xml?


Yes it is.

And how does the

'xmlNamespaceAware' attribute fit in?


You can decide to validate with or without namespace.



And what's the comment about the Xerces 2.2 parser?


For a long time, Xerces was broken/buggy when used in Tomcat.

'm using Sun's JDK

1.5.0. Does it use Xerces internally?


Yes it does.





Thanks for the mostly useless reply. I was hoping (silly me) that since
the 'xmlValidation' attribute is completely undocumented
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html), one of the
Tomcat programmers could go into more detail about whether it works and
any sublties involved in its use (e.g., any JDK dependecies). Setting
it to 'true' results in a lot of stack traces when validating my simple
web.xml.

Here's something that illustrates the sloppiness of Tomcat programmers:

I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I
went into the server.xml that is distributed with TC and changed the
'xmlValidation' attribute value to "true" on the  attribute. What
do you think happened? I got tons of meaningless stack traces. This
tells me one of two things -- either the sloppy Tomcat open sores
programmers released an invalid web.xml that doesn't validate *OR* that
the 'xmlValidation' functionality is broken.

The fact that Tomcat 5.5.12 was released with this very basic (admit
it, it's not a subtle issue) problem indicates to me the poor state of
testing the Tomcat programmers must do at a system level.








When I set the 'xmlValidation' attribute to 'true' I get a big stack
trace. One would think it might be appropriate to offer a nice error
message describing the problem.


Blame Xerces ;-). XML error are not always easy to discover.




You say that the lousy XML error messages are something I should "blame
on Xerces". That response is a lazy copout which is *SO TYPICAL* of the
arrogant programmers working on open sores projects. I don't blame the
error messages on Xerces, I blame them on lazy, sloppy open sores
Tomcat programmers -- too lazy to test even basic aspects of their
system (like XML validation), too lazy to keep the documentation of
their product up to date, too lazy to GENERATE VALID, MEANINGFUL ERROR
MESSAGES rather than just dumping a stack trace from Xerces, too lazy
to look into any problems that don't interest them. (Hey, they're not
getting paid, why should they bother with things that don't interest
them? -- That seems to be the Open Source Programmer's Manifesto).






I've looked at the latest TC documentation for  and it makes 
no

mention of the 'xmlValidation' attribute:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html


That's a problem. I will take a look.



Can someone please explain these two attributes? My web.xml is 
getting

unwieldy and I'd like to start validating it.


In short, set those two values to true. If you are seeing exception, 
then it means your web.xml is not properly written. Try using 
Netbeans/Eclipse (or any IDE). It is much more easy.





Another lazy copout!! Even the web.xml that is distributed w/Tomcat
does not validate! Did you even test this before you replied to my note
or did you just assume the user was at fault???


When someone criticizes the poor state of an open sores project (as I
am doing now), the typical response from the open sores programmer is
to shift responsibility to the user -- the user is often told to dig
through the change logs or browse the forum archives or even to fix the
bug/documentation themselves instead of "complaining". What an
unprofessional, lazy attitude from programmers! The open sores
programmers try to cast *their* laziness as the user's laziness for
"not digging deeply enough" to resolve their own problem, or even
fixing the problem themselves by going into the source code. The fact
that the Tomcat User mailing list often receives over 150 messages a
day is more a testament to Tomcat's crappy documentation than to its
popularity.

Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy
to pay money for quality. I guess Tomcat bares out the old adage, "you
get what you pay for".





---

Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)

[Bob Bronson]

Comments below, for any of you who care


- Original Message - 
From: "Jeanfrancois Arcand" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Tuesday, November 01, 2005 9:11 AM
Subject: Re: Persistent "xmlValidation" Problem



Hi,

Bob Bronson wrote:

Hello,

Sorry, to bother the developer group with this question but I posted 
twice on the user group and received zero replies. I was hoping one 
of you could offer some quick advice on this question.

-
I'm using TC 5.5.12.
Please look at this snippet from the server.xml that is distributed
with TC:

 
  


Can anyone tell me what the 'xmlValidation' attribute on  is 
for?
I realize it has something to do with "XML validation", but what XML 
is

it referring to? Is it the corresponding web.xml?


Yes it is.

And how does the

'xmlNamespaceAware' attribute fit in?


You can decide to validate with or without namespace.



And what's the comment about the Xerces 2.2 parser?


For a long time, Xerces was broken/buggy when used in Tomcat.

'm using Sun's JDK

1.5.0. Does it use Xerces internally?


Yes it does.





Thanks for the mostly useless reply. I was hoping (silly me) that since 
the 'xmlValidation' attribute is completely undocumented 
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html), one of the 
Tomcat programmers could go into more detail about whether it works and 
any sublties involved in its use (e.g., any JDK dependecies). Setting 
it to 'true' results in a lot of stack traces when validating my simple 
web.xml.


Here's something that illustrates the sloppiness of Tomcat programmers:

I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I 
went into the server.xml that is distributed with TC and changed the 
'xmlValidation' attribute value to "true" on the  attribute. What 
do you think happened? I got tons of meaningless stack traces. This 
tells me one of two things -- either the sloppy Tomcat open sores 
programmers released an invalid web.xml that doesn't validate *OR* that 
the 'xmlValidation' functionality is broken.


The fact that Tomcat 5.5.12 was released with this very basic (admit 
it, it's not a subtle issue) problem indicates to me the poor state of 
testing the Tomcat programmers must do at a system level.









When I set the 'xmlValidation' attribute to 'true' I get a big stack
trace. One would think it might be appropriate to offer a nice error
message describing the problem.


Blame Xerces ;-). XML error are not always easy to discover.




You say that the lousy XML error messages are something I should "blame 
on Xerces". That response is a lazy copout which is *SO TYPICAL* of the 
arrogant programmers working on open sores projects. I don't blame the 
error messages on Xerces, I blame them on lazy, sloppy open sores 
Tomcat programmers -- too lazy to test even basic aspects of their 
system (like XML validation), too lazy to keep the documentation of 
their product up to date, too lazy to GENERATE VALID, MEANINGFUL ERROR 
MESSAGES rather than just dumping a stack trace from Xerces, too lazy 
to look into any problems that don't interest them. (Hey, they're not 
getting paid, why should they bother with things that don't interest 
them? -- That seems to be the Open Source Programmer's Manifesto).







I've looked at the latest TC documentation for  and it makes 
no

mention of the 'xmlValidation' attribute:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html


That's a problem. I will take a look.



Can someone please explain these two attributes? My web.xml is 
getting

unwieldy and I'd like to start validating it.


In short, set those two values to true. If you are seeing exception, 
then it means your web.xml is not properly written. Try using 
Netbeans/Eclipse (or any IDE). It is much more easy.





Another lazy copout!! Even the web.xml that is distributed w/Tomcat 
does not validate! Did you even test this before you replied to my note 
or did you just assume the user was at fault???



When someone criticizes the poor state of an open sores project (as I 
am doing now), the typical response from the open sores programmer is 
to shift responsibility to the user -- the user is often told to dig 
through the change logs or browse the forum archives or even to fix the 
bug/documentation themselves instead of "complaining". What an 
unprofessional, lazy attitude from programmers! The open sores 
programmers try to cast *their* laziness as the user's laziness for 
"not digging deeply enough" to resolve their own problem, or even 
fixing the problem themselves by going into the source code. The fact 
that the Tomcat User mailing list often receives over 150 messages a 
day is more a testament to Tomcat's crappy documentation than to its 
popularity.


Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy 
to pay money for quality. I guess Tomcat bares out the old adage, "you 
get what you pay for".






-

Re: Persistent "xmlValidation" Problem

[Bob Bronson]

Comments below, for any of you who care


- Original Message - 
From: "Jeanfrancois Arcand" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Cc: 
Sent: Tuesday, November 01, 2005 9:11 AM
Subject: Re: Persistent "xmlValidation" Problem



Hi,

Bob Bronson wrote:

Hello,

Sorry, to bother the developer group with this question but I posted 
twice on the user group and received zero replies. I was hoping one 
of you could offer some quick advice on this question.

-
I'm using TC 5.5.12.
Please look at this snippet from the server.xml that is distributed
with TC:

 
  


Can anyone tell me what the 'xmlValidation' attribute on  is 
for?
I realize it has something to do with "XML validation", but what XML 
is

it referring to? Is it the corresponding web.xml?


Yes it is.

And how does the

'xmlNamespaceAware' attribute fit in?


You can decide to validate with or without namespace.



And what's the comment about the Xerces 2.2 parser?


For a long time, Xerces was broken/buggy when used in Tomcat.

'm using Sun's JDK

1.5.0. Does it use Xerces internally?


Yes it does.





Thanks for the mostly useless reply. I was hoping (silly me) that since
the 'xmlValidation' attribute is completely undocumented
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html), one of the
Tomcat programmers could go into more detail about whether it works and
any sublties involved in its use (e.g., any JDK dependecies). Setting
it to 'true' results in a lot of stack traces when validating my simple
web.xml.

Here's something that illustrates the sloppiness of Tomcat programmers:

I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I
went into the server.xml that is distributed with TC and changed the
'xmlValidation' attribute value to "true" on the  attribute. What
do you think happened? I got tons of meaningless stack traces. This
tells me one of two things -- either the sloppy Tomcat open sores
programmers released an invalid web.xml that doesn't validate *OR* that
the 'xmlValidation' functionality is broken.

The fact that Tomcat 5.5.12 was released with this very basic (admit
it, it's not a subtle issue) problem indicates to me the poor state of
testing the Tomcat programmers must do at a system level.








When I set the 'xmlValidation' attribute to 'true' I get a big stack
trace. One would think it might be appropriate to offer a nice error
message describing the problem.


Blame Xerces ;-). XML error are not always easy to discover.




You say that the lousy XML error messages are something I should "blame
on Xerces". That response is a lazy copout which is *SO TYPICAL* of the
arrogant programmers working on open sores projects. I don't blame the
error messages on Xerces, I blame them on lazy, sloppy open sores
Tomcat programmers -- too lazy to test even basic aspects of their
system (like XML validation), too lazy to keep the documentation of
their product up to date, too lazy to GENERATE VALID, MEANINGFUL ERROR
MESSAGES rather than just dumping a stack trace from Xerces, too lazy
to look into any problems that don't interest them. (Hey, they're not
getting paid, why should they bother with things that don't interest
them? -- That seems to be the Open Source Programmer's Manifesto).






I've looked at the latest TC documentation for  and it makes 
no

mention of the 'xmlValidation' attribute:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html


That's a problem. I will take a look.



Can someone please explain these two attributes? My web.xml is 
getting

unwieldy and I'd like to start validating it.


In short, set those two values to true. If you are seeing exception, 
then it means your web.xml is not properly written. Try using 
Netbeans/Eclipse (or any IDE). It is much more easy.





Another lazy copout!! Even the web.xml that is distributed w/Tomcat
does not validate! Did you even test this before you replied to my note
or did you just assume the user was at fault???


When someone criticizes the poor state of an open sores project (as I
am doing now), the typical response from the open sores programmer is
to shift responsibility to the user -- the user is often told to dig
through the change logs or browse the forum archives or even to fix the
bug/documentation themselves instead of "complaining". What an
unprofessional, lazy attitude from programmers! The open sores
programmers try to cast *their* laziness as the user's laziness for
"not digging deeply enough" to resolve their own problem, or even
fixing the problem themselves by going into the source code. The fact
that the Tomcat User mailing list often receives over 150 messages a
day is more a testament to Tomcat's crappy documentation than to its
popularity.

Yes, yes, I know Tomcat is "not for me". You're right. I'm happy
to pay money for quality. I guess Tomcat bares out the old adage, "you
get what you pay for".





--

DO NOT REPLY [Bug 37350] New: - Problems serving large (50k+) static images on linux

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: Problems serving large (50k+) static images on linux
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a web app that spits out dynamic pages that include within them links to
static icons and whatnot. A typical  looks like:



These all work perfectly on Tomcat 5.5.9 on Windows XP.

When I move the war over to my linux box with Tomcat 5.5.12, however, all the
 tags that point to images over about 50k break. I don't get a broken link,
I don't get a half an image, I just get ... nothing.

When I look in catalina.out, I see what I think is the error message, but I
can't figure out the cause.

Again, small images server just fine. Big ones cause errors, but only when
references via links as I described.

Also noteworthy is that Tomcat appears unable to serve the image even if I
navigate to it via the url directly e.g. typing:

http://p500:9090/Corinna/img/help/navigatemain.png

Results in the same error.

The error I get the *first* time I go after the resource. 

ClientAbortException:  java.net.SocketException: Broken pipe
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffe
r.java:366)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:403)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:
314)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:29
3)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputSt
ream.java:97)
at org.apache.tapestry.request.ResponseOutputStream.forceFlush(ResponseO
utputStream.java:149)
at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java
:945)
at org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.j
ava:198)
at servlet.MyServlet.doService(MyServlet.java:167)
at org.apache.tapestry.ApplicationServlet.doGet(ApplicationServlet.java:
159)
at servlet.MyServlet.doGet(MyServlet.java:141)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:868)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:663)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
lowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
at java.lang.Thread.run(Thread.java:595)

The error I get *subsequent times*:

java.lang.NoSuchMethodError:
org.apache.naming.resources.ResourceAttributes.getCanonicalPath()Ljava/lang/String;

org.apache.catalina.servlets.DefaultServlet.checkSendfile(DefaultServlet.java:1521)

org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:839)

org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:348)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37350] - Problems serving large (50k+) static images on linux

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-04 04:09 ---
Created an attachment (id=16872)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16872&action=view)
One of the images that tomcat wont' serve


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Rewrite features

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, November 03, 2005 12:18 PM
Subject: Re: Rewrite features


>Bill Barker wrote:
>> We don't unbind the service() from the Thread.  However, in Coyote
Request
>> instances are very long lived objects that (at least for HTTP/1.1)
persist
>> over many connections.
>>
>> The APR Connector uses a ThreadLocal to bind the Request instance to a
>> single Thread instance.  The next request that it handles may have been
>> received on a different Socket than the last, but it is bound to the
Thread.
>> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via
the
>> init() method of ThreadPoolRunnable.
>>
>> The Nio/AJP Connector binds the Request instance to a Socket connection
(via
>> the SelectionKey.attachment).
>
>Personally, I always considered the Request/Response objects were tied
>to the thread. I don't know for sure, but it could mean that my valve
>may not work with your connector then (the utility object that resolves
>special variables uses the request, and it could be an issue).
>

As I said, it probably doesn't matter since nobody (except me :) uses my
Connector.  Also, if you're using AJP it's likely that you'd be using
mod_rewrite for this sort of thing anyway ;-).

>Rémy



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: Rewrite features

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, November 03, 2005 12:11 PM
Subject: Re: Rewrite features


>Costin Manolache wrote:
>> On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>>
>>>It probably doesn't matter (since nobody uses it :), but using
ThreadLocal
>>>won't work with the Nio/AJP Connector.  That one doesn't bind a Request
>>>instance to a Thread instance, so a particular Request instance will
process
>>>on many different Threads during its lifecycle.
>>
>> Does the spec say anything about the thread model when executing a
>> servlet ? ( too lazy to search, I know some people on the list have
>> memorized the spec already :-)
>>
>> I'm not sure how this happens - I tought that the request is bound to
>> a thread during service() execution, and kept-alive connections are no
>> longer bound. How do we unbind the service() from the thread ???
>
>There must be a misunderstanding somewhere: the thread is indeed bound
>during the execution of the adapter process method, so TLs should work
>the way I am using them. Using notes is difficult for this because there
>can be "nested" rewrites (one at host level + one at context level, for
>example). I would have preffered using that for performance, of course;
>maybe an array would do it, or something, but TLs are cleaner to
>understand. I do need plenty of TLs anyway, as the regexp engine is per
>thread. For some reason, it took me a long time to figure out a design
>that I liked, worked and met the requirements (I suck).
>

The TomcatResolver instance is holding a reference to the Request instance,
and is in a TL.  As a result (because of the way the ThreadPool works) it
will live very much longer than just during the processing of a given
Request.  This is all fine for all of the current Connectors except Nio/AJP,
since they happen to bind the Request instance to the Thread instance so you
always get the right Request instance.

Adding a setRequest method to TomcatResolver would "fix" this with the
minimal amount of work.



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: Rewrite features

[Costin Manolache]

On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" 
> Sent: Thursday, November 03, 2005 11:30 AM
> Subject: Re: Rewrite features
>
>
> On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> >> It probably doesn't matter (since nobody uses it :), but using
> ThreadLocal
> >> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
> >> instance to a Thread instance, so a particular Request instance will
> process
> >> on many different Threads during its lifecycle.
> >
> >Does the spec say anything about the thread model when executing a
> >servlet ? ( too lazy to search, I know some people on the list have
> >memorized the spec already :-)
>
> When an AJP Request comes in, the Connector gets a Thread from the Pool to
> process the Request.  After the Request is done processing, it returns the
> Thread to the Pool.  There is no reason that it should get the same Thread
> instance each time it does this.

Yes, but I tought all the service() method is still running in one
thread from start to finish.
The next AJP Request is a different servlet request - in the past it
was in the same thread only if Keep-Alive was used. If the connection
has expired ( keep alive timeout, or multiple connections from browser
) - it'll go to different thread.

The only case I knew where a service() will lose thread in the middle
is the Jetty continuation, where the thread is released by a sepecial
exception and extrenal event reaquire a random thread to continue.



> >
> >I'm not sure how this happens - I tought that the request is bound to
> >a thread during service() execution, and kept-alive connections are no
> >longer bound. How do we unbind the service() from the thread ???
> >
>
> We don't unbind the service() from the Thread.  However, in Coyote Request
> instances are very long lived objects that (at least for HTTP/1.1) persist
> over many connections.

But this is not guaranteed - you can't rely on this, there are many
cases where you would get a different thread.


> The APR Connector uses a ThreadLocal to bind the Request instance to a
> single Thread instance.  The next request that it handles may have been
> received on a different Socket than the last, but it is bound to the Thread.
> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
> init() method of ThreadPoolRunnable.

I still don't understand the problem.
2 requests from the same browser can be assigned different threads in
both connectors. They get same thread in the old connector more often
- if they happen to use the same socket, but this is not allways the
case.

I suppose I'm missing something trivial here...

>
> The Nio/AJP Connector binds the Request instance to a Socket connection (via
> the SelectionKey.attachment).

Costin

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

Re: Rewrite features

[Remy Maucherat]

Bill Barker wrote:

We don't unbind the service() from the Thread.  However, in Coyote Request
instances are very long lived objects that (at least for HTTP/1.1) persist
over many connections.

The APR Connector uses a ThreadLocal to bind the Request instance to a
single Thread instance.  The next request that it handles may have been
received on a different Socket than the last, but it is bound to the Thread.
With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
init() method of ThreadPoolRunnable.

The Nio/AJP Connector binds the Request instance to a Socket connection (via
the SelectionKey.attachment).


Personally, I always considered the Request/Response objects were tied 
to the thread. I don't know for sure, but it could mean that my valve 
may not work with your connector then (the utility object that resolves 
special variables uses the request, and it could be an issue).


Rémy

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

Re: Rewrite features

[Remy Maucherat]

Costin Manolache wrote:

On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:


It probably doesn't matter (since nobody uses it :), but using ThreadLocal
won't work with the Nio/AJP Connector.  That one doesn't bind a Request
instance to a Thread instance, so a particular Request instance will process
on many different Threads during its lifecycle.


Does the spec say anything about the thread model when executing a
servlet ? ( too lazy to search, I know some people on the list have
memorized the spec already :-)

I'm not sure how this happens - I tought that the request is bound to
a thread during service() execution, and kept-alive connections are no
longer bound. How do we unbind the service() from the thread ???


There must be a misunderstanding somewhere: the thread is indeed bound 
during the execution of the adapter process method, so TLs should work 
the way I am using them. Using notes is difficult for this because there 
can be "nested" rewrites (one at host level + one at context level, for 
example). I would have preffered using that for performance, of course; 
maybe an array would do it, or something, but TLs are cleaner to 
understand. I do need plenty of TLs anyway, as the regexp engine is per 
thread. For some reason, it took me a long time to figure out a design 
that I liked, worked and met the requirements (I suck).


As for putting this at a lower level, no, because Mladen wanted to be 
able to specify per host and per context rules, so mapping has to occur 
first, and then be performed again (there are other features which need 
). Having it as a rule is equivalent to putting it (unless in stupid 
cases where the rewrite valve is set after another valve that is 
expensive to invoke). Since it's our product, we have some specific 
requirements ;)


Side effect: if MessageByte and CharChunk were implementing 
CharSequence, I could just give them to the regexp engine without having 
to do useless toString calls.


Note: this feature is something that I don't want in Tomcat; just 
imagine the non portable mess that webapps would become if rewrite was 
readily available ...


Rémy

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

Re: Rewrite features

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, November 03, 2005 11:30 AM
Subject: Re: Rewrite features


On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>> It probably doesn't matter (since nobody uses it :), but using
ThreadLocal
>> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
>> instance to a Thread instance, so a particular Request instance will
process
>> on many different Threads during its lifecycle.
>
>Does the spec say anything about the thread model when executing a
>servlet ? ( too lazy to search, I know some people on the list have
>memorized the spec already :-)

When an AJP Request comes in, the Connector gets a Thread from the Pool to
process the Request.  After the Request is done processing, it returns the
Thread to the Pool.  There is no reason that it should get the same Thread
instance each time it does this.

>
>I'm not sure how this happens - I tought that the request is bound to
>a thread during service() execution, and kept-alive connections are no
>longer bound. How do we unbind the service() from the thread ???
>

We don't unbind the service() from the Thread.  However, in Coyote Request
instances are very long lived objects that (at least for HTTP/1.1) persist
over many connections.

The APR Connector uses a ThreadLocal to bind the Request instance to a
single Thread instance.  The next request that it handles may have been
received on a different Socket than the last, but it is bound to the Thread.
With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
init() method of ThreadPoolRunnable.

The Nio/AJP Connector binds the Request instance to a Socket connection (via
the SelectionKey.attachment).

>
>Costin



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: Rewrite features

[Costin Manolache]

On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> It probably doesn't matter (since nobody uses it :), but using ThreadLocal
> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
> instance to a Thread instance, so a particular Request instance will process
> on many different Threads during its lifecycle.

Does the spec say anything about the thread model when executing a
servlet ? ( too lazy to search, I know some people on the list have
memorized the spec already :-)

I'm not sure how this happens - I tought that the request is bound to
a thread during service() execution, and kept-alive connections are no
longer bound. How do we unbind the service() from the thread ???


Costin

>
> The alternative (which, IMHO looks nicer) is to use (Coyote)Request Notes
> instead of ThreadLocal.
>
> - Original Message -
> From: "Remy Maucherat" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" 
> Sent: Thursday, November 03, 2005 8:40 AM
> Subject: Rewrite features
>
>
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jbos
> s/web/rewrite/
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Rewrite features

[Yoav Shapira]

Hi,

> The reason I ask - I'm playing with coyote standalone, I have a
> trivial mapper, file server, hello world adapter - for simple http
> serving. 

I would love, love, love to see this.  What's the download footprint size?

Thanks,

Yoav

Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

Re: Rewrite features

[Bill Barker]

It probably doesn't matter (since nobody uses it :), but using ThreadLocal
won't work with the Nio/AJP Connector.  That one doesn't bind a Request
instance to a Thread instance, so a particular Request instance will process
on many different Threads during its lifecycle.

The alternative (which, IMHO looks nicer) is to use (Coyote)Request Notes
instead of ThreadLocal.

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Thursday, November 03, 2005 8:40 AM
Subject: Rewrite features


Hi,

As part of the JBoss Web project, I have developed a URL rewrite valve,
more or less cloned on mod_rewrite. It doesn't support everything from
mod_rewrite, and there's no docs at the moment, but it's not too hard to
figure out how to use it.

For looking at it and testing, it's here (of course, it's neither
polished nor well tested at the moment):
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jbos
s/web/rewrite/

Rémy

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




This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: tomcat source / eclipse project

[Ian Darwin]

Mark Thomas wrote:

I have something like this for TC5 & TC4. I do keep the files up to 
date because I use them every time I look at Tomcat code.


I need to migrate my development areas from the old CVS structure to 
the SVN set-up. Once I have updated my eclipse files, I'll add them to 
the repo.


Anyone object to them being added directly under 
tomcat/container/tc5.5.x, tomcat/jasper/tc5.5.x etc?


They pretty well have to be there to work, right? So, please put them there.
I presume there's just a .project and a .classpath for each of a few 
top-level

projects, right? These will be harmless to non-Eclipse users, and invisible
on platforms that support *NIX filename semantics, so I'd say +1 for them.

Thanks
Ian

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

Re: tomcat source / eclipse project

[Keith Wannamaker]

+1

It is a pain setting these up.

Keith

Mark Thomas wrote:
I have something like this for TC5 & TC4. I do keep the files up to date 
because I use them every time I look at Tomcat code.


I need to migrate my development areas from the old CVS structure to the 
SVN set-up. Once I have updated my eclipse files, I'll add them to the 
repo.


Anyone object to them being added directly under 
tomcat/container/tc5.5.x, tomcat/jasper/tc5.5.x etc?


Mark


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

Re: Rewrite features

[Costin Manolache]

Have you considered placing it at a lower level, as a coyote adapter ?
The reason I ask - I'm playing with coyote standalone, I have a
trivial mapper, file server, hello world adapter - for simple http
serving. This would fit well before entering the servlet engine.

Costin

On 11/3/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: tomcat source / eclipse project

[Mark Thomas]

I have something like this for TC5 & TC4. I do keep the files up to 
date because I use them every time I look at Tomcat code.


I need to migrate my development areas from the old CVS structure to 
the SVN set-up. Once I have updated my eclipse files, I'll add them to 
the repo.


Anyone object to them being added directly under 
tomcat/container/tc5.5.x, tomcat/jasper/tc5.5.x etc?


Mark

Yoav Shapira wrote:

Hi,



task. Could you please point me to some .project / .classpath files as



They don't exist: set them up and contribute them if you wish.  They'd be
welcome *as long as they are maintained current.*  I'm certainly not in the
mood to make changes in more than one place every time I update build.xml.



Why don't you just add these files to the 'Building with Eclipse' section



If the files existed and were maintained to be current, they'd be added with
enthusiasm.



An eclipse-ready project or at least a possibility to checkout the
repository it in a structured way, with one source folder and one lib
folder, would be everything one can dream of :-)



Don't dream of it: if it's that important to you, do it.  And if you want to
help others as well, contribute it.

Yoav

Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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








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

Re: Rewrite features

[Remy Maucherat]

Yoav Shapira wrote:

Hi,
Cool, I like it.  Two questions:

- Why the RewriteMap interface?  It does seem to add much over a normal Map,
and I doubt you're targeting JDK 1.1 compatibility ;)


It's not a map (at least not a Java map). mod_rewrite calls the 
directive RewriteMap.



- Seems like this could be easily done as a Filter instead of Valve.  The
lifecycle support would be a bit different, start -> init, stop -> destroy,
etc, but otherwise it doesn't seem like a stretch...


A filter would not work. Doing it this way will (eventually) be a lot 
more efficient.


Rémy

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

Re: Rewrite features

[Yoav Shapira]

Hi,
Cool, I like it.  Two questions:

- Why the RewriteMap interface?  It does seem to add much over a normal Map,
and I doubt you're targeting JDK 1.1 compatibility ;)

- Seems like this could be easily done as a Filter instead of Valve.  The
lifecycle support would be a bit different, start -> init, stop -> destroy,
etc, but otherwise it doesn't seem like a stretch...

Yoav

--- Remy Maucherat <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> As part of the JBoss Web project, I have developed a URL rewrite valve, 
> more or less cloned on mod_rewrite. It doesn't support everything from 
> mod_rewrite, and there's no docs at the moment, but it's not too hard to 
> figure out how to use it.
> 
> For looking at it and testing, it's here (of course, it's neither 
> polished nor well tested at the moment):
>
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

Rewrite features

[Remy Maucherat]

Hi,

As part of the JBoss Web project, I have developed a URL rewrite valve, 
more or less cloned on mod_rewrite. It doesn't support everything from 
mod_rewrite, and there's no docs at the moment, but it's not too hard to 
figure out how to use it.


For looking at it and testing, it's here (of course, it's neither 
polished nor well tested at the moment):

http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/

Rémy

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