As well, heres a simple example of using the JAXP XPath API.


Mark R. Diggory wrote:
I've been listening on this discussion and wanted to make some recommendations on packages that are available for handling application configuration.

In regards to merging xml based configs, I highly recommend a couple Apache Jakarta Commons projects that allow such a Dynamic merging/loading and are actually used in production by Tomcat and Struts.

As well, if you are really going to go down the route of wanting to work directly with JDOM or DOM (Not something I recommend) I'd suggest using Saxons XPath/XQuery API over Jaxen or JXPath, these XPath evaluators are far from complete in capability of processing XML, you'll find no elegant support for Namespaces in them. As well, I'd recommend moving to Saxon as the default XSL transformer for DSpace, Saxon is the only XSLT 2.0 implementation I've seen to date and probably the best open source XQuery engine for processing XML documents out there.

Both Xalan and Saxon support an XPath API and this API is used at least by Saxon to provide an implementation to the JAXP 1.3 XPath API. I suspect the classes your seeing in Xalan are used to provide the same support

Mark Diggory
Software Developer
Harvard MIT Data Center
Apache Jakarta Commons

Richard Jones wrote:
Hi Larry,

to follow.  I have a similar issue at the moment in that I have tried to
use XPath in JDOM to discover that we also need to use Jaxen
(  This is also distributed under an Apache-like licence
You're in luck, I'm using jaxen in the LNI already.  JDOM can supposedly
interface to other XPath implementations -- what XPath do we have
already?   Don't worry about dropping JDOM, I've put it in a patch already.

Cool.  There is actually already a JDOM JAR in the cvs.  As part of the
existing DSpace distribution there is something called the XPathAPI.
It's part of the Xalan library I think.

Back to merging XML files, it occurs to me we could really use a general
tool that does this well, not just for web.xml.  The Grouper example
is a great start, I think it could easily be adapted, e.g. to process
files in the order we want, and operate on XML structures in memory rather
than writing out temp files all the time.  I'm using memory-based
XSL transformations right now in the XSL-driven crosswalk plugins.

Each type of XML document will need a profile listing the elements to
process, which is necessarily like having a second schema or DTD, and it'll
have to be maintained when the schema changes.  But it's easier than
changing code, I think.

Yeah, definitely.  A general tool like this seems like a great idea.
Perhaps this is the sort of thing that has also been done before, and
perhaps where the guys from Grouper got the idea?  If their code can be
generalised relatively simply, though, we should give it a go.

How would folk like to proceed on this?

I hope add-ons will still have a way to install a separate
webapp.  Although I've merged OAI, WebUI, and LNI into one webapp for
my patch, there is still a separate webapp that simulates the old
dspace-oai webapp (by forwarding requests to the main webapp) in case
sites need to keep responding to the old URLs.  The only way to "alias"
a URL in a simple servlet container like Tomcat is with a separate

TBH, I hadn't thought of that at all!  What are the issues with
generating separate webapps?  Presumably we need to allow for separate
web.xml files for each one, and also to define what code goes into each
WAR?  I'm not sure how to easily achieve this at the moment.  Any
suggestions?  Perhaps this is something that might belong in the "for
after 1.4 category", but it would be good if the first version of the
addon mech is sensible enough to extend to this without too much

Please let me know if I can help with adapting the Grouper code,
since I'm already pretty familiar with XSLT under JDOM.

I am enthusiastic about anyone who wants to lend a hand in this work.
How would people like to proceed?

My plan is to keep tackling the (ever growing) issues list until we
arrive at something which looks like it might do the job initially.
Perhaps I could continue to work on the fiddly bits of installation
order and mechanics while some of you work on the XML merging issues.
Larry could simultaneously keep an eye on my work with Ant, and between
us we'll fit the XML merging into the build process as it matures.

Larry: it occurred to me this morning that perhaps we should really keep
much of the build process in Java rather than Ant with a long term view
of making component management something that could one day be done via
a web interface.  A management procedure that could be handled purely by
method calls might be beneficial.  What do you reckon (I know this is
exactly the opposite of what you were suggesting in your last email)?

If we get to the end with something sensible then we could go straight
for community testing and feedback with a view to getting into 1.4 asap.
If, on the other hand, we discover problems further down the line we can
always build a 3rd prototype knowing a whole lot more than we did