Spies, Brennan wrote:
Oliver,
Thanks for the reply.
Let me clarify the last point. Parsing the XML is not really the problem.
Using XPath syntax (with namespaces) is. If, for example, I have the
following XML:
<Application xmlns="urn:example">
<Owner>Bob</Owner>
<Events>
<Transport>
<JMS>
<URL>tcp://...</URL>
<NamingFactory>
com.example.InitialContextFactory
</NamingFactory>
</JMS
</Transport>
</Events>
</Application>
Using an XPath expression to get the Owner's name in Commons Configuration as
specified in the docs (I assume) would give me an XPath string like
/Application/Owner/text()
While this works without namespaces, in the example I've given above you'd
get nothing back. You'd have to convert it to something like
/*[local-name()='Application']/*[local-name()='Owner']/text()
in order to retrieve that value.
Configuration ignores namespaces when parsing XML documents. It creates
an internal representation of the element tree that only uses the local
names. XPATH expressions are evaluated on this internal representation
(using Commons JXPath), so they will also work in the basic form (i.e.
without the local-name() stuff).
Also, being able to bind a subtree to a Java object automatically is a huge
convenience that saves a lot of coding manually populating those properties.
In my case, I use JAXB to bind the subtree that starts with <Transport>, for
example:
@XmlRootElement(name="Transport", namespace="urn:example")
public class Transport {
@XmlElement(name="URL", namespace="urn:example")
private URI providerURL;
@XmlElement(namespace="urn:example")
private String namingFactory;
//...etc....
}
I don't really see any evidence that Commons Configuration supports this,
though I wouldn't mind doing a little custom coding if CC did the heavy
lifting for me.
There is no support in Configuration for JAXB. You would have to parse
the document twice: with Configuration for extracting the properties and
with JAXB for obtaining your data objects.
Oliver
Regards,
Brennan Spies
-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 12:49 PM
To: Jakarta Commons Users List
Subject: Re: [Commons Configuration] XML Schema support, and other questions
Hi, comments inline...
Spies, Brennan wrote:
Hi all,
I am considering using Commons Configuration for my project, but am not
sure
if I would be able to do the type of configuration that I want.
Some background:
I am writing a project that uses two sources of configuration, LDAP and XML
(local). The LDAP properties represent "reserved" (user cannot override)
and
"default" properties (user can override), while the local XML file
(user-defined) represents all the user-controlled configuration
properties-some have defaults in LDAP, some don't. The
CompositeConfiguration
seems to support that, so far so good.
CompositeConfiguration and also DefaultConfigurationBuilder allow to
define an order of configuration sources in which to search for
properties. So if your configurations are correctly ordered, you can
achieve the desired behavior.
The XML file is defined by an XML Schema, and has namespaces associated
with
it. Namespaces seems to muck with XPath expressions, as you have to use
XPath
functions like 'local-name()' to correctly get the path. It looks like
Commons Configuration only supports DTDs...:-(
That's right, so far only DTDs are supported.
The other thing that I am doing is using a mix of properties (key = value)
and actual beans which I am binding (on the XML end) using JAXB.
Not sure if I understand this requirement correctly. You can parse a XML
file with XMLConfiguration no matter of its content. If some parts of
the document do not represent properties, they do not disturb the
parsing process. As long as you specify the correct keys to your
properties you can access them.
HTH
Oliver
So, can I achieve what I want using Commons Configuration and maybe a
little
custom coding? Or should I write this one myself?
Thanks,
Brennan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
