Well done guys - just one question: does it still work as a unexpanded war file? ie, if you produce a war (apologies if this has been tested), drop it into tomcat with the "do not unpack" setting, is it ok?
J. > -----Original Message----- > From: David Crossley [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 28 November 2001 2:41 am > To: [EMAIL PROTECTED] > Subject: Re: found the cause of Bug #5060 build docs > > > David Crossley wrote: > > Gianugo Rabellino wrote: > > > David Crossley wrote: > > > > > > > Excellent, thanks everyone. That fixes it. > > > > I have committed the changes to CommandlineContext.java > > > > into HEAD only. > > > > > > > > Would people on all platforms, please please confirm that > > > > "build docs" now works for you. Then i will add the changes > > > > to cocoon_20_branch. > > > > > > > > > Unfortunately I can confirm a failure. This is W2K after a > clean checkout: > > > > > > ERROR 10068 [ ] ():Sitemap > > > org.apache.cocoon.ProcessingException: Could not read resource > > > > > > file:/C:/java/src/cvs/cocoon/HEAD/xml-cocoon2/build/cocoon/documen > tation/xdocs/catalog-test.xml: > > > org.xml.sax.SAXParseException: File > > > > > > "file:/C:/java/src/cvs/cocoon/HEAD/xml-cocoon2/build/cocoon/docume > ntation/xdocs/ISOnum.pen" > > > not found. > > > > > > Turning log up to DEBUG I get the following: > > > > > > [java] DEBUG 10068 [ ] (): ComponentFactory creating > > > new instance of org.apache.cocoon.components.resolver.ResolverImpl. > > > [java] DEBUG 10068 [ ] (): Setting Catalog verbosity > > > level to 2 > > > [java] DEBUG 10068 [ ] (): CommandlineContext: > > > getResource=/resources/entities/catalog > > > [java] DEBUG 10068 [ ] (): System Catalog URL is > > > > > > file:C:/java/src/cvs/cocoon/HEAD/xml-cocoon2/build/cocoon/document > ation/./resources/entities/catalog > > > [java] Loading catalog: > > > > > > file:C:/java/src/cvs/cocoon/HEAD/xml-cocoon2/build/cocoon/document > ation/./resources/entities/catalog > > > > > > Is there anything else I can do to help you out? > > > > Please do. If you raise the verbosity" to 3 in xconf > > may help. Obviously, i was concerned that we would > > simply transfer the problem from UNIX to Windows. > > > > I am just now trying the patch from Christian Schmitt > > to ResolverImpl.java though i suspect that our problem > > still lies with building the path in CommandlineContext.java > > The patch from Christian fixed it. Essentially the catalog loader > now uses a pathname to the default catalog which has an > appropriate absolute pathname for the OS and with no leading file: > > > Gianugo, you may understand better than me, the discussion > > about file:// problems that were identified and added to Bugzilla. > > That discussion may be still relevant for other issues. This patch > simply avoids the file:// problem. > > > My other concern is that if we fix it for the "build docs" > > commandline context, then we may break it for webapp context. > > Anyway, it is worth persisting - we seem close. > > --David > > We would now like to see some success reports from other > platforms, particularly Mac and other Windows. You need to > be able to run "build docs" without failing when it gets to > processing xdocs/catalog-test.xml and you need to see a > result from the webapp Sample "Entity Catalogs". > So far we have ... > Unix (Solaris 8) ... OK > Linux 2.4.2-2 (RedHat 7.1) and Blackdown j2sdk-1.3.1 ... OK > WinNT 4.0 ... OK > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
