Re: Problems under 1.5 Was: [site] New Jakarta download pages
On Tue, 22 Feb 2005, Henri Yandell [EMAIL PROTECTED] wrote: The current problems are largely due to a stupid assumption on my part that Xalan would be the JDK xslt handler forever. XSLTC is considered the next generation of Xalan, or so it seems. Looking at our Gump experience, whichever versions of Xerces and XSLTC are included with JDK 1.5, they must be quite different from the Apache CVS versions (Apache Xerces doesn't fully support DOM3 yet, xml-commons is still at JAXP 1.2 level, XSLTC from CVS HEAD doesn't even build under JDK 1.5 using any released version of Ant ...) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] bug update
On Tue, 22 Feb 2005, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 23 Feb 2005 00:41:38 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Known problems: * Chain, IO, Transaction, Validator use .MD5 instead of .md5 I think this is an Ant vs. Maven issue, although I don't recall which way around. Ant's checksum task has a fileext attribute. If you don't set it, it defaults to the name of the algorithm, so it would be .MD5. Using the fileext attribute, you can easily use whatever you want. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems under 1.5 Was: [site] New Jakarta download pages
On Wed, 23 Feb 2005, Stefan Bodewig wrote: On Tue, 22 Feb 2005, Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 22 Feb 2005, Stefan Bodewig wrote: While it was using XSLTC, which is the TraX processor shipping with JDK 1.5. We now switched to Xalan-J's CVS HEAD. I give up :) How would I force it to be dependent on a particular version of Xalan? Check the jar as well as an xml-apis jar from xml-commons (or from Xalan itself) into svn, write a build.sh/.bar combo that ensures those two jars end up in the bootclasspath and force all people to use the scripts instead of Ant directly. I can't think of any other way, sorry. I assume that the JDK stuff in the classpath is going to butcher even an attempt to use Xalan directly via the java tag. The script would be as simple as , | #!/bin/sh | | ANT_OPTS=-bootclasspath path-to-xml-apis.jar:path-to-xalan.jar ant $@ ` Hmm, you'll probably need to include a matching version of Xerces as well. Painful. Geir's laughing at me right now :) Maybe there is a way to do what you trying to do with XSLT in Ant, even if it may seem less easy. At the risk of overcommitting, what exactly requires Xalan-J ATM? Maybe I can come up with something that's going to work with Ant, even if I have to write a custom task (something I'm not really afraif of). 3 problems with Xalan-XSLTC. The first is easy, changing xhtml to xml. The second is the use of the redirect extension. In XSLTC it's putting the files into cwd and not into the directory of the target file. If I dig a bit into xsltc, it might have more available to its redirect tag, or I could add a move to Ant (if I could get it to work for foo*.xml instead of **/*.xml). The third is just that XSLTC orders the attributes differently from Xalan, so every site build is going to hit lots of pages (ie bad svn diffs) if we switch back and forth between JVMs. xsltc appears to sort the attributes of a html tag differently so if we have 1 person using 1.4 and 1 using 1.5, our diffs are going to be spammed by attributes rotating back and forth. That's a problem. Also XSLTC requires far more heap memory than Xalan-J 2.x. Hadn't noticed the memory being a problem, but wasn't really looking. The speed was impressive :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems under 1.5 Was: [site] New Jakarta download pages
On Wed, 23 Feb 2005, Henri Yandell [EMAIL PROTECTED] wrote: I assume that the JDK stuff in the classpath is going to butcher even an attempt to use Xalan directly via the java tag. If you use bootclasspath instead of classpath it should work. The second is the use of the redirect extension. This is where I thought we might use a different solution. Use an Ant task instead of redirect extensions. The third is just that XSLTC orders the attributes differently from Xalan, so every site build is going to hit lots of pages (ie bad svn diffs) if we switch back and forth between JVMs. Yes, I've seen you mention that and looked for a way to control the behaviour of either - haven't found anything yet. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector]
it may well be wiser to discuss these matters on lists which are not public. brian's usually very well informed about such matters. i wonder whether henri might be able to bring this up (either formally or informally) with aim of discovering whether jakarta in general and tomcat in particular have the right structures in place and what improvements we might make. - robert On 22 Feb 2005, at 02:23, Henri Yandell wrote: On Mon, 21 Feb 2005, Mark Thomas wrote: Hi, Having just dealt with the issue below I was thinking where else, other than the Tomcat User mailing list this information needed to be sent? That got me thinking about the wider issue of handling security issues at Jakarta/Apache. I went looking for, but failed to find, answers to the following questions: 1. Does anyone monitor the issues reported to [EMAIL PROTECTED] to ensure that they are evaluated and, if necessary addressed, in a timely manner? If yes, who? If not, should we? I think the httpd folks tend to monitor [EMAIL PROTECTED], and forward Tomcat specific ones over to the [EMAIL PROTECTED] list. There've been a couple of emails that have processed that way. 2. Do we publish anywhere a list of known security issues and their associated fixes? If yes, where? If not, should we? Not that I know. I'd assume it'd be a Tomcat page somewhere? So much of Jakarta/Apache is outside the obvious realm of security issues that I think it's probably a (sub-)community based issue. Does anyone here know the answers to these questions? I don't :) I imagine Tomcat should approach things with the same stance that Httpd has towards such issues (whatever that is), and possibly get a couple of people on [EMAIL PROTECTED] if they're not already. Hen Original Message From: Mark Thomas [EMAIL PROTECTED] All, A security issue has come to light where a mal-formed request may result in JSP source code disclosure. This issue only applies if all of the following are true: 1. You are using any Tomcat 4 version = 4.1.15 2. You are using the deprecated HTTP 1.1 connector (org.apache.catalina.connector.http.HttpConnector) 3. You have configured 1 or more contexts served by the connector with a resources element that uses the allowLinking parameter and this parameter is set to true. The fix is to use the Coyote HTTP connector (org.apache.coyote.tomcat4.CoyoteConnector). The on-line Tomcat 4 docs have been updated to include a warning about this configuration combination. The next Tomcat 4 release will include the updated documentation. If you are using Tomcat 4 with the standard Coyote HTTP connector this issue does not apply. Tomcat 5.0.x and 5.5.x are unaffected by this issue. Thanks are due to Glenn Choat who reported this issue to the Tomcat team last week. As a reminder, if you have a verified security bug to report please do not post it to email lists or submit a bug report. Security bugs should be reported privately by email to [EMAIL PROTECTED] Regards, Mark - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] More pages to delete
nicola indicated to me that the incubator might be interested in some of the content of this nature. be easier to offer the content whilst it's still up. anyone want to volunteer to take this to the incubator? (if no one jumps in, i'll try to find to do it in the next few days.) - robert On 22 Feb 2005, at 05:28, Henri Yandell wrote: Continuing my quest to reduce the Jakarta site to a 'under construction' image: * Delete packageversioning* files. * Delete versioning.html. * Delete idedevelopers.html. Nothing within the Jakarta site links to these pages. - Versioning is a nice enough document, but not one that we use afaik. Idedevelopers is just out of context now. The subpages to do with remote debugging of Tomcat moved to Tomcat a while back, and we don't seem to get these kind of questions anymore. Packageversioning is another nice enough document that I don't think is focused on at all. - Alternatively, should these move somewhere? I think the Java-specific content was turned down for www.apache.org, but we could start to build Java-specific content onto java_at_apache.html? Hen - 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: [site] FAQs page
the incubator folks might appreciate an edited version of the apacheforge stuff. (a little famous in it's day.) any volunteers to contact incubator and offer to do the editing if the content appeals? - robert On 22 Feb 2005, at 05:50, Henri Yandell wrote: Last for the night I swear. Is there any life in the FAQs page? http://jakarta.apache.org/site/faqs.html A good portion of the FAQs have moved to TLP. The ApacheForge section is utterly redundant by the Incubator now, the servlet/jsplinks at the bottom are better placed on Tomcat's site and that just leaves the links to the coding conventions, which could be folded into one of the other project/development/guideline pages. Hen - 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: [site] killing vendors page
On Mon, 2005-02-21 at 19:20, Erik Hatcher wrote: On Feb 21, 2005, at 10:54 AM, Noel J. Bergman wrote: I'd suggest that we talk to the PRC about it. There are some good things about a vendors page. +1 anyone volunteer? Erik makes an interesting point about the Wiki, but it would mean that we couldn't vet it for content to prevent grossly misleading content. Lucene has a page like this here: http://wiki.apache.org/jakarta-lucene/Support All wiki changes are sent to an e-mail list for this very reason though, so that the community can vet it. If someone posted misleading content, I'm sure many would take action to correct it almost immediately. a vendor list is only as good as the company it keeps. i suspect that vendors would have a vested interest to keep it up to date. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] Working under 1.5 Was: Problems under 1.5
Following the lead of every great salesman, I'll begin by informing one and all that the site now generates under 1.5 quite happily. I'm using 1.5.0-rc under Debian Linux. If pine could do smallprint, I'd point out that 1.4 doesn't work now. I think it's going to be easier to fix 1.4 issues than to fix 1.5 issues. There's still the great big stinking pain of their different indentation/attribute-order, which we could possibly solve by shipping xsltc and forcing use of that. JDK 1.5 doesn't require the bootclasspath pain to get a different version of xsltc than the one in the jdk to work (as sun don't use the apache namespace for their variant). A driving reason for making 1.5 the working one and not 1.4 is that it's quite simply better. 10 seconds vs 2 minutes is hard to argue with. The biggest negative I know is that it cuts Mac users out (and I'm one of those). In a few months we'll be upgrading to 1.5 (Steve willing). I'll work on ant-hackery to make the 1.4 one at least be correct, and then hopefully we can echo a suggestion that using 1.5 is much preferable to 1.4 to avoid the evil svn diffs. If needed, we can then look at shipping xsltc with the build. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] .htaccess and site/.htaccess
Cool. I'll modify things to match this, we've gained a fair bunch of site ones in the top level .htaccess (all my fault I suspect). Hen On Wed, 23 Feb 2005, robert burrell donkin wrote: recommended by infrastructure as best practice. i think that it's for performance reasons. - robert On 22 Feb 2005, at 04:56, Henri Yandell wrote: Anyone know why we have two .htaccess files? Is there a performance reason or somesuch to keep the site/ redirects in its own .htaccess file? Hen - 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: [site] Working under 1.5 Was: Problems under 1.5
And now works under 1.4, at least my OS X. Still with the proviso that switching between 1.4 and 1.5 will lead to large svn diffs, so I've got a big warning at the top of the ant output that recommends 1.5. The hacks for 1.4 are clearly defined, but there is a bit of hard-coding of path into the xsl files to get it working under 1.5 that wouldn't be there if I had a clue how to make that work nicely. Hen On Wed, 23 Feb 2005, Henri Yandell wrote: Following the lead of every great salesman, I'll begin by informing one and all that the site now generates under 1.5 quite happily. I'm using 1.5.0-rc under Debian Linux. If pine could do smallprint, I'd point out that 1.4 doesn't work now. I think it's going to be easier to fix 1.4 issues than to fix 1.5 issues. There's still the great big stinking pain of their different indentation/attribute-order, which we could possibly solve by shipping xsltc and forcing use of that. JDK 1.5 doesn't require the bootclasspath pain to get a different version of xsltc than the one in the jdk to work (as sun don't use the apache namespace for their variant). A driving reason for making 1.5 the working one and not 1.4 is that it's quite simply better. 10 seconds vs 2 minutes is hard to argue with. The biggest negative I know is that it cuts Mac users out (and I'm one of those). In a few months we'll be upgrading to 1.5 (Steve willing). I'll work on ant-hackery to make the 1.4 one at least be correct, and then hopefully we can echo a suggestion that using 1.5 is much preferable to 1.4 to avoid the evil svn diffs. If needed, we can then look at shipping xsltc with the build. Hen - 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]
