DO NOT REPLY [Bug 37238] New: - Unable to start HTTPS listener using PKCS12 format certificate.

[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=37238

   Summary: Unable to start HTTPS listener using PKCS12 format
certificate.
   Product: Tomcat 5
   Version: 5.0.25
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: critical
  Priority: P2
 Component: Connector:HTTP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


After moving keystore from JKS format to PKCS12 format, tomcat server fails to
listen for https and logs following:

=
INFO: Starting Coyote HTTP/1.1 on http-80
Oct 19, 2005 2:47:27 AM org.apache.coyote.http11.Http11Protocol start
SEVERE: Error starting endpoint
java.io.IOException: DerInputStream.getLength(): lengthTag=79, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:530)
at sun.security.util.DerValue.(DerValue.java:234)
at sun.security.util.DerInputStream.readVector(DerInputStream.java:359)
at sun.security.util.DerInputStream.getSequence(DerInputStream.java:267)
at
com.sun.net.ssl.internal.ssl.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1222)
at java.security.KeyStore.load(KeyStore.java:1150)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:278)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:220)
at
org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JSSE14SocketFactory.java:143)
at
org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:109)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:88)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:253)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoint.java:275)
at 
org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:177)
at
org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1500)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:485)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2298)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422)



Here is our configuration file:
===

===

-- 
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: Status/Authority of AJP/1.5

[Henri Gomez]

AJP 1.5 should support automatic discovery of tomcat backend, new
systems and new webapps.

That's the current need for many of us when adding tomcats / webapp
behind Apache 2 webservers. In such case we need to restart them and
it's sad.

How could it be accomplished, may be via a master tomcat who will give
the tomcat farm topology to Apache HTTP2.

What do you think ?

2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> I see. Sorry, I've been sleeping for quite a while, I'm slowly getting
> up to speed with the latest developments.
>
> Are you saying that mod_proxy_ajp is significantly faster than
> mod_proxy ? That's interesting.
>
> To answer your question - ajp10 and ajp11 were used in JServ,
> developed in Apache.
> Ajp12 is based on 11, developed in the early days of tomcat. I think
> jetty also suppors ( or supported ) the protocol at some time.
>
> IMHO - if a new version of the protocol is developed, there are 2 choices:
> - preserve backwards compatibility - there are few ugly way to do this
> - break backwards compatibility - in wich case it may be better to
> redo the protocol so it is extensible, and maybe even better reuse an
> existing protocol. An example to look at is the DBUS protocol ( from
> freedesktop ) - or maybe classical RPC. Ad-hoc arbitrary binary
> protocols can be a bad idea - as we see with ajp12 extensibility
> problems.
>
>
> Costin
>
> On 10/24/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> > Costin Manolache wrote:
> > > I tought some time ago AJP was 'deprecated' - to be replaced with
> > > plain HTTP and mod_proxy ?
> >
> > Why?
> >
> > It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity
> > of optimizing the backend connection.  I don't think anyone forsees mod_jk
> > being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
> > http servers), but from an Apache perspective, hopefully mod_proxy_ajp will
> > make mod_jk/Apache a footnote in history :)
> >
> > Bill
> >
> > -
> > 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]
>
>

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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

I see. Sorry, I've been sleeping for quite a while, I'm slowly getting
up to speed with the latest developments.

Are you saying that mod_proxy_ajp is significantly faster than
mod_proxy ? That's interesting.

To answer your question - ajp10 and ajp11 were used in JServ,
developed in Apache.
Ajp12 is based on 11, developed in the early days of tomcat. I think
jetty also suppors ( or supported ) the protocol at some time.

IMHO - if a new version of the protocol is developed, there are 2 choices:
- preserve backwards compatibility - there are few ugly way to do this
- break backwards compatibility - in wich case it may be better to
redo the protocol so it is extensible, and maybe even better reuse an
existing protocol. An example to look at is the DBUS protocol ( from
freedesktop ) - or maybe classical RPC. Ad-hoc arbitrary binary
protocols can be a bad idea - as we see with ajp12 extensibility
problems.


Costin

On 10/24/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I tought some time ago AJP was 'deprecated' - to be replaced with
> > plain HTTP and mod_proxy ?
>
> Why?
>
> It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity
> of optimizing the backend connection.  I don't think anyone forsees mod_jk
> being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
> http servers), but from an Apache perspective, hopefully mod_proxy_ajp will
> make mod_jk/Apache a footnote in history :)
>
> Bill
>
> -
> 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: Status/Authority of AJP/1.5

[William A. Rowe, Jr.]

Costin Manolache wrote:

I tought some time ago AJP was 'deprecated' - to be replaced with
plain HTTP and mod_proxy ?


Why?

It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity
of optimizing the backend connection.  I don't think anyone forsees mod_jk
being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
http servers), but from an Apache perspective, hopefully mod_proxy_ajp will
make mod_jk/Apache a footnote in history :)

Bill

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

Re: Status/Authority of AJP/1.5

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Monday, October 24, 2005 3:11 PM
Subject: Re: Status/Authority of AJP/1.5


>I tought some time ago AJP was 'deprecated' - to be replaced with
>plain HTTP and mod_proxy ?
>

Once httpd-2.2.0 ships, then it's likely that people will want to use
mod_proxy_ajp (which is part of httpd) instead of mod_jk.  But AJP is very
much alive.  Even Remy is now an AJP devloper ;-).

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

Context tag with path attribute

[Vivek Lakshmanan]

Hi Folks,
I just noticed that the Context tag's path attribute is ignored (at
least seems to be) in tomcat 5.5.9 unless it is included in the
server.xml file statically. If an application were to be deployed at a
context like /foo/bar in previous versions (5.0.28), I suppose that
would require an explicit entry in the server.xml since I cant specify
that as the name of the .xml context file and I am unaware of another
way to get around this issue. I was wondering what the reasons were for
this change in the newer version? 

Thanks,
Vivek



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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

I tought some time ago AJP was 'deprecated' - to be replaced with
plain HTTP and mod_proxy ?

Costin

On 10/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, October 24, 2005 1:52 PM
> Subject: Status/Authority of AJP/1.5
>
>
> > Questions since some interesting ideas have popped up with respect to the
> > next flavor of AJP...  firstoff, who holds the AJP standard; is it the
> ASF?
> >
>
> Yes, it's entirely owned by the ASF.  It evolved from JServ, which is also
> owned by the ASF.
>
> > Second, what is the status of AJP/1.5 and where is it discussed?
> >
>
> Well, http://issues.apache.org/bugzilla/show_bug.cgi?id=37100 sort of
> wandered off-topic into this area :).  Otherwise, probably
> http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html is your best
> bet.
>
> > I would like to float some various questions to not only introduce some
> > 'flush' signal, to inform the outward facing server to stop caching (if
> > it was) and push out a partial response; and I'd like to explore other
> > information that could be captured with respect to balancing.
> >
>
> By itself, client-flush wouldn't be hard to implement.
>
> > Thanks!
> >
> > Bill
> >
> > -
> > 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: Status/Authority of AJP/1.5

[Bill Barker]

- Original Message -
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: 
Sent: Monday, October 24, 2005 1:52 PM
Subject: Status/Authority of AJP/1.5


> Questions since some interesting ideas have popped up with respect to the
> next flavor of AJP...  firstoff, who holds the AJP standard; is it the
ASF?
>

Yes, it's entirely owned by the ASF.  It evolved from JServ, which is also
owned by the ASF.

> Second, what is the status of AJP/1.5 and where is it discussed?
>

Well, http://issues.apache.org/bugzilla/show_bug.cgi?id=37100 sort of
wandered off-topic into this area :).  Otherwise, probably
http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html is your best
bet.

> I would like to float some various questions to not only introduce some
> 'flush' signal, to inform the outward facing server to stop caching (if
> it was) and push out a partial response; and I'd like to explore other
> information that could be captured with respect to balancing.
>

By itself, client-flush wouldn't be hard to implement.

> Thanks!
>
> Bill
>
> -
> 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]

Status/Authority of AJP/1.5

[William A. Rowe, Jr.]

Questions since some interesting ideas have popped up with respect to the
next flavor of AJP...  firstoff, who holds the AJP standard; is it the ASF?

Second, what is the status of AJP/1.5 and where is it discussed?

I would like to float some various questions to not only introduce some
'flush' signal, to inform the outward facing server to stop caching (if
it was) and push out a partial response; and I'd like to explore other
information that could be captured with respect to balancing.

Thanks!

Bill

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

follow up on 'busyness-based' load balancing patch: bug 36138

[Chris Lamprecht]

I'd like to follow up on a patch I submitted in August:

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

The patch includes a new load balancing algorithm based on current
worker "busyness" (lb.method=B).  The details of the patch are in
bugzilla, and of course, in the patch itself.  It improved performance
greatly for us, load balancing about 25 threads of high traffic over 6
tomcats.

We've also been using this patch with mod_jk 1.2.14 in production
since August with good results.

I know this won't make it into the 1.2.15 version, is there any chance
of getting it into the next version?

Thanks,
Chris

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

Re: [VOTE] JK 1.2.15

[Glenn Nielsen]

I have built mod_jk 1.2.15 for apache 2.0.55 on both Solaris 7 (Sun CC) and
FreeBSD 5.3. Build and normal use appear to be fine.

+1 to release as stable

Regards,

Glenn

On Thu, Sep 29, 2005 at 05:56:55PM +0200, Mladen Turk wrote:
> Hi,
> 
> JK 1.2.15 has been tagged last week.
> Please see the:
> http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
> for a full list of changes.
> 
> 
> Sources can be found at:
> http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.15/
> 
> 
> Please vote:
> 
> [X] Stable -- good build
> [ ] Alpha -- something serious is wrong: what is it?
> 
> Regards,
> Mladen
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: [JK] Status -- was [VOTE] JK 1.2.15

[William A. Rowe, Jr.]

Jean-frederic Clere wrote:

Mladen Turk wrote:


Anyhow, what should I do, since I've volunteer for a RM?


Good questions...


I mean, I don't expect to see the 1.3 branch for couple of
months from now, 


well, that's neither here nor there w.r.t. 1.2.x - whoever needs
to do new development (if 1.2 is feature-frozen) should simply branch
already.  Since I believe we are ready on the svn side, this is nothing
more than an svn cp .../trunk .../branches/1.2.x

but let's leave 1.3 out of this immediate discussion


and the 1.2.14 is unusable on Solaris, so
we need some action. The 1.2.15 (bugfix) release is the
only thing that is implementable right now, thought.


Agreed, it's time to release a 1.2.15, but this is where the RM's job
is very frustrated, working independently, as opposed to working with the
dev list.  I don't remember much chatter before 1.2.15 suddenly appeared,
but when most of the dev@'ers are on different pages, it can take a while
to all get back in sync.

(FWIW - 1.2.15 is going to my QA folks tonight.  You probably are aware
that I had almost every free hour invested in the last few weeks getting out
new apr and httpd versions.  Sorry that my focus was elsewhere.)


There are 10 open bug, what about trying to close them before the release?


That's also irrelevant - is 1.2.15 the best available version?  If so, let's
release (and if you want to squish 10 bugs in a week, jf, feel free to RM
yet another release then!)  The issue (not a problem, unless you are a user
who makes no contribution) is that nobody 'schedules' Apache fixes, each
contributor scratches their own itch.  When everything is healthy, this means
that -someone- is likely to see a significant bug squished, or a competent
user steps up to squish it themself and offer a patch.


Since there was no reactions to the VOTE either pro or
contra for more then a mont,
seems to me we are in a serious problem,


Howso? ...


because the developers/commiter interest is blocking the release.


That's not a problem, that's a symptom.  But you presume it's an unhealthy
symptom...


The final solution is either to bring that to the tomcat pmc,
and if there is really zero interest on maintaining mod_jk,
among the current commiters, it should be either shut down,
or proposed as a new project with a different set of maintainers.


Mladen, this is a bit over-the-top :)  You know full well...

 * you can fork and call your code base mod_jk_mt - nothing wrong with that,
   it's under the Apache License.  Don't call it mod_jk/Apache Tomcat Connector
   and don't host it on apache.org.  Don't feel put-upon if such an effort is
   not warmly embraced by your fellow contributors, here.

 * you can discuss 'why isn't 1.2.15 ready?' on list.  Perhaps, as jfclere
   observes, that some contributors have an issue with it (note no negative
   vote was offered, only a reason why one contributor isn't testing it.)
   Discussion is healthy.

 * you can employ patience, and ping for more testers.  They will likely
   come along in due time.  Especially Solaris testers.  Recent instability
   may have scared some off for the time being from testing this, now very
   solid, newer code.

 * finally, you can consider that, in large measure, mod_jk is 'baked', it's
   been stable for years (well, 1.2.6 was), and many have little motivation
   to develop/test/deploy a new flavor, if they are happy with their current
   installation.  This simply means that new releases will take a bit longer
   to test, and a bit longer to get feedback 'from the field'.

Believe me, you aren't the first frustrated RM.  But a couple-week delay
is hardly cause to sound the klaxons and drop the halon :)

As long as jk serves a purpose, suggesting that it be abandoned isn't the
right answer.  Obviously jrun was ditched because it wasn't supported, but
it also was hopelessly outdated by jk.  Obviously jk2 was scuttled because
it just didn't measure up to jk, it didn't serve a useful need.

But mod_jk serves a need, has maintainers/committers/reviewers.  It's only
a matter of 'sheparding cats' at this point :)

Bill

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

Re: [JK] Status -- was [VOTE] JK 1.2.15

[Jean-frederic Clere]

Mladen Turk wrote:


William A. Rowe, Jr. wrote:



Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?



I'll try to find cycles to test myself, next week.  I know I'm having
alot of trouble with the apache 1.3 build on odd architectures, probably
because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool 
based
httpd 1.3.  I'm working on cleaner autoconf against httpd-2.0 already 
for building mod_ftp, which will probably apply very cleanly here as 
well.




Fine :)

Anyhow, what should I do, since I've volunteer for a RM?
I mean, I don't expect to see the 1.3 branch for couple of
months from now, and the 1.2.14 is unusable on Solaris, so
we need some action. The 1.2.15 (bugfix) release is the
only thing that is implementable right now, thought.


There are 10 open bug, what about trying to close them before the release?



Since there was no reactions to the VOTE either pro or
contra for more then a mont,
seems to me we are in a serious problem, because
the developers/commiter interest is blocking the release.
The final solution is either to bring that to the tomcat pmc,
and if there is really zero interest on maintaining mod_jk,
among the current commiters, it should be either shut down,
or proposed as a new project with a different set of maintainers.

Regards,
Mladen.


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





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

DO NOT REPLY [Bug 37220] - Semi-colon in filename HTTP bug

[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=37220





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 19:36 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Sorry, but anything after ';' is stripped off and treated as a path 
> parameter,
> > even if ';' encoded. I don't want to take risks and handle this 
> > differently, 
> so
> > this issue is not going to be fixed.
> 
> This just means that Tomcat can't/won't handle encoding properly. That is 
> sad. 
> For all I know this might be a problem for other characters as well. How come 
> Tomcat handles this differently than Apache and IIS?
> 
> This most likely causes a bug in the WebDAV Servlet. If you try to upload a 
> file to Tomcat using WebDAV, all characters after ';' is stripped form the 
> file name.

That's the way it is for the ';' character. If you don't like it, you can try to
patch your Tomcat or use a different product.

-- 
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 37220] - Semi-colon in filename HTTP bug

[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=37220





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 19:27 ---
(In reply to comment #3)
> Sorry, but anything after ';' is stripped off and treated as a path 
parameter,
> even if ';' encoded. I don't want to take risks and handle this differently, 
so
> this issue is not going to be fixed.

This just means that Tomcat can't/won't handle encoding properly. That is sad. 
For all I know this might be a problem for other characters as well. How come 
Tomcat handles this differently than Apache and IIS?

This most likely causes a bug in the WebDAV Servlet. If you try to upload a 
file to Tomcat using WebDAV, all characters after ';' is stripped form the 
file name.

-- 
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: [JK] Status -- was [VOTE] JK 1.2.15

[Peter Rossbach]

Sorry for late response, but I start testing and hope finish the test at 
next two days


First testresults at Suse 9.3, Windows XP looks very well

Peter

Mladen Turk schrieb:


William A. Rowe, Jr. wrote:



Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?



I'll try to find cycles to test myself, next week.  I know I'm having
alot of trouble with the apache 1.3 build on odd architectures, probably
because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool 
based
httpd 1.3.  I'm working on cleaner autoconf against httpd-2.0 already 
for building mod_ftp, which will probably apply very cleanly here as 
well.




Fine :)

Anyhow, what should I do, since I've volunteer for a RM?
I mean, I don't expect to see the 1.3 branch for couple of
months from now, and the 1.2.14 is unusable on Solaris, so
we need some action. The 1.2.15 (bugfix) release is the
only thing that is implementable right now, thought.

Since there was no reactions to the VOTE either pro or
contra for more then a mont,
seems to me we are in a serious problem, because
the developers/commiter interest is blocking the release.
The final solution is either to bring that to the tomcat pmc,
and if there is really zero interest on maintaining mod_jk,
among the current commiters, it should be either shut down,
or proposed as a new project with a different set of maintainers.

Regards,
Mladen.


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








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

DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 18:45 ---
Remy,

I am using Tomcat 5.5.9, and log4j is only being loaded within the webapp
context (not global) and I still get this problem.

To date everyone keeps on talking theory but no one had yet to offer a practical
solution. Both Brett and Yoav have suggested one, which is to allow a
configurable timeout value before the ClassLoader is invalidated. Granted it's
not foolproof (who knows how big the timeout needs to be), but at least it's a
practical solution. You mention there are some other solutions, what are some of
your practical solutions to this problem?

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

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

DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 18:36 ---
hey,

i wasn't really blaming log4j, i just noted from the many many posts for this 
bug that log4j came up a lot and taking a pragmatic view thought it may be 
addressable. however, i appreciate that if you were to do that, then where 
would you stop if other libs caused the same issue. it wouldn't be good to 
pollute tomcat's code to bypass known issues for sure. i jsut think that since 
it's mostly this log4j class causing the issue, someone somewhere could change 
the root cause.

i don't know .. just thinking out load ;)



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

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

Re: Sandbox ?

[Remy Maucherat]

Costin Manolache wrote:

On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:


For sending a file on a socket - I'm sure using apr would be faster (
is sendfile wrapper implemented ? ), you shouldn't have to read the
file in java.


You need to look a bit into the code ;)

There is:
- APRized HTTP connector with sendfile and poller usage for keepalive
- HTTPS support using OpenSSL
- APRized AJP connector with poller usage for keepalive


I tought there is something for keepalive in the java connector as
well - I guess I was looking in the wrong place, I know apr can do all
the cool things, but I couldn't find the equivalent code.
It may be nice - and maybe that would make the apr and java code share
more code :-)


No, there's nothing for the "pure" Java connectors. I don't see the 
point of trying to do it in "pure" Java, as:
- all the network code is native anyway, so it depends on if you prefer 
the native network code to come from the ASF or your JVM vendor ;)
- the API exposed to do the same thing in "pure" Java (when they exist) 
are unreasonably complex compared with APR



It is a way to do even-based IO for servlets - but regardless of name,
the actual feature can be
usefull. At least for a sandbox setting :-)  Not a big priority for me
- I was hoping other people would be interested too.


Did you look at SIP and SIP servlets ? (maybe you did at Motorola) I 
think the specification is complex, but it is actually designed for 
doing this kind of asynchronous IO processing. I don't really understand 
the point of trying to hack stuff based on the Servlet API and/or HTTP 
to do asynchronous processing, since neither has been designed for that.



- it encourages a design for servlets which will run very badly on other
servlet containers


Well, long running servlets ( bound to events or slow IO ) will run
bad anyway on pure threads servers. But if more servers support the
concept - maybe a good solution would emerge, and become part of a
future standard. It would certainly be better than seeing it in the
next servlet spec - without enough implementation experimentation.


This would make the programming model a lot more complex and would act 
funny with web frameworks. Honestly, I'm not hot about it right now.



It could be implemented relatively easily in the APRized connectors, but
given the cost to process a small request over a keepalive connection
(it's cheap; for example, the use case for this being a chat room, I
don't see how it would perform bad if using separate requests for each
message), I don't see any reason to support this.


In the chat room case - you can never get 'instant' messages, you
depend on the polling
 frequency.


Yes, it does add significant latency.

Rémy

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

DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 18:08 ---
(In reply to comment #36)
> although many comments say log4j has nothing to do with it which is 
> theoretically probably true, most of the time it appears like log4j is 
> causing 
> the issue. my latest threaddeath which i get around 5 times per day I suppose 
> after about 5 reloads indicates
> 
> INFO: Illegal access: this web application instance has been stopped already. 
>  
> Could not load org.apache.log4j.spi.ThrowableInformation.  The eventual 
> following stack trace is caused by an error thrown for debugging purposes as 
> well as to attempt to terminate the thread which caused the illegal access, 
> and 
> has no functional impact.
> 
> It does always appear to be this SPI class as long as I can remember. A 
> naiive 
> thought but perhaps if there were a way to stop this class entering loadClass 
> at the wrong time the threaddeath would disappear for most common cases since 
> everyone uses log4j with tomcat.

I don't see the point of blaming log4j as is. It's the same problem with any
shared library which would keep objects related to a webapp, while at the same
time being disconnected from the lifecycle (at best, memory leaking will occur).
I'd say the concept is to be blamed, but there are few solutions.

Problems can also be caused by not setting the context classloader well (I did
fix some more issues related to this in 5.5.9+, as JULI is quite sensitive to
that). I think the current code is now clean related to this.

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

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

DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 18:01 ---
I second that motion. I also keep on seeing that
"org.apache.log4j.spi.ThrowableInformation" error and I redeploy my application
a few hundred times a day (while developing under Netbeans) so this issue is
very critical to me. It would also be invaluable to have a minimal testcase for
this. Yoav (of Tomcat) has mentioned he'd work on a fix for this issue but we
need a testcase first (he can't reproduce it on his end).

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

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

Re: Sandbox ?

[Costin Manolache]

On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:

> > For sending a file on a socket - I'm sure using apr would be faster (
> > is sendfile wrapper implemented ? ), you shouldn't have to read the
> > file in java.
>
> You need to look a bit into the code ;)
>
> There is:
> - APRized HTTP connector with sendfile and poller usage for keepalive
> - HTTPS support using OpenSSL
> - APRized AJP connector with poller usage for keepalive

I tought there is something for keepalive in the java connector as
well - I guess I was looking in the wrong place, I know apr can do all
the cool things, but I couldn't find the equivalent code.
It may be nice - and maybe that would make the apr and java code share
more code :-)

> > An unrelated subject - don't know if you saw
> > http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html
> >
> > I don't like very much the implementation ( with Exceptions to control
> > the flow ), but I think there is a good idea to have support in the
> > thread pool to temporary release the thread for long-running servlets,
> > and then get a thread back on some event. How this is made visible to
> > servlets is debatable - I think there are few better ways than what
> > jetty is doing - but the low level is probably more important.
>
> I don't like it:
> - the naming is bad (this is using a poller to get read events, so it's
> basically an IO event mechanism)

Yes, the naming is horible - just some buzzwords with little
connection with the real feature.

It is a way to do even-based IO for servlets - but regardless of name,
the actual feature can be
usefull. At least for a sandbox setting :-)  Not a big priority for me
- I was hoping other people would be interested too.


> - it shouldn't just reinvoke the service method unless it can actually
> just continue transparently execution (also, in the "compatibility"
> mode, the execution path isn't the same), and creates the need for
> proprietary routing logic

I agree, the high-level doesn't look good - and it never does, for all
event-based systems :-), even those who don't try to hide this behind
a thread-based interface like service().


> - it encourages a design for servlets which will run very badly on other
> servlet containers

Well, long running servlets ( bound to events or slow IO ) will run
bad anyway on pure threads servers. But if more servers support the
concept - maybe a good solution would emerge, and become part of a
future standard. It would certainly be better than seeing it in the
next servlet spec - without enough implementation experimentation.


> It could be implemented relatively easily in the APRized connectors, but
> given the cost to process a small request over a keepalive connection
> (it's cheap; for example, the use case for this being a chat room, I
> don't see how it would perform bad if using separate requests for each
> message), I don't see any reason to support this.

In the chat room case - you can never get 'instant' messages, you
depend on the polling
 frequency.


Costin

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

DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 17:32 ---
although many comments say log4j has nothing to do with it which is 
theoretically probably true, most of the time it appears like log4j is causing 
the issue. my latest threaddeath which i get around 5 times per day I suppose 
after about 5 reloads indicates

INFO: Illegal access: this web application instance has been stopped already.  
Could not load org.apache.log4j.spi.ThrowableInformation.  The eventual 
following stack trace is caused by an error thrown for debugging purposes as 
well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact.

It does always appear to be this SPI class as long as I can remember. A naiive 
thought but perhaps if there were a way to stop this class entering loadClass 
at the wrong time the threaddeath would disappear for most common cases since 
everyone uses log4j with tomcat.



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

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

Re: [JK] Status -- was [VOTE] JK 1.2.15

[Glenn Nielsen]

I plan on installing 1.2.15 on FreeBSD 5.3 and Solaris 7 today and
do some minimal testing.

Glenn

On Mon, Oct 24, 2005 at 03:17:56PM +0200, Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
> >>
> >>Do you guys find something that would prevent 1.2.15 to
> >>be declared as stable that I'm missing?
> >
> >I'll try to find cycles to test myself, next week.  I know I'm having
> >alot of trouble with the apache 1.3 build on odd architectures, probably
> >because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based
> >httpd 1.3.  I'm working on cleaner autoconf against httpd-2.0 already 
> >for building mod_ftp, which will probably apply very cleanly here as well.
> >
> 
> Fine :)
> 
> Anyhow, what should I do, since I've volunteer for a RM?
> I mean, I don't expect to see the 1.3 branch for couple of
> months from now, and the 1.2.14 is unusable on Solaris, so
> we need some action. The 1.2.15 (bugfix) release is the
> only thing that is implementable right now, thought.
> 
> Since there was no reactions to the VOTE either pro or
> contra for more then a mont,
> seems to me we are in a serious problem, because
> the developers/commiter interest is blocking the release.
> The final solution is either to bring that to the tomcat pmc,
> and if there is really zero interest on maintaining mod_jk,
> among the current commiters, it should be either shut down,
> or proposed as a new project with a different set of maintainers.
> 
> Regards,
> Mladen.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

DO NOT REPLY [Bug 37218] - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 17:07 ---
(In reply to comment #4)
> Remy,
> 
> I don't understand what you mean in your last post. How is the error on the
> request thread related to the ThreadDeath issue I am seeing?

You were the one quoting another user about an irrelevant issue, so I was simply
pointing his problem was not the same as your problem.

> What I am seeing on my end is that as soon as I get a ThreadDeath from
> manager/redeploy then I am forced to restart the entire container (not only 
> the
> webapp). If I try to stop, then start the webapp without a full container
> restart, I get another fatal error.
> 
> Surely you don't expect us to restart the entire container every time we make 
> an
> application modification? On my end this can take up to 60 seconds, making
> development unbearable.

Yes, if you mess with the classloading and it ends up in an unpredictable state,
I expect you to restart the container. If you don't like it, then try to find
another, hopefully more robust, container, as I don't know how to make Tomcat
more robust for classloading handling.

As this is going nowhere (as with most of the bug reports you are involved with,
I have to note), this will be my last reply.


-- 
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 37218] - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 16:51 ---
Remy,

I don't understand what you mean in your last post. How is the error on the
request thread related to the ThreadDeath issue I am seeing?

What I am seeing on my end is that as soon as I get a ThreadDeath from
manager/redeploy then I am forced to restart the entire container (not only the
webapp). If I try to stop, then start the webapp without a full container
restart, I get another fatal error.

Surely you don't expect us to restart the entire container every time we make an
application modification? On my end this can take up to 60 seconds, making
development unbearable.

-- 
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 37220] - Semi-colon in filename HTTP bug

[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=37220


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 16:01 ---
Sorry, but anything after ';' is stripped off and treated as a path parameter,
even if ';' encoded. I don't want to take risks and handle this differently, so
this issue is not going to be fixed.

-- 
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 37218] - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:48 ---
(In reply to comment #2)
> Remy, please read comment #28 by Brett in
> http://issues.apache.org/bugzilla/show_bug.cgi?id=26372
> 
> and a newer comment #31 by Brett in
> http://issues.apache.org/bugzilla/show_bug.cgi?id=27371
> 
> Please note that http://issues.apache.org/bugzilla/show_bug.cgi?id=27371 is a
> newer issue than http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 which
> you are likely familiar with. Brett clearly states:
> 
> "I ran into this issue, and having written a trivial test case, I can confirm 
> that this zilla has nothing to do with logging (commons or log4j) or parent 
> classloaders etc.  No amount of fiddling with library classloading will fix 
> it."
> 
> So the Tomcat guys won't fix this, nor the Log4j guys. What are we left doing?
> What is your advice/suggestion for resolving this issue?

Completely unrelated. In this guy's case, the error will be on request
processing thread (with the only result being that his request will end sooner,
which is as expected in this situation).

-- 
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 37220] - Semi-colon in filename HTTP bug

[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=37220





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:32 ---
Created an attachment (id=16786)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16786&action=view)
Screen-dump of error-msg when I click the filename with semi-colon.


-- 
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 37220] - Semi-colon in filename HTTP bug

[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=37220





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:32 ---
Created an attachment (id=16785)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16785&action=view)
Screen dump of directorylisting with filename containing semi-colon. 


-- 
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 37220] New: - Semi-colon in filename HTTP bug

[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=37220

   Summary: Semi-colon in filename HTTP bug
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:HTTP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When trying to download a file via HTTP from Tomcat I an get error if the 
filename contains the semi-colon ; character.

I place a file with semi-colon in the filename under the Tomcat http server. 
When I am linking to that file (test;01.png) i get "the requested resource is 
not available.

Take a look at the attached screendumps.

Screen1 shows a directory listing of the file in question.
Screen2 shows the error-msg when i click the filename.

This is not a problem in Apache 2.0.53.
I tested and found this problem using IE 6.0 and Firefox 1.0.7 against Tomcat 
5.5.12 running on a Windows XP SP2 system.

-- 
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 37218] - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:30 ---
Remy, please read comment #28 by Brett in
http://issues.apache.org/bugzilla/show_bug.cgi?id=26372

and a newer comment #31 by Brett in
http://issues.apache.org/bugzilla/show_bug.cgi?id=27371

Please note that http://issues.apache.org/bugzilla/show_bug.cgi?id=27371 is a
newer issue than http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 which
you are likely familiar with. Brett clearly states:

"I ran into this issue, and having written a trivial test case, I can confirm 
that this zilla has nothing to do with logging (commons or log4j) or parent 
classloaders etc.  No amount of fiddling with library classloading will fix it."

So the Tomcat guys won't fix this, nor the Log4j guys. What are we left doing?
What is your advice/suggestion for resolving this issue?

-- 
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: [JK] Status -- was [VOTE] JK 1.2.15

[Mladen Turk]

William A. Rowe, Jr. wrote:


Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?


I'll try to find cycles to test myself, next week.  I know I'm having
alot of trouble with the apache 1.3 build on odd architectures, probably
because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based
httpd 1.3.  I'm working on cleaner autoconf against httpd-2.0 already 
for building mod_ftp, which will probably apply very cleanly here as well.




Fine :)

Anyhow, what should I do, since I've volunteer for a RM?
I mean, I don't expect to see the 1.3 branch for couple of
months from now, and the 1.2.14 is unusable on Solaris, so
we need some action. The 1.2.15 (bugfix) release is the
only thing that is implementable right now, thought.

Since there was no reactions to the VOTE either pro or
contra for more then a mont,
seems to me we are in a serious problem, because
the developers/commiter interest is blocking the release.
The final solution is either to bring that to the tomcat pmc,
and if there is really zero interest on maintaining mod_jk,
among the current commiters, it should be either shut down,
or proposed as a new project with a different set of maintainers.

Regards,
Mladen.


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

DO NOT REPLY [Bug 37218] - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:16 ---
This will not be addressed, as this does not make any sense.

-- 
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 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app

[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=27371


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 15:07 ---
*** Bug 36616 has been marked as a duplicate of this bug. ***

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

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

DO NOT REPLY [Bug 37218] New: - Configurable wait-time before invalidating ClassLoader on webapp redeploy

[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=37218

   Summary: Configurable wait-time before invalidating ClassLoader
on webapp redeploy
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Webapps:Manager
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This issue is related to BugZilla issues #26372 and #27371. The former older
issue indicates there is a bug in log4j. The latter newer issue points out there
is actually a Tomcat issue and absolutely cannot be fixed within the scope of 
log4j.

#27371 talks about a configurable wait-time setting in Tomcat but it looks like
no one has filed a BugZilla issue for it so this is it. As part of this issue,
I'm requesting that Tomcat allow us to configure the wait-time before it
invalidates the ClassLoader in order to fix issues #26372 and #27371. It is
important to note that there are no known workarounds for these issues at this
time (at least, not as far as I can tell).

I have filed this as a high priority issue because of the lack of a workaround.
As well, Netbeans development environment uses manager/redeploy every time the
webapp is modified (a few times a minute while I'm debugging) so using
reloadable=true is not an option. This is discussed in detail at
http://www.netbeans.org/issues/show_bug.cgi?id=62529

-- 
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 37215] - Wrong interpretation of static Content(Excel-File)

[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=37215


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 14:55 ---
Add following mime mapping to your conf/web.xml or WEB-INF/web.xml

   
  xls
  application/vnd.ms-excel
   

-- 
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 37215] New: - Wrong interpretation of static Content(Excel-File)

[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=37215

   Summary: Wrong interpretation of static Content(Excel-File)
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P1
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a Problem opening static Excel-Files with Tomcat5.5 (embedded in JBoss
4.0.3). All types of documents are opend the right way. Only Excel-Documents get
displyed wrong. When activating a Link on such a document the document gets
displayed as if it is of type html. The link is something like
http://localhost:8080/test/test.xls (in the root Directory of embedded Tomcat).
But when I activate it the Browsers uRL is right but the Document gets
interpreted as a html-page. I tried with JBoss 4.0.2 and 4.0.3 and it's the same
Problem. With Tomcat 4.0 (standalone) everything went fine. Any Ideas what the
Prblem could be?

-- 
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: Sandbox ?

[Remy Maucherat]

Costin Manolache wrote:

On 10/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:


I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
buffers ), and
you set it in the ByteChunk. "Extend" is not the best choice - it
would be hard to work with direct ( or other ) buffers. I'm actually
thinking about adding some static methods as well for all the utils we
have in BB.


I didn't do any tests, but accessing direct buffers contents seems
vastly more expensive. I don't see how they could be used other than for:
- buffering (as done in the APR connectors)
- transferring bytes without manipulating them in Java (ex: sending a
file on a socket)

Did you do some microbenchmarks ?


No - and I'm sure they wouldn't look very good, the current
implementation seems to just do JNI on each operation, so they are
probably more expensive

However - the fact that it is badly implemented now doesn't mean they
can't be implemented better in future or in a different VM :-), i.e.
with special support from the garbage collector, so it can be backed
by an unmovable byte[].  Realtime java JSR requires support for
unmovable objects ( afaik ) - so sooner or later we may have such a
VM, and then direct buffers would be the fastest way to communicate
between java and native.


Ok.


For sending a file on a socket - I'm sure using apr would be faster (
is sendfile wrapper implemented ? ), you shouldn't have to read the
file in java.


You need to look a bit into the code ;)

There is:
- APRized HTTP connector with sendfile and poller usage for keepalive
- HTTPS support using OpenSSL
- APRized AJP connector with poller usage for keepalive


Anyway - this is just a sandbox experiment, we can try different things.

An unrelated subject - don't know if you saw
http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html

I don't like very much the implementation ( with Exceptions to control
the flow ), but I think there is a good idea to have support in the
thread pool to temporary release the thread for long-running servlets,
and then get a thread back on some event. How this is made visible to
servlets is debatable - I think there are few better ways than what
jetty is doing - but the low level is probably more important.


I don't like it:
- the naming is bad (this is using a poller to get read events, so it's 
basically an IO event mechanism)
- it shouldn't just reinvoke the service method unless it can actually 
just continue transparently execution (also, in the "compatibility" 
mode, the execution path isn't the same), and creates the need for 
proprietary routing logic
- it encourages a design for servlets which will run very badly on other 
servlet containers
- the operations for saving/restoring of the request (basically 
equivalent to FORM) aren't exactly cheap, as well as the usage of a poller


It could be implemented relatively easily in the APRized connectors, but 
given the cost to process a small request over a keepalive connection 
(it's cheap; for example, the use case for this being a chat room, I 
don't see how it would perform bad if using separate requests for each 
message), I don't see any reason to support this.



BTW - where do we deal with keep-alive http connections ? ( I remember
you or Mladen added code to not keep the thread busy ).


The AprEndpoint does this stuff.

Rémy

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

DO NOT REPLY [Bug 37213] New: - problem when running tomcat with -security option

[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=37213

   Summary: problem when running tomcat with -security option
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: minor
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi all,

I got problem when running tomcat with -security option.

This is output
D:\Tomcat 5.5.12\bin>tomcat5 -security
[2005-10-24 15:10:09] [402  prunsrv.c] [error]
The operation completed successfully.
[2005-10-24 15:10:09] [1246 prunsrv.c] [error]
Load configuration failed

If i start tomcat without -security option it work fine.
What happen with me?

-- 
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 28222] - getRequestURL() in forwarded jsp/servlet doesn't return new url

[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=28222





--- Additional Comments From [EMAIL PROTECTED]  2005-10-24 09:13 ---
The problem is also that tomcat servlet's javadocs were (are still??) misleading
and sugesting behaviour of 5.0 tomcat.

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