DO NOT REPLY [Bug 13285] - admin web application fail with virtual host

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285

admin web application fail with virtual host

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-17 08:06 ---
As Larry said to me, 
I reopen the bug to "force" the patch to be included/resolved in  Tomcat 3.3.2.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13715] - can't do include of fragment named .jspf

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13715

can't do include of fragment named .jspf





--- Additional Comments From [EMAIL PROTECTED]  2002-10-17 08:11 ---
The patch which should fix the problem has been ported to 5.0, and is included
in the 5.0.0 milestone. However, it doesn't look like it has been integrated in
any J2EE related tags.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13723] New: - Bootstrap: Class loader creation threw exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723

Bootstrap: Class loader creation threw exception

   Summary: Bootstrap: Class loader creation threw exception
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I startup the Tomcat server it threw 
java.lang.IllegalMonitorStateException: current thread not owner

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Context loading order in TC 4.1/5 ?

[Henri Gomez]

How did I specify a context loading order with Tomcat 4.1/5 ?

ie :

ROOT, then app1, app2, zorg1, app3 ?

In tomcat 3.3.1, it was easy by adding  in server.xml,
but it seems that TC 4.1.x didn't follow the order of appareance in
its server.xml.

Thanks for your advices ;)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13726] New: - WAR files does not unpack/extract automatically

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726

WAR files does not unpack/extract automatically

   Summary: WAR files does not unpack/extract automatically
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when using the manager to deploy webapps, it does not extract the war files in my 
webapps 
folder.

I have these settings in my server.xml




1. The 
application is working but why is it not extracting the war file? 
2. I normally install webapps 
with just 

http://localhost:8080/manager/install?path=/sample&war=jar:file:/usr/local/tomcat/webapps/sample.war!/

I 
checked the work directory and i can see my webapp there. When does the unpacking of 
war files, and 
starting of app service occur?

For now i am using tomcat 4.0.4

Thank You.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699

Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1





--- Additional Comments From [EMAIL PROTECTED]  2002-10-17 09:34 ---
Could you send us an example servlet/jsp so I could make more tests and try to
locate this one ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13726] - WAR files does not unpack/extract automatically

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13726

WAR files does not unpack/extract automatically

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2002-10-17 09:45 ---
Well, this doesn't count as a bug, as it is expected behavior (long running
story of confusion with the Catalina deployer). Only the auto-deployer is
affected by the attributes you used.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Vote results + Security Audit redirection

[Paul Speed]

Costin Manolache wrote:
> 
> IAS wrote:
> 
> > I got a little bit curious about why finding bugs relevant to security
> > and fixing them should be not open. I don't doubt that there are both
> > merit and demerit of discussing those critical issues with full
> > disclosure. Absolutely there may be some peril that some (bad) people
> > can misuse the opened information purely exposed to help tomcat
> > community to collaborate against security problems. Regardless of such
> > understanding, I feel sorry about loss of the potential that more
> > openness can give more people chances to figure out the shared troubles
> > and remind them of importance of security at an early stage.
> 
> The problem is when the bad people find out about the security
> problems before they are fixed. I'm not saying that anyone subscribe
> to tomcat-dev is 'bad', but the list is archived and google searchable
> and has a lot of subscribers.
> 
> All information will become public - it's just that I think it is
> better ( at least for the bugs we discover ) to first have a fix.
> You probably noticed most of the announcements on security issues
> from apache and many other organizations include a fix or at least
> workaround. It is a common practice to have the security issues
> forwarded first to some commiters, and then made public. And I think this
> should be true not only for bugs found from outside, but also from
> inside.
> 
> > There was also some comment about "other special issues", which has not
> > been clear to me yet.
> 
> It's not clear to me either :-)
> 
> Maybe short notices like "I want to propose X as a commiter, does
> anyone has any objection ?" - to avoid some of the unpleasant
> things we had in the past. That's the only example I can think
> of.

Except, this is exactly the kind of thing I think should stay on this
list.  A slippery slope indeed.

Maybe all tomcat-dev traffic should be vetted through this other
list first and posted here at a 1 to 2 week delay, just in case 
something is mentioned that might turn out with analysis to be a
security risk.  The more security through obscurity the better,
right? ;)

The nice thing about your current way of dicussing security issues
(CC e-mail threads) is that it's a real pain in the butt.  In other
words, likely only to be used in the cases of necessity.

I think the only way you can keep the new list from feeling like a 
double secret exclusive club is to forward _all_ traffic at some
delay and keep that traffic to a minimum.  Otherwise, it's going to
start feeling an awful lot like some of you felt when working for
Sun were having extended offline discussions that eventually just
popped up here as a pre-resolved proposal/issue.  Wish I could
site a specific case, but it was a while ago.  It will be as 
frustrating as waiting for a JSR public draft.

Sorry, I didn't mean to go on so long originally.  There's just
something about all this that worries me a bit.  Perhaps because
noone else seems particularly concerned.

Oh well, what do I know.
-Paul

> 
> > Basically, I hope every discussion among Apache Jakarta Project
> > developers would be as open and transparent as possible.
> 
> Same for me.
> 
> My main goal was to get all active commiters involved in future
> security issues. We are all equally responsible.
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13723] - Bootstrap: Class loader creation threw exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13723

Bootstrap: Class loader creation threw exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-10-17 12:20 ---
I never encountered any problem like this with Tomcat on Win 2k or XP, nor can
reproduce this. There is probably a setup problem somewhere (or at least, you'll
have to give very detailed instructions on how to reproduce thise - and for
starters, you *must* include the full stack trace when dealing with
never-before-seen errors).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: uri mapping problems

[Mladen Turk]

> -Original Message-
> From: jean-frederic clere 
> 
> I am fighting with the mapping of mod_jk2. (Apache-2.0).
> I have noted that things like [uri:/*_servlet_vehicle/*] is 
> not working.
> 

Cannot work like that having starURIstar only URI/star cause we only
have prefix match. I'm not sure that mod_jk can be used for that either.
Can be done but I'm not sure are there any specification limitations or
rules that forbid that. Also where in the mapping tree would such a
pattern get matched (I suppose after prefix, but before suffix).
If there are not such limitations then we'll need some sort of reverse
prefix mapping.

MT. 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: