Derek Hohls wrote: > David > Thanks for the information - and the lecture...
Oh dear, i did not intend it to come across as a lecture. Sorry. I do tend to over-explain an answer for the benefit of everyone and various levels of understanding. > FWIW, the subject heading reflected my perception of the problem > *at the time*. As people posted replies, that perception changed. > I don't think it was any less obvious than some of the queries > which get posted on the list. And, yes, if no one replied or gave > any useful answers I would try and repost in some other way... That is a good approach. I understand now. > As for the logfiles you suggest examining, one of my frustrations > was that they were too big (over 100MB) to open with any editor > I have; my machine just fell over. Yes this is definitely an issue. Cocoon has many parts to it. If you set the log level to DEBUG then they all contribute messages to what becomes a big logfile. On UNIX there are no problems with text editors reading these and using internal search facilities to find the type of log entries that you want. On other systems that may be an issue. I certainly agree - i too have a hard time interpreting the logfiles. That cries out for some clever cookie to develop a Cocoon application that can interpret its own logfiles. A logfile is structured data so a generator could be written. > I am considering *downgrading* > the verbosity level. That is the intent. Start with DEBUG level. When all is running OK, then change the level to something appropriate for production. However, when i talked about "verbosity", i was not referring to the general Cocoon DEBUG level in logkit.xconf Rather i was meaning the Entity Resolver verbosity parameter. This is only for specific messages coming from the resolver. The default level is 1 (not much). Turn it up to see any errors. If there are any problems with the entity resolver, then they will be apparent at the begiining of the logfile. > I will now go away and do the reading you suggested... > > Derek > > PS The pages do now work - not sure what (if anything) changed > (maybe the restart of Tomcat??). Excellent news. That is possible. If i supsect a problem i always stop Tomcat clean out its work/ directory, a re-start Tomcat. If i have been fiddling with the source or updating the code, then i build clean and then build. --David > >>> [EMAIL PROTECTED] 20/02/2002 01:10:37 >>> > Derek Hohls wrote: > > I have feeling that the link to the oasis site needs to > > have to work properly... > > No it does not. This is one of the reasons for using > the Entity Resolver. You should be able to do your > Cocoon processing with absolutely no connection > to the Internet. Cocoon can then use local copies > of the DTDs. Have you looked at the documentation > userdocs/concepts/catalog.html ? > > I think that you need to look more carefully at your > logfiles. And please do what the documentation > advises you to do .... if you suspect problems with the > resolution of DTDs and other entities, then raise > the verbosity level in CatalogManager.properties > This will send messages to standard output during > Tomcat/Cocoon startup. There is also another verbosity > setting in webapp/cocoon.xconf which will re-set the > level during Cocoon operation after startup. > (Remember that this, and many other, section of the > xconf is incorporated at build time.) > > You can, of course, bypass the entity resolver completely > and hack your XML instance documents to have a local > System Identifier in the doctype declaration. This will > force the parser to use local copies of the DTDs. > However, this is not the desired option. The entity > resolver should find the local DTDs for you and so you > do not need to mess about with the input XML instances. > > By the way, this issue has nothing to do with the > "stylesheets" as the email subject indicates. > Everyone needs to be very careful with email subject > lines, or your postings will get missed on these very > busy lists. > > --David --------------------------------------------------------------------- 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]>
