Re: patch for ManagerServlet (was Re: yet another tomcat goes stable and I still have to make a custom package)
yep, I'll get this one in Haroon Rafique wrote: On Apr 6 at 9:54am, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote: HR> On Mar 22 at 3:04pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: HR> HR> FH> patch looks good to me, +1, HR> FH> if no objections arise, then I can submit, we'll wait until end of week. HR> FH> Filip HR> FH> HR> FH> http://issues.apache.org/bugzilla/attachment.cgi?id=17944 HR> FH> HR> HR> Any status on committing the above patch attached to bug 36847? HR> I hear talk of cutting a 5.5.17 release later this week. I would love to see the above patch integrated into 5.5.17. Thanks in Advance, -- Haroon Rafique <[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: patch for ManagerServlet (was Re: yet another tomcat goes stable and I still have to make a custom package)
On Apr 6 at 9:54am, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote: HR> On Mar 22 at 3:04pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: HR> HR> FH> patch looks good to me, +1, HR> FH> if no objections arise, then I can submit, we'll wait until end of week. HR> FH> Filip HR> FH> HR> FH> http://issues.apache.org/bugzilla/attachment.cgi?id=17944 HR> FH> HR> HR> Any status on committing the above patch attached to bug 36847? HR> I hear talk of cutting a 5.5.17 release later this week. I would love to see the above patch integrated into 5.5.17. Thanks in Advance, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch for ManagerServlet (was Re: yet another tomcat goes stable and I still have to make a custom package)
On Mar 22 at 3:04pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: FH> patch looks good to me, +1, FH> if no objections arise, then I can submit, we'll wait until end of week. FH> Filip FH> FH> http://issues.apache.org/bugzilla/attachment.cgi?id=17944 FH> Any status on committing the above patch attached to bug 36847? -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Yeah, new patch looks good. I'd add a logging statement to the simple stack trace so that people looking at the log can have a hint if this error actually occurs. Yoav On 3/22/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > patch looks good to me, +1, > if no objections arise, then I can submit, we'll wait until end of week. > Filip > > > > > http://issues.apache.org/bugzilla/attachment.cgi?id=17944 > > Haroon Rafique wrote: > > On Today at 2:47pm, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote: > > > > HR> > > HR> Patch 17943 submitted on bugzilla 36847. > > > > That should read Patch 17944. My mistake. > > -- > > Haroon Rafique > > <[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] > > -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
patch looks good to me, +1, if no objections arise, then I can submit, we'll wait until end of week. Filip http://issues.apache.org/bugzilla/attachment.cgi?id=17944 Haroon Rafique wrote: On Today at 2:47pm, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote: HR> HR> Patch 17943 submitted on bugzilla 36847. That should read Patch 17944. My mistake. -- Haroon Rafique <[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: yet another tomcat goes stable and I still have to make a custom package
On Today at 2:47pm, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote: HR> HR> Patch 17943 submitted on bugzilla 36847. That should read Patch 17944. My mistake. -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 1:07pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: FHDL> FHDL> exactly, this or a better fix: do this check inside the copy method. FHDL> FHDL> BASE vs HOME was just an example of a scenario that you didn't think FHDL> about, there are many more. so a patch should not break, but FHDL> improve. just like the one you suggested, all you have to do now is FHDL> to submit the actual patch file FHDL> FHDL> Filip Thanks Filip, Patch 17943 submitted on bugzilla 36847. http://issues.apache.org/bugzilla/attachment.cgi?id=17944 http://issues.apache.org/bugzilla/show_bug.cgi?id=36847 Regards, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Haroon Rafique wrote:
Replace:
copy(localWar, new File(getAppBase(), basename + ".war"));
with:
File secondCopy = new File(getAppBase(), basename + ".war");
if( !localWar.getCanonicalPath().equals(secondCopy.getCanonicalPath()) ) {
copy(localWar, secondCopy);
}
exactly, this or a better fix: do this check inside the copy method.
BASE vs HOME was just an example of a scenario that you didn't think
about, there are many more. so a patch should not break, but improve.
just like the one you suggested, all you have to do now is to submit the
actual patch file
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Hola, > As you can clearly see, BASE and HOME are different (and before you ask, > neither one of them is a symlink :-)) > > So, I modified ManagerServlet to show some debug output before the 1st > copy, inserted a Thread.sleep() in the middle and some more debug output > before the 2nd copy. Here are the results (in catalina.out): > > Copying > /www/tomcatbase/work/Catalina/localhost/manager/some-tag-here/sws.war to > /www/tomcatbase/webapps/sws.war > Length: 8047722 > Copying /www/tomcatbase/webapps/sws.war to /www/tomcatbase/webapps/sws.war > Length: 0 > > As you can see 2nd copy is trying to copy onto itself. Its not needed!! Excellent, this is good testing and progress. > Who do you want the feature to work for? > > a) People with default configuration > b) People with esoteric configurations that are yet to be discovered c) Everyone. > I would guess a) since most people run with CATALINA_HOME and > CATALINA_BASE as the same. Proving the above assertion would be difficult at best. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 12:11pm, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote:
YS> [..snip..]
YS>
YS> If you want to submit a more precise patch, i.e. one that checks for
YS> the tag usage and then only circumvents copies if the two files are
YS> indeed the same exact path (taking symlinks and catalina_base versus
YS> catalina_home into account), good. If you want to submit accompanying
YS> test cases, great. Both would be gladly welcomed.
YS>
I wouldn't even know where to begin to write a test case for this
scenario, so I will decline on that. The patch is easy enough:
(http://issues.apache.org/ is down at the moment)
Replace:
copy(localWar, new File(getAppBase(), basename + ".war"));
with:
File secondCopy = new File(getAppBase(), basename + ".war");
if( !localWar.getCanonicalPath().equals(secondCopy.getCanonicalPath()) ) {
copy(localWar, secondCopy);
}
All done!
YS> Like Filip, I'd -1 the patch as is because it's too general and
YS> doesn't seem to take into account scenarios where the two paths are
YS> different so the copy does not result in a zero-sized file.
YS>
YS> Yoav
YS>
Regards,
--
Haroon Rafique
<[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 12:11pm, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote: YS> [..snip..] YS> YS> You can call it paranoia if you wish, but I prefer caution. I'm not YS> about to go remove a line code in an important component that we know YS> is used in several paths through the code (corresponding to several YS> different deployment scenarios) and that has been stable for a year YS> plus save for the complaints from one user. I don't believe that YS> you're the only user of the tagging feature: simply given the YS> demographics of Tomcat adoption, I'd be unlikely to believe any one YS> feature only has one user. It's far more likely that the bug only YS> shows up in your particular environment. No one's contending that YS> you're seeing bad behavior, we just think the patch is too general and YS> risky as-is. YS> Fair enough. I'll do a test with different CATALINA_HOME and CATALINA_BASE. YS> YS> If you want to submit a more precise patch, i.e. one that checks for YS> the tag usage and then only circumvents copies if the two files are YS> indeed the same exact path (taking symlinks and catalina_base versus YS> catalina_home into account), good. If you want to submit accompanying YS> test cases, great. Both would be gladly welcomed. YS> If I find time, I'll work on the patch, but before I do that, let me show my setup with a different CATALINA_BASE and CATALINA_HOME. This is how I start my tomcat: env CATALINA_BASE=/www/tomcatbase /www/tomcat/bin/startup.sh The output comes out as: Using CATALINA_BASE: /www/tomcatbase Using CATALINA_HOME: /www/tomcat Using CATALINA_TMPDIR: /www/tomcatbase/temp Using JRE_HOME: /opt/sun-jdk-1.5.0.06 As you can clearly see, BASE and HOME are different (and before you ask, neither one of them is a symlink :-)) So, I modified ManagerServlet to show some debug output before the 1st copy, inserted a Thread.sleep() in the middle and some more debug output before the 2nd copy. Here are the results (in catalina.out): Copying /www/tomcatbase/work/Catalina/localhost/manager/some-tag-here/sws.war to /www/tomcatbase/webapps/sws.war Length: 8047722 Copying /www/tomcatbase/webapps/sws.war to /www/tomcatbase/webapps/sws.war Length: 0 As you can see 2nd copy is trying to copy onto itself. Its not needed!! YS> Like Filip, I'd -1 the patch as is because it's too general and YS> doesn't seem to take into account scenarios where the two paths are YS> different so the copy does not result in a zero-sized file. YS> As explained above, the paths cannot be different (even if BASE and HOME are different). They can be different if symlinks are used. I will ask again who knows what the 2nd copy is doing? And, yet again, I will be told its been there for over a year with no complaints. Phew!!! YS> Yoav YS> Who do you want the feature to work for? a) People with default configuration b) People with esoteric configurations that are yet to be discovered I would guess a) since most people run with CATALINA_HOME and CATALINA_BASE as the same. In addition, I have also shown that even if CATALINA_HOME and CATALINA_BASE are different the code is still at fault. Cheers, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Hola, > False information??? you guys are pretty paranoid. I explained clearly > that /www/tomcat is a symlink to /www/apache-tomcat-5.5.16. You can call it paranoia if you wish, but I prefer caution. I'm not about to go remove a line code in an important component that we know is used in several paths through the code (corresponding to several different deployment scenarios) and that has been stable for a year plus save for the complaints from one user. I don't believe that you're the only user of the tagging feature: simply given the demographics of Tomcat adoption, I'd be unlikely to believe any one feature only has one user. It's far more likely that the bug only shows up in your particular environment. No one's contending that you're seeing bad behavior, we just think the patch is too general and risky as-is. If you want to submit a more precise patch, i.e. one that checks for the tag usage and then only circumvents copies if the two files are indeed the same exact path (taking symlinks and catalina_base versus catalina_home into account), good. If you want to submit accompanying test cases, great. Both would be gladly welcomed. Like Filip, I'd -1 the patch as is because it's too general and doesn't seem to take into account scenarios where the two paths are different so the copy does not result in a zero-sized file. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 10:45am, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: FHDL> There are scenarios where CATALINA_BASE is different from FHDL> CATALINA_HOME, and not different as in symlinked, different as in FHDL> two different directories. FHDL> Thanks, now I'm beginning to understand the full implications. FHDL> Fliip I don't know much about running a different CATALINA_BASE and CATALINA_HOME but I'll try in a second and report back the results. Thanks, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
that doesn't change the flaw of the patch, if there are scenarios where
the paths indeed are different, then you need to answer the following
questions:
1. What are those scenarios
2. And is the code correct in those scenarios
otherwise, I would change your patch to just fix the copy method, that
when the destination and the source are the same, don't perform the
copy, then you can safely guarantee it to work.
but providing a patch that fixes your scenario, yet there is no proof
that it fixes all, will be hard to squeeze in.
There are scenarios where CATALINA_BASE is different from CATALINA_HOME,
and not different as in symlinked, different as in two different
directories.
Fliip
Haroon Rafique wrote:
On Today at 9:29am, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
FHDL> Haroon Rafique wrote:
FHDL> >/www/apache-tomcat-5.5.16/webapps/sws.war
FHDL> >/www/tomcat/webapps/sws.war
FHDL>
FHDL> this would turn my vote into -1, based on false information provided
FHDL> earlier.
FHDL> That should be explanation enough.
FHDL>
Hi Filip,
Seems like everyone is missing my point.
False information??? you guys are pretty paranoid. I explained clearly
that /www/tomcat is a symlink to /www/apache-tomcat-5.5.16.
FHDL> Haroon, you'd need to provide a more solid test case, if the paths
FHDL> indeed are different.
FHDL>
FHDL> Filip
To further quench your fears. I removed the symlink and actually named the
directory /www/tomcat. Then I changed the code in question to as follows:
if (tag != null) {
File localWarCopy = new File(deployed, basename + ".war");
System.out.println("Copying " + localWar + " to " + localWarCopy);
copy(localWar, localWarCopy);
System.out.println("Length: " + localWarCopy.length());
localWar = localWarCopy;
Thread.sleep(2);
File needlessCopy = new File(getAppBase(), basename + ".war");
System.out.println("Copying " + localWar + " to " + needlessCopy);
copy(localWar, needlessCopy);
System.out.println("Length: " + needlessCopy.length());
}
Pardon me for my sarcasm while I use a variable called needlessCopy.
Here's the output in catalina.out when I run a remote deploy with a tag
using ant:
Copying /www/tomcat/work/Catalina/localhost/manager/some-tag-here/sws.war
to /www/tomcat/webapps/sws.war
Length: 8047695
Copying /www/tomcat/webapps/sws.war to /www/tomcat/webapps/sws.war
Length: 0
You can draw your own conclusions. Are they identical???
FHDL>
FHDL>
FHDL> > On Today at 11:06am, RM=>Reinhard Moosauer <[EMAIL PROTECTED]> wrote:
FHDL> >
FHDL> > RM> Hi Filip, Haroon,
FHDL> > RM>
FHDL> > RM> as far as I understand, the problem is a copy operation which copies
FHDL> > RM> one file on itself.
FHDL> > RM> Haroon showed that this is happing in his case.
FHDL> > RM> Unfortunately, it it not proved that this is happening in all cases.
FHDL> > RM> Furthermore, the removal of the second copy operation could still
FHDL> > RM> cause a regression in other cases.
FHDL> > RM>
FHDL> >
FHDL> > Hi Reinhard,
FHDL> >
FHDL> > I'm obviously not very familiar with the tomcat code and by no means an
FHDL> > expert so I didn't realize that there was copy protection involved. In
FHDL> > any case, all of the involved code only works if tag is non-null. To my
FHDL> > knowledge, I'm the only one who uses remote war deployment while using
FHDL> > tags, and the empirical evidence that I have suggests that the 2nd copy
FHDL> > operation is not necessary (it could have even been a copy-and-paste
FHDL> > error).
FHDL> >
FHDL> > RM>
FHDL> > RM> Maybe we could fix the bug in a more secure way:
FHDL> > RM> How about adding a check to the copy()-method, so that it can no
FHDL> > RM> more delete a file by copying on itself?
FHDL> > RM> We could:
FHDL> > RM> 1. just ignore the copy if the 2 paths are the same
FHDL> > RM> 2. throw an IllegalArgumentException if the 2 paths are the same
FHDL> > RM>
FHDL> >
FHDL> > Gotta be careful here. When I said the 2 paths are same, I generalized a
FHDL> > little bit. The two paths are almost the same. They are:
FHDL> >
FHDL> > /www/apache-tomcat-5.5.16/webapps/sws.war
FHDL> > /www/tomcat/webapps/sws.war
FHDL> >
FHDL> > One of them involves a symlink. They are the same as long as you
FHDL> > consider the fact that /www/tomcat is a symbolic link to
FHDL> > apache-tomcat-5.5.16:
FHDL> >
FHDL> > lrwxrwxrwx 1 root root 20 Mar 21 14:33 /www/tomcat ->
FHDL> > apache-tomcat-5.5.16
FHDL> >
FHDL> > So, my (non-binding) vote :-), would be to:
FHDL> >
FHDL> > 1) Remove the 2nd copy() method all together
FHDL> > 2) Clean up copy() method to throw an IllegalArgumentException if the 2
FHDL> >paths are the same while *ALSO* taking into account any symbolic
FHDL> >links.
FHDL> >
FHDL> > RM>
FHDL> > RM> Personally, I would prefer the second solution, because it make
FHDL> > RM> errors like this one better to find in the future.
FHDL> > RM> The two code-lines removed by Haroon could have a try-catch-block to
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 10:15am, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote: YS> Hola, YS> YS> Hi, YS> YS> [..snip..] YS> YS> How would this be different in the case where CATALINA_BASE is not the YS> same as CATALINA_HOME? YS> I don't know. My guess would be that CATALINA_BASE would contain the uploaded file in the work/Catalina/localhost/manager/my-tag-here which will be copied to the webapps folder in the 1st copy() method. And then the 2nd copy() method will do "you should know what, at this point". Pardon me again as my tone expresses some frustration. YS> > I agree about test-coverage. YS> YS> More tests in this area would be awesome. YS> YS> Yoav YS> Cheers, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 9:29am, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
FHDL> Haroon Rafique wrote:
FHDL> >/www/apache-tomcat-5.5.16/webapps/sws.war
FHDL> >/www/tomcat/webapps/sws.war
FHDL>
FHDL> this would turn my vote into -1, based on false information provided
FHDL> earlier.
FHDL> That should be explanation enough.
FHDL>
Hi Filip,
Seems like everyone is missing my point.
False information??? you guys are pretty paranoid. I explained clearly
that /www/tomcat is a symlink to /www/apache-tomcat-5.5.16.
FHDL> Haroon, you'd need to provide a more solid test case, if the paths
FHDL> indeed are different.
FHDL>
FHDL> Filip
To further quench your fears. I removed the symlink and actually named the
directory /www/tomcat. Then I changed the code in question to as follows:
if (tag != null) {
File localWarCopy = new File(deployed, basename + ".war");
System.out.println("Copying " + localWar + " to " + localWarCopy);
copy(localWar, localWarCopy);
System.out.println("Length: " + localWarCopy.length());
localWar = localWarCopy;
Thread.sleep(2);
File needlessCopy = new File(getAppBase(), basename + ".war");
System.out.println("Copying " + localWar + " to " + needlessCopy);
copy(localWar, needlessCopy);
System.out.println("Length: " + needlessCopy.length());
}
Pardon me for my sarcasm while I use a variable called needlessCopy.
Here's the output in catalina.out when I run a remote deploy with a tag
using ant:
Copying /www/tomcat/work/Catalina/localhost/manager/some-tag-here/sws.war
to /www/tomcat/webapps/sws.war
Length: 8047695
Copying /www/tomcat/webapps/sws.war to /www/tomcat/webapps/sws.war
Length: 0
You can draw your own conclusions. Are they identical???
FHDL>
FHDL>
FHDL> > On Today at 11:06am, RM=>Reinhard Moosauer <[EMAIL PROTECTED]> wrote:
FHDL> >
FHDL> > RM> Hi Filip, Haroon,
FHDL> > RM>
FHDL> > RM> as far as I understand, the problem is a copy operation which copies
FHDL> > RM> one file on itself.
FHDL> > RM> Haroon showed that this is happing in his case.
FHDL> > RM> Unfortunately, it it not proved that this is happening in all cases.
FHDL> > RM> Furthermore, the removal of the second copy operation could still
FHDL> > RM> cause a regression in other cases.
FHDL> > RM>
FHDL> >
FHDL> > Hi Reinhard,
FHDL> >
FHDL> > I'm obviously not very familiar with the tomcat code and by no means an
FHDL> > expert so I didn't realize that there was copy protection involved. In
FHDL> > any case, all of the involved code only works if tag is non-null. To my
FHDL> > knowledge, I'm the only one who uses remote war deployment while using
FHDL> > tags, and the empirical evidence that I have suggests that the 2nd copy
FHDL> > operation is not necessary (it could have even been a copy-and-paste
FHDL> > error).
FHDL> >
FHDL> > RM>
FHDL> > RM> Maybe we could fix the bug in a more secure way:
FHDL> > RM> How about adding a check to the copy()-method, so that it can no
FHDL> > RM> more delete a file by copying on itself?
FHDL> > RM> We could:
FHDL> > RM> 1. just ignore the copy if the 2 paths are the same
FHDL> > RM> 2. throw an IllegalArgumentException if the 2 paths are the same
FHDL> > RM>
FHDL> >
FHDL> > Gotta be careful here. When I said the 2 paths are same, I generalized a
FHDL> > little bit. The two paths are almost the same. They are:
FHDL> >
FHDL> > /www/apache-tomcat-5.5.16/webapps/sws.war
FHDL> > /www/tomcat/webapps/sws.war
FHDL> >
FHDL> > One of them involves a symlink. They are the same as long as you
FHDL> > consider the fact that /www/tomcat is a symbolic link to
FHDL> > apache-tomcat-5.5.16:
FHDL> >
FHDL> > lrwxrwxrwx 1 root root 20 Mar 21 14:33 /www/tomcat ->
FHDL> > apache-tomcat-5.5.16
FHDL> >
FHDL> > So, my (non-binding) vote :-), would be to:
FHDL> >
FHDL> > 1) Remove the 2nd copy() method all together
FHDL> > 2) Clean up copy() method to throw an IllegalArgumentException if the 2
FHDL> >paths are the same while *ALSO* taking into account any symbolic
FHDL> >links.
FHDL> >
FHDL> > RM>
FHDL> > RM> Personally, I would prefer the second solution, because it make
FHDL> > RM> errors like this one better to find in the future.
FHDL> > RM> The two code-lines removed by Haroon could have a try-catch-block to
FHDL> > RM> ignore the IllegArgExc here (with a bold FIXME-Message to the log!)
FHDL> > RM>
FHDL> > RM> ***
FHDL> > RM> I suggest to be very careful in changing this part of tomcat. This
FHDL> > RM> case proves again, that the test-coverage in the manager code is not
FHDL> > RM> pretty good. Mainly because there are many configuration and
FHDL> > RM> deployment scenarios, which affect its behavior. (I suffered a
FHDL> > RM> similar case some days ago)
FHDL> > RM> ***
FHDL> > RM>
FHDL> >
FHDL> > I agree about test-coverage.
FHDL> >
FHDL> > I fully appreciate and understand the need for caution. However, by
FHDL> > their own admission, most tomcat developers do not have the time to test
FHDL> > the remote deployment while tagging
Re: yet another tomcat goes stable and I still have to make a custom package
Haroon Rafique wrote:
/www/apache-tomcat-5.5.16/webapps/sws.war
/www/tomcat/webapps/sws.war
this would turn my vote into -1, based on false information provided
earlier.
That should be explanation enough.
Haroon, you'd need to provide a more solid test case, if the paths
indeed are different.
Filip
On Today at 11:06am, RM=>Reinhard Moosauer <[EMAIL PROTECTED]> wrote:
RM> Hi Filip, Haroon,
RM>
RM> as far as I understand, the problem is a copy operation which copies one file
RM> on itself.
RM> Haroon showed that this is happing in his case.
RM> Unfortunately, it it not proved that this is happening in all cases.
RM> Furthermore, the removal of the second copy operation could still cause a
RM> regression in other cases.
RM>
Hi Reinhard,
I'm obviously not very familiar with the tomcat code and by no means an
expert so I didn't realize that there was copy protection involved. In any
case, all of the involved code only works if tag is non-null. To my
knowledge, I'm the only one who uses remote war deployment while using
tags, and the empirical evidence that I have suggests that the 2nd copy
operation is not necessary (it could have even been a copy-and-paste
error).
RM>
RM> Maybe we could fix the bug in a more secure way:
RM> How about adding a check to the copy()-method, so that it can no more delete a
RM> file by copying on itself?
RM> We could:
RM> 1. just ignore the copy if the 2 paths are the same
RM> 2. throw an IllegalArgumentException if the 2 paths are the same
RM>
Gotta be careful here. When I said the 2 paths are same, I generalized a
little bit. The two paths are almost the same. They are:
/www/apache-tomcat-5.5.16/webapps/sws.war
/www/tomcat/webapps/sws.war
One of them involves a symlink. They are the same as long as you consider
the fact that /www/tomcat is a symbolic link to apache-tomcat-5.5.16:
lrwxrwxrwx 1 root root 20 Mar 21 14:33 /www/tomcat -> apache-tomcat-5.5.16
So, my (non-binding) vote :-), would be to:
1) Remove the 2nd copy() method all together
2) Clean up copy() method to throw an IllegalArgumentException if the 2
paths are the same while *ALSO* taking into account any symbolic links.
RM>
RM> Personally, I would prefer the second solution, because it make errors
RM> like this one better to find in the future.
RM> The two code-lines removed by Haroon could have a try-catch-block to
RM> ignore the IllegArgExc here (with a bold FIXME-Message to the log!)
RM>
RM> ***
RM> I suggest to be very careful in changing this part of tomcat. This
RM> case proves again, that the test-coverage in the manager code is not
RM> pretty good. Mainly because there are many configuration and
RM> deployment scenarios, which affect its behavior. (I suffered a similar
RM> case some days ago)
RM> ***
RM>
I agree about test-coverage.
I fully appreciate and understand the need for caution. However, by their
own admission, most tomcat developers do not have the time to test the
remote deployment while tagging via ant. To my knowledge, I am the only
who uses this in production with tomcat 5.5.12+ (since I'm the only one
complaining about it for the last 6 months or so). Combined with the fact
that the whole operation is inside a if (tag != null) {} leads me to
believe that it is safe to take out the 2nd copy() method. Believe me,
with the 2nd copy() method in tact, remote deploying via ant while tagging
does *NOT* work.
RM>
RM> Please tell, if I can help
RM>
RM> Reinhard
RM>
You have helped already by replying.
Regards,
--
Haroon Rafique
<[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: yet another tomcat goes stable and I still have to make a custom package
Hola, > Gotta be careful here. When I said the 2 paths are same, I generalized a > little bit. The two paths are almost the same. They are: > > /www/apache-tomcat-5.5.16/webapps/sws.war > /www/tomcat/webapps/sws.war > > One of them involves a symlink. They are the same as long as you consider > the fact that /www/tomcat is a symbolic link to apache-tomcat-5.5.16: How would this be different in the case where CATALINA_BASE is not the same as CATALINA_HOME? > I agree about test-coverage. More tests in this area would be awesome. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
On Today at 11:06am, RM=>Reinhard Moosauer <[EMAIL PROTECTED]> wrote:
RM> Hi Filip, Haroon,
RM>
RM> as far as I understand, the problem is a copy operation which copies one
file
RM> on itself.
RM> Haroon showed that this is happing in his case.
RM> Unfortunately, it it not proved that this is happening in all cases.
RM> Furthermore, the removal of the second copy operation could still cause a
RM> regression in other cases.
RM>
Hi Reinhard,
I'm obviously not very familiar with the tomcat code and by no means an
expert so I didn't realize that there was copy protection involved. In any
case, all of the involved code only works if tag is non-null. To my
knowledge, I'm the only one who uses remote war deployment while using
tags, and the empirical evidence that I have suggests that the 2nd copy
operation is not necessary (it could have even been a copy-and-paste
error).
RM>
RM> Maybe we could fix the bug in a more secure way:
RM> How about adding a check to the copy()-method, so that it can no more
delete a
RM> file by copying on itself?
RM> We could:
RM> 1. just ignore the copy if the 2 paths are the same
RM> 2. throw an IllegalArgumentException if the 2 paths are the same
RM>
Gotta be careful here. When I said the 2 paths are same, I generalized a
little bit. The two paths are almost the same. They are:
/www/apache-tomcat-5.5.16/webapps/sws.war
/www/tomcat/webapps/sws.war
One of them involves a symlink. They are the same as long as you consider
the fact that /www/tomcat is a symbolic link to apache-tomcat-5.5.16:
lrwxrwxrwx 1 root root 20 Mar 21 14:33 /www/tomcat -> apache-tomcat-5.5.16
So, my (non-binding) vote :-), would be to:
1) Remove the 2nd copy() method all together
2) Clean up copy() method to throw an IllegalArgumentException if the 2
paths are the same while *ALSO* taking into account any symbolic links.
RM>
RM> Personally, I would prefer the second solution, because it make errors
RM> like this one better to find in the future.
RM> The two code-lines removed by Haroon could have a try-catch-block to
RM> ignore the IllegArgExc here (with a bold FIXME-Message to the log!)
RM>
RM> ***
RM> I suggest to be very careful in changing this part of tomcat. This
RM> case proves again, that the test-coverage in the manager code is not
RM> pretty good. Mainly because there are many configuration and
RM> deployment scenarios, which affect its behavior. (I suffered a similar
RM> case some days ago)
RM> ***
RM>
I agree about test-coverage.
I fully appreciate and understand the need for caution. However, by their
own admission, most tomcat developers do not have the time to test the
remote deployment while tagging via ant. To my knowledge, I am the only
who uses this in production with tomcat 5.5.12+ (since I'm the only one
complaining about it for the last 6 months or so). Combined with the fact
that the whole operation is inside a if (tag != null) {} leads me to
believe that it is safe to take out the 2nd copy() method. Believe me,
with the 2nd copy() method in tact, remote deploying via ant while tagging
does *NOT* work.
RM>
RM> Please tell, if I can help
RM>
RM> Reinhard
RM>
You have helped already by replying.
Regards,
--
Haroon Rafique
<[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Hi Filip, Haroon, as far as I understand, the problem is a copy operation which copies one file on itself. Haroon showed that this is happing in his case. Unfortunately, it it not proved that this is happening in all cases. Furthermore, the removal of the second copy operation could still cause a regression in other cases. Maybe we could fix the bug in a more secure way: How about adding a check to the copy()-method, so that it can no more delete a file by copying on itself? We could: 1. just ignore the copy if the 2 paths are the same 2. throw an IllegalArgumentException if the 2 paths are the same Personally, I would prefer the second solution, because it make errors like this one better to find in the future. The two code-lines removed by Haroon could have a try-catch-block to ignore the IllegArgExc here (with a bold FIXME-Message to the log!) *** I suggest to be very careful in changing this part of tomcat. This case proves again, that the test-coverage in the manager code is not pretty good. Mainly because there are many configuration and deployment scenarios, which affect its behavior. (I suffered a similar case some days ago) *** Please tell, if I can help Reinhard Am Mittwoch, 22. März 2006 00:54 schrieb Filip Hanik - Dev Lists: > aah got it, in that case, > > +1 > > to get this fixed, > will wait a day or two, if no minus one votes come up, I'll apply it for > you, just remind me :) > > Filip > > Haroon Rafique wrote: > > On Today at 4:02pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> > > wrote: > > > > FHDL> Question, if you remove the lines you mentioned, does the > > FHDL> application get deployed in your local instance, the one where the > > FHDL> manager servlet runs? Cause the line that is removed is where the > > FHDL> war is copied to the appbase of the host. > > FHDL> > > > > > > Hi Filip, > > > > Thanks to you too for responding. I don't really understand your > > question. With my "fix", the application gets deployed in the regular > > place (webapps directory) and I can see it under the manager servlet as > > well. I'm not quite sure what you mean by local instance?? > > > > The copy() line that is removed: > > > >copy(localWar, new File(getAppBase(), basename + ".war")); > > > > is pretty misleading. At this point, the value of localWar (the first > > argument) and new File(GetAppBase(), basename + ".war") is exactly the > > same. So, the call in fact clobbers a perfectly valid war file with a new > > 0-length file. In pseudo-code I can translate that to copy from an > > already existing war file onto itself (creating a new one in the process) > > and eventually end up with a 0-length file. As I explained in one of my > > earlier emails, the copy to appbase of the host has already happened in > > the previous copy() method call with no problems. > > > > As a test I put a Thread.sleep(2) in between the 2 copy methods and > > sure enough, the war file is full-length in the webapps directory after > > the 1st call and 0-length after the 2nd call. > > > > FHDL> > > FHDL> I haven't had time to run through this patch, but there should be a > > FHDL> -1 if we don't want it, and an explanation along with that. > > FHDL> > > FHDL> so I am +0 on it, since don't have time to test it > > FHDL> > > > > :-( Sorry to hear that, but at least you responded. Neutral is better > > : than > > > > negative. > > > > FHDL> > > FHDL> Filip > > FHDL> > > > > Cheers, > > -- > > Haroon Rafique > > <[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] -- Reinhard Moosauer IT Beratung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
aah got it, in that case, +1 to get this fixed, will wait a day or two, if no minus one votes come up, I'll apply it for you, just remind me :) Filip Haroon Rafique wrote: On Today at 4:02pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: FHDL> Question, if you remove the lines you mentioned, does the FHDL> application get deployed in your local instance, the one where the FHDL> manager servlet runs? Cause the line that is removed is where the FHDL> war is copied to the appbase of the host. FHDL> Hi Filip, Thanks to you too for responding. I don't really understand your question. With my "fix", the application gets deployed in the regular place (webapps directory) and I can see it under the manager servlet as well. I'm not quite sure what you mean by local instance?? The copy() line that is removed: copy(localWar, new File(getAppBase(), basename + ".war")); is pretty misleading. At this point, the value of localWar (the first argument) and new File(GetAppBase(), basename + ".war") is exactly the same. So, the call in fact clobbers a perfectly valid war file with a new 0-length file. In pseudo-code I can translate that to copy from an already existing war file onto itself (creating a new one in the process) and eventually end up with a 0-length file. As I explained in one of my earlier emails, the copy to appbase of the host has already happened in the previous copy() method call with no problems. As a test I put a Thread.sleep(2) in between the 2 copy methods and sure enough, the war file is full-length in the webapps directory after the 1st call and 0-length after the 2nd call. FHDL> FHDL> I haven't had time to run through this patch, but there should be a FHDL> -1 if we don't want it, and an explanation along with that. FHDL> FHDL> so I am +0 on it, since don't have time to test it FHDL> :-( Sorry to hear that, but at least you responded. Neutral is better than negative. FHDL> FHDL> Filip FHDL> Cheers, -- Haroon Rafique <[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: yet another tomcat goes stable and I still have to make a custom package
On Today at 4:02pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: FHDL> Question, if you remove the lines you mentioned, does the FHDL> application get deployed in your local instance, the one where the FHDL> manager servlet runs? Cause the line that is removed is where the FHDL> war is copied to the appbase of the host. FHDL> Hi Filip, Thanks to you too for responding. I don't really understand your question. With my "fix", the application gets deployed in the regular place (webapps directory) and I can see it under the manager servlet as well. I'm not quite sure what you mean by local instance?? The copy() line that is removed: copy(localWar, new File(getAppBase(), basename + ".war")); is pretty misleading. At this point, the value of localWar (the first argument) and new File(GetAppBase(), basename + ".war") is exactly the same. So, the call in fact clobbers a perfectly valid war file with a new 0-length file. In pseudo-code I can translate that to copy from an already existing war file onto itself (creating a new one in the process) and eventually end up with a 0-length file. As I explained in one of my earlier emails, the copy to appbase of the host has already happened in the previous copy() method call with no problems. As a test I put a Thread.sleep(2) in between the 2 copy methods and sure enough, the war file is full-length in the webapps directory after the 1st call and 0-length after the 2nd call. FHDL> FHDL> I haven't had time to run through this patch, but there should be a FHDL> -1 if we don't want it, and an explanation along with that. FHDL> FHDL> so I am +0 on it, since don't have time to test it FHDL> :-( Sorry to hear that, but at least you responded. Neutral is better than negative. FHDL> FHDL> Filip FHDL> Cheers, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Question, if you remove the lines you mentioned, does the application
get deployed in your local instance, the one where the manager servlet
runs? Cause the line that is removed is where the war is copied to the
appbase of the host.
I haven't had time to run through this patch, but there should be a -1
if we don't want it, and an explanation along with that.
so I am +0 on it, since don't have time to test it
Filip
Haroon Rafique wrote:
Hi Yoav,
Thanks for responding. Please see my replies below:
On Today at 11:26am, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote:
YS> Hi,
YS> The reason your patch hasn't been applied yet (or at least, the reason
YS> I haven't applied it yet, and I have looked at it once your twice) is
YS> that I'm sure the copy operation you remove is really redundant in all
YS> cases.
YS>
Please read on, and I'll prove to you that the code in question is in fact
a mistake.
YS>
YS> The copy operation seems to have been added as part of revision 303270
YS> committed on Thu Sep 23 07:03:27 2004 UTC by Remy. It's been nearly a
YS> year and half since then, with no complaints about this code except
YS> yours, so it seems to work for the majority of users. Accordingly,
YS> before we go and apply your patch, we'd need to be convinced that it
YS> doesn't introduce a regression failure.
YS>
Let the convincing begin...
[If you want, we can take this offline and you can reply inside bugzilla
36847.]
The code in question pre-revision 303270 used to look like this:
// Copy WAR and XML to the host base
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath, basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
}
The code after revision 303270 looks like this:
// Copy WAR and XML to the host app base if needed
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath,
basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
copy(localWar, new File(getAppBase(), basename +
".war"));
}
Can we agree on the fact that there are 2 copy() methods inside the
if (tag != null) {} code snippet?
If that is indeed the case, then can we also agree that this code only
runs when tag is not null and any modifications to this code will *NOT*
effect anything else as long as tag is null?
Now onto more. I can confirm for you that the following code snippet
inside an ant file does *NOT* work.
http://localhost:8080/manager";
username="username_here"
password="password_here"
path="/myapp"
update="true"
tag="some-tag-here"
war="file:/path/to/war/myapp.war"/>
Just because no one else has complained about it (for a year or however
long) does not mean that the bug does not exist. In my case, I always
get a:
SEVERE: Exception fixing docBase: {0}
java.util.zip.ZipException: error in opening zip file
followed by:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Invalid or unreadable WAR file
: error in opening zip file
in catalina.out. And for more proof the webapps directory contains a 0
length .war file.
1) Do you yourself use remote war deployment while using tags using ant?
2) Have you tried the above ant code snippet (after cleaning up some of
the attributes)?
3) How can we ship a tomcat with a broken feature that no one has really
bothered to test? Perhaps, (after fixing this) the next step is to
write an automated test for this. Remember this used to work in 5.5.9.
Now, I'll explain why it fails:
Here's the sequence of events (my context is called sws):
1) context is undeployed
2) local war is uploaded to:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
3) First copy() method copies:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
to new File():
/www/tomcat/webapps/sws.war
We have a good copy at this moment in time.
3) Second copy() method copies:
/www/tomcat/webapps/sws.war
to new File():
/www/tomcat/webapps/sws.war
essentially resulting in a 0-length file. Can you see my pain at this
point? The code has basically guaranteed a 0-length file.
Why is step 3) even necessary?
Furthermore, I can confirm for you that taking out the offending lines,
makes remote war deployment via tags 100% successful for me.
YS> [..snip..]
YS>
Thanks for listening,
--
Haroon Rafique
<[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Re: yet another tomcat goes stable and I still have to make a custom package
Hi Yoav,
Thanks for responding. Please see my replies below:
On Today at 11:26am, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote:
YS> Hi,
YS> The reason your patch hasn't been applied yet (or at least, the reason
YS> I haven't applied it yet, and I have looked at it once your twice) is
YS> that I'm sure the copy operation you remove is really redundant in all
YS> cases.
YS>
Please read on, and I'll prove to you that the code in question is in fact
a mistake.
YS>
YS> The copy operation seems to have been added as part of revision 303270
YS> committed on Thu Sep 23 07:03:27 2004 UTC by Remy. It's been nearly a
YS> year and half since then, with no complaints about this code except
YS> yours, so it seems to work for the majority of users. Accordingly,
YS> before we go and apply your patch, we'd need to be convinced that it
YS> doesn't introduce a regression failure.
YS>
Let the convincing begin...
[If you want, we can take this offline and you can reply inside bugzilla
36847.]
The code in question pre-revision 303270 used to look like this:
// Copy WAR and XML to the host base
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath, basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
}
The code after revision 303270 looks like this:
// Copy WAR and XML to the host app base if needed
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath,
basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
copy(localWar, new File(getAppBase(), basename +
".war"));
}
Can we agree on the fact that there are 2 copy() methods inside the
if (tag != null) {} code snippet?
If that is indeed the case, then can we also agree that this code only
runs when tag is not null and any modifications to this code will *NOT*
effect anything else as long as tag is null?
Now onto more. I can confirm for you that the following code snippet
inside an ant file does *NOT* work.
http://localhost:8080/manager";
username="username_here"
password="password_here"
path="/myapp"
update="true"
tag="some-tag-here"
war="file:/path/to/war/myapp.war"/>
Just because no one else has complained about it (for a year or however
long) does not mean that the bug does not exist. In my case, I always
get a:
SEVERE: Exception fixing docBase: {0}
java.util.zip.ZipException: error in opening zip file
followed by:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Invalid or unreadable WAR file
: error in opening zip file
in catalina.out. And for more proof the webapps directory contains a 0
length .war file.
1) Do you yourself use remote war deployment while using tags using ant?
2) Have you tried the above ant code snippet (after cleaning up some of
the attributes)?
3) How can we ship a tomcat with a broken feature that no one has really
bothered to test? Perhaps, (after fixing this) the next step is to
write an automated test for this. Remember this used to work in 5.5.9.
Now, I'll explain why it fails:
Here's the sequence of events (my context is called sws):
1) context is undeployed
2) local war is uploaded to:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
3) First copy() method copies:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
to new File():
/www/tomcat/webapps/sws.war
We have a good copy at this moment in time.
3) Second copy() method copies:
/www/tomcat/webapps/sws.war
to new File():
/www/tomcat/webapps/sws.war
essentially resulting in a 0-length file. Can you see my pain at this
point? The code has basically guaranteed a 0-length file.
Why is step 3) even necessary?
Furthermore, I can confirm for you that taking out the offending lines,
makes remote war deployment via tags 100% successful for me.
YS> [..snip..]
YS>
Thanks for listening,
--
Haroon Rafique
<[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: yet another tomcat goes stable and I still have to make a custom package
Hi, The reason your patch hasn't been applied yet (or at least, the reason I haven't applied it yet, and I have looked at it once your twice) is that I'm sure the copy operation you remove is really redundant in all cases. The copy operation seems to have been added as part of revision 303270 committed on Thu Sep 23 07:03:27 2004 UTC by Remy. It's been nearly a year and half since then, with no complaints about this code except yours, so it seems to work for the majority of users. Accordingly, before we go and apply your patch, we'd need to be convinced that it doesn't introduce a regression failure. For reference, Remy's commit notes on the patch read: - Fix some deprecation warnings. - Fix bug 31264: deploy should now behave correctly. Also move the writing of the WAR inside the isServiced block, so that if the uploading takes time, the auto deployer doesn't try to deploy it. - Add any deployment operation inside a try/finally block so that serviced is set back to false for the management operation, regardless of what occurs. There shouldn't be any unexpected exceptions thrown out there, but any problem would prevent further management of the application. Yoav On 3/21/06, Haroon Rafique <[EMAIL PROTECTED]> wrote: > Dear Tomcat Developers, > > I noticed that 5.5.16 has beeen voted as stable (no major issues) on March > 15th. To deploy this release in production I will have to make a custom > distribution (yet once again). The reason for this is that a simple bug in > ManagerServlet (reported by myself) has still not been fixed. Before I can > deploy a vanilla release to production, I need to have this bug committed. > I reported this bug 36847 in the tomcat 5.5.9 days (2005-09-28) and I also > did the analysis and provided a patch. > http://issues.apache.org/bugzilla/show_bug.cgi?id=36847 > > Would a tomcat developer be kind enough to take a look at the bug and > commit it, so that it makes it into the next stable release? I have sent > reminder emails before but have gotten no response. Is there anything else > I can do? > > Thanks In Advance, > -- > Haroon Rafique > <[EMAIL PROTECTED]> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
yet another tomcat goes stable and I still have to make a custom package
Dear Tomcat Developers, I noticed that 5.5.16 has beeen voted as stable (no major issues) on March 15th. To deploy this release in production I will have to make a custom distribution (yet once again). The reason for this is that a simple bug in ManagerServlet (reported by myself) has still not been fixed. Before I can deploy a vanilla release to production, I need to have this bug committed. I reported this bug 36847 in the tomcat 5.5.9 days (2005-09-28) and I also did the analysis and provided a patch. http://issues.apache.org/bugzilla/show_bug.cgi?id=36847 Would a tomcat developer be kind enough to take a look at the bug and commit it, so that it makes it into the next stable release? I have sent reminder emails before but have gotten no response. Is there anything else I can do? Thanks In Advance, -- Haroon Rafique <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
