[Mav-user] Fixed Xalan/Domify problem

2002-02-26 Thread Jeff Schnitzer

I found the problem preventing Domify from working with Xalan 2.2 (or
later); the Document node adapter was not implementing hasChildNodes().
Apparently other processors never called it, so we never implemented it.

I've released a new version of Domify (1.0.1, at
http://domify.sourceforge.net) and a new (b3) beta release of the
opt-domify package.

One thing to note is that Domify now uses Log4J and prints a whole lot
of messages if you let it.  I have updated the log4j.properties in
maverick/tools to exclude DEBUG messages from the org.infohazard.domify
package and added instructions for this to the opt-domify release notes.

Jeff Schnitzer
[EMAIL PROTECTED]

___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user



RE: [Mav-user] problem with beta 2

2002-02-26 Thread Jeff Schnitzer

 From: jim moore [mailto:[EMAIL PROTECTED]]
 
 Maybe instead of writing a file, it would be better to be able to
 specify a command (similar to reloadCommand) which dumps the current
 config as a page.  That way it isn't necessary to worry about where
you
 can write to the filesystem, should getRealPath() be used, etc.
 
 I'm not sure. I'm thinking of situations where a developer who is
 unfamiliar
 with maverick inherits a project and has to get up to speed.
 
 While the ability to view dump the current config to a page would be
 useful
 for one developing a mav project (so yes, I am voting for this), I am
not
 sure it precludes or replaces dumping a file. (If the new developer
can
 find
 the command to do this, they are probably past the point where they
are
 looking for the file.)

Hmmm, seems to me that anyone who inherits a maverick project is going
to need some minimal amount of orientation anyways, and letting them
know about the currentConfig command would seem like an important step.
True, it's harder to guess than a maverick-processed.xml file, but at
least it's still available if you're using a WAR file.

 As far as where to dump the file, I would say just dump it to the same
 directory where you found maverick.xml. Just append -processed to the
file
 name (or something similar), so maverick.xml becomes maverick-
 processed.xml,
 and if they renamed maverick.xml to foo.xml, then foo-processed.xml
would
 be
 produced.
 
 If there is an IOException or some other problem, just log the
exception
 to
 System.err or better yet, use Log4J with a warn level.

You must be developing on a system by adding and editing files in a
directory structure :-)  I suspect that most people instead build WAR
files and deploy them into their containers.  Since I never actually
look at the expanded version of the WARs (if they even exist), I
wouldn't think to look there for a maverick-processed.xml... and I
suspect most people using WAR files are in the same boat.

I'm really averse to the idea of writing files, especially back into the
WAR.  It just seems to me that it is very likely not going to work and
it's not really intuitive; nothing else I've ever seen *writes* files to
the WEB-INF dir.  Yeah, someone could miss the special command, but
that's why I slave over the documentation :-)  If people end up asking
about it a lot on this list, I'll add it to the FAQ.

Jeff Schnitzer
[EMAIL PROTECTED]

___
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user