Re: [Catalina] Using XML Parsing Package in "org.apache.tomcat .util.xml"

[ru...@us.ibm.com]

Craig R. McClanahan wrote:
> XmlMapper is quite nice.  I was able to set up the rules to read a
> configuration file for Catalina with almost no problems.
>
> I'd be happy to work on these (and add some more Javadocs :-).

I second the "quite nice" comment.  Just to warn everybody, I plan to be in
the same basic area.

While the approach is quite nice, errors in the configuration file are just
as likely to be reported as NullPointerExceptions or outright ignored.  I
don't plan to release the second milestone until this this is a bit more
robust.  I've already had people in my office this morning who have picked
up Tomcat and couldn't figure out how to get it to start...

I also have a pet peeve against people looking for setters by explicit
names instead of using Introspectors...

- Sam Ruby

P.S.  Automatic servlet reloading seems to be working, and sessions appear
to be retained across reloads.  I don't know how much of this was
accidental, and how much of it was hard work by Costin, but I do know that
I didn't have to do anything!  Hopefully I can return the favor by making
XmlMapper more robust.

Class reloading

[co...@eng.sun.com]

> P.S.  Automatic servlet reloading seems to be working, and sessions appear
> to be retained across reloads.  I don't know how much of this was

Only for objects that are loaded with the system loader - if you save a
String or any other objects for CLASSPATH, it's ok. 
If you save an object from WEB-APP/classes or /lib  - it will be lost or
you'll get exception...

Sorry about that, still a lot of work to do.

Costin

Re: [Catalina] Using XML Parsing Package in "org.apache.tomcat .util.xml"

[co...@costin.dnt.ro]

> I also have a pet peeve against people looking for setters by explicit
> names instead of using Introspectors...

There is a reason for that :-)

It's _VERY_ important to be able to separate the document from the
program. Look at web.xml - it may be the perfect format for an
xml configuration file, but that doesn't mean tomcat has to design the
objects based on it's DTD ! 

The reverse is also true - you may have the best design for a Java
application, if you design your DTD based on that you'll get a very bad
result. 

The worse is that if you have programming objects match XML structure,
you'll have problems doing changes and chosing the right internal
representation. You can represent everything as a graph ( xml tree +
pointers = graph), but graph alghoritms are most of the time very
expensive, and most of the "programming" is in using good data structures
and good alghoritms.

XmlMapper had to be able to read WEB.XML - it's the ultimate test for any
xml tool... 

XmlMapper solves a different problem than xml serialization or xml
bindings, where the xml file is generated based on java object structure.
 
It is very different from xsl - which does a lot of programming in xml. 
(in xsl you can sort a set of <tags> or pick the third from left ). 

"programming in java, data in xml :-)"


> While the approach is quite nice, errors in the configuration file are
just
> as likely to be reported as NullPointerExceptions or outright ignored.  I
> don't plan to release the second milestone until this this is a bit more
> robust.  I've already had people in my office this morning who have picked
> up Tomcat and couldn't figure out how to get it to start...

Yes, I know - but at least we have stack traces if that happens :-)
( i.e. we have some control )
You can get more help with:
    <xmlmapper:debug level="0" />

I will add more logs, and you can insert
   if( ctx.getDebug() > your_leve) ctx.log( "message" )
( and leave it there - in case something happens again )



Costin