XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

You should probably prefer getResource() or getResourceStream()
over getRealPath(), which only works if the webapp is being served
off the filesystem as individual files. Many servlet containers serve
directly out of war or ear composites (virtual filesystems) without
"exploding" them first.

The code ends up somewhat cleaner without the filesystem coupling:

URL url = sc.getResource("/WEB-INF/somexmlfile.xml");
if ( url != null ) {
        Document doc = parser.build(url);
}

Inexplicably, the servlet API doesn't reference getRealPath <-->  
getResource
with @see, leading to one annoying bug that typically rears it head only
at deployment time.

This leads to one issue I have with XOM, which is that it doesn't handle
catalog resolvers very elegantly. (It comes up here, because using  
getResouce
means the parser doesn't (necessarily) have base file to resolve  
relative
url's relative to, leaving you with only absolute url's for entities -  
unless
you implement a catalog resolver).

If you want to use a catalog to resolve entity references (dtd's,  
external
entities), which is a "good thing" (the classic Norm Walsh article is  
currently
at  
http://xml.apache.org/commons/components/resolver/resolver- 
article.html),
then you need to specify the parser explicitly, e.g.:

XMLReader reader = new  
org.apache.xml.resolver.tools.ResolvingXMLReader();
Builder builder = new Builder(reader);

While this solution is wonderfully for a mature system, but is quite a  
leap
for anyone other than an XML wonk. (This is as much to do with how the
fact that entity resolution is underplayed in the XML spec and  and only
the obvious implementation  
[http://xml.apache.org/commons/components/resolver/index.html]
is "buried" at apache as it does with XOM et. al.)

This means that you lose the nice touch of XOM finding the best parser
for the job, and that upgrading XOM and/or your XML parser can be quite
frustrating, particularly if you need to used the "endorsed" libraries  
mechanism,
which you do in a servlet context.

Since XOM is already "in the business" of picking parsers an has set the
"easy to learn" design objective, I think it would be a great service  
to reflectively
detect the resolver and create a resolving parser if possible. I  
believe this would
only effect the semantics of the Builder ctor and the system-specific  
details
of the underlying parser, and so could even be considered for 1.0.  
Failing
that, a documentation change, particularly in the tutorial, would help  
greatly.

Michael Abato

On Apr 5, 2004, at 5:20 PM, luca wrote:

> thanks for your help. Things seem to work now:
>
> //sc is instance of ServletContext
> String path = sc.getRealPath("/WEB-INF/somexmlfile.xml");
> File file = new File(path);
> if (file.exists()) {
>     obj = new Obj(file.toURI().toString());
> }
>
> this ends up in an invokation of :
>
> parser.build(file.toURI().toString());
>
> Hope this helps others in the future.
> Extra keywords for the archive: servlet, ServeletContext, tomcat,
> web application, webapp, getResource(), getResourceAsStream()
>
>
> luca
>
> Elliotte Rusty Harold wrote:
>
> > At 11:01 AM +0200 4/5/04, luca wrote:
> > > thanks, is there an API to do the encoding?
> > >
> > > I reported the expanded path, but my real problem is that
> > > I am building a web-application
> > > and I'll need to read my config XML file out of /WEB-INF/,
> > > which I can achieve through  
> > > ServletContext().getRealPath("/WEB-INF/myfile.xml").
> > >
> > > Also, will I need to append the "file:///" string at the beginning?
> > It depends on what  
> > ServletContext().getRealPath("/WEB-INF/myfile.xml") gives you. I'm  
> > not personally familiar with that method, but I suspect File.toURI()  
> > or File.toURL might be what you're looking for.
>
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest