Please stabilize this package, thank you.
x86 done
NO GO FOR X86! DirectoryIndex index.jsf JkOptions +ForwardDirectories does not work anymore with 1.2.20 + jboss 4.0.4.GA (= Tomcat 5.5). I don't know why (may be probably an upstream problem). Tested even with no optimization at all. I had to step back to 1.2.19.
Please report that to upstream and see what they say. Thank you.
I will, but 1.2.20 is the latest version available. I don't know which are the Gentoo policies about this, but I would avoid stabilizing the latest version of a component (not a product): I would prefer to have a look to the bugs fixed in the next release... It is easy in Gentoo to get latest, non-stable packages. It is not that easy to stick to a previous stable version when there is a later one.
Dropped http://issues.apache.org/bugzilla/show_bug.cgi?id=41430 upstream.
Considering this one was mostly bug fixes. Not sure if it's enough to prevent it from going stable on Gentoo. Since upstream considers it stable, less the problem you ran into. Not sure if any others are mapping .jsf or using the ForwardDirectories directive. I have been running 1.2.20 on my dev server since upstream released it without problems. But I am only mapping .jsps and sevlets. It's definitely not a good thing, but it's not a broken across the board in all cases. Just in some cases like yours. It will get worked and resolved, but not sure we should hold others back as well. Since there were many other bug fixes. But if others feel the same on this, I don't have any major objections to 1.2.20 not being stable, and reverting back to 1.2.19. But would prefer not to. Since in your case you can just package.mask the newer one till the problem you ran into is resolved. Since it does seem to be a problem coming from upstream.
Also if you would please try to run at least one server as ~arch. So we can catch this stuff before stabilization and report back to upstream faster. All while still in ~arch, so by the time we do stabilize. We have worked out problems like this. Also per bug report. If you find a patch that fixes this. Let me know I can add it to ebuild for now as a band aid. Till upstream does another release.
No need to ~x86 my system nor: upstream found the problem. It is a single-codeline change. The forward patch is available at http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?r1=478743&r2=478744&pathrev=478744&view=patch. It will revert almost smoothly (only a 55 lines offset with respect to final 1.1.20). It it meant to fix the obscure Native:JK bug 36121 ( http://issues.apache.org/bugzilla/show_bug.cgi?id=36121 ) so, whether reverted, this bug will be back. Stay tuned with Jakarta Native:JK bug 41430: I asked to the Jakarta team to decide which of the two behaviours (pre- or post-36121) is to be assumed the right one. Regarding Comment#6. Entering a debate about this is probably the last thing both you and me are looking for. My point is that probably most of the people working with Tomcat (and derivatives) is somehow "in touch" with the Jakarta team, while maybe 1/100 of them is also "in touch" with the Gentoo one. Stabilizing the latest version of a component voids the potential feedback of a lot of people which may, eventually, post a bug about past-compatibility breakages in Jakarta. If 1.1.21 would have reported "fix#xxx reverted back due to problem yyy", it would have been clear that 1.1.20 had not to get stable. That said, I'm fine with any decision Gentoo will take about this matter: now I'm prepared to backup somehow.
It seems these are the (forward) patches to be applied to 1.1.20: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diff&rev=478744&r1=478743&r2=478744 http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/changelog.xml?view=diff&rev=478744&r1=478743&r2=478744 They are basicly reverting mod_jk to the 1.1.19 way about this bug, and documenting this. I see nobody else reported this problem and I already got ride of mine. So, William, you have the option to go with a mod_jk-1.1.20-r1 or just wait for the next mod_jk-1.1.21 (which should probably fix it). Thanks,
(In reply to comment #9) Well, no: I was confused by a cross-posting, So please forget Comment#9. Sorry about this. Upstream seems to need more time to study a solution.
Yeah not sure what to think about all of this. I am not sure if it should prevent stabilization or what? My gut says we can go ahead and stabilize. Hopefully this only effects a few. I don't really have a problem with patching, but the patch is going to reverse another fix/update. If I understand things correctly. So upstream is pondering on how to do both, instead of the current one or the other. Not much I can do to resolve this, short of rolling up my sleeves and jumping in the ditch. I will likely wait to see what upstreams resolution is. Almost would be best if we could move this to another bug, but then will have to reference this one per the history. So will likely leave as is, and proceed with stabilization on other archs.
It is already stable and an -r1 version can't be shipped because we actually miss a patch. But it would probably be unconfortable to users to un-stabilize the already stabilized module. So, I guess the best move is to leave it stable, now.
Thanks for getting in touch with upstream on that. I am following the upstream bug so will keep my eye on the situation. Along with hopes for a resolution in 1.2.21
amd64 stable
Giampaolo, I just put 1.2.21 into tree, it's a dev/snapshot of a upcoming release. If possible please test to see if the problem you ran into is resolve or not. I am almost thinking we might want to start a new bug. Referencing this one, and of course the upstream one. Unless it's resolved in 1.2.21. Thanks
