>> v6.1 is out now - and BEA are not the quickest. True, naturally, opensource projects are always the fastest at adhering to standards - but my company has licenses for 6.0 only, so that is the version I have to work with.
>> You could always remove WLs version of avalon and replace it Avalon has nothing to do with Weblogic - it is used by cocoon, and comes distributed with it (it is a framework created by the Apache folks). >> What's wrong with tomcat? Nothing at all - see first answer. Waste of money paying zillions for weblogic licenses and then not using it at all ;-) Chris. -----Original Message----- From: Anthony Aldridge [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 3:40 PM To: [EMAIL PROTECTED] Subject: Re: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at las t :) v6.1 is out now - and BEA are not the quickest. You could always remove WLs version of avalon and replace it, or remove it form the system classpath and leave only in the webapp classpath (if that's still how WL 6.0 works - see my previous email). Good luck, Tony PS What's wrong with tomcat? [EMAIL PROTECTED] on 04/26/2002 02:33:10 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at las t :) Hi there good news and bad news - I have found the reason why the NoSuchMethodException is being thrown - I first dug out the source of the Avalon class that was throwing the exception, to find out what method was being expected. Here is the 'offending' method, which is found in the class org.apache.avalon.framework.configuration.DefaultConfigurationBuilder (inside Avalon version 4.1.2, which is used in Cocoon 2.0.2): public DefaultConfigurationBuilder( final boolean enableNamespaces ) { //yaya the bugs with some compilers and final variables .. try { final SAXParserFactory saxParserFactory = SAXParserFactory.newInstance(); if ( enableNamespaces ) { saxParserFactory.setNamespaceAware(true); } final SAXParser saxParser = saxParserFactory.newSAXParser(); this.setParser(saxParser.getXMLReader()); <--- THE PROBLEM } catch( final Exception se ) { throw new Error( "Unable to setup SAX parser" + se ); } } Note that the class expects there to be a method 'getXMLReader' available in the SAXParser object (javax.xml.parsers.SAXParser) - this is logical, because in the version of Xerces Cocoon was built against, this method exists. I then looked at the structure of the SAXParser class that Weblogic 6.0 SP2 uses, and found out that there is no 'getXMLReader' method!!! So who is to blame? Well, the offender is BEA - their JAXP API is broken, because it does not comply with the defacto standard, the one in the Java 1.4.0 API - whereas Avalon itself is completely justified in expecting the getXMLReader method, because it *should* be there according to Sun's API docs. Oh well, I'll have to work out how to bypass BEA's XML crud until a new service pack comes out for 6.0, I guess.... pffff.... Thanks to all the folks who tried to help me with my problem :) --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
