directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: XMLBeans Based Configuration
Date Sun, 03 Oct 2004 01:33:31 GMT

Your description of the problem, tool synopsis, and possible solutions
for it are excellent.  I like your approach ;) and  I like idea #3 very
much.   It sounds perfect to me now having encountered some issues with
XMLBeans 1.  The next version might address these issues with the
extension mechanism but we're not going to see that in prod use soon. 
So go for it and let me know what I can do to help you out.


On Sat, 2004-10-02 at 11:54, Cetin Karakus wrote:
> Hi,
> I have been working on the task of creating infrastructure to read/manipulate
> XML configuration files. We have decided to use XMLBeans as our XML read/write
> machinery. To summarize the problem we would like to solve:
> 1-	
> We have  XML Schemas that define the structure of valid configuration files.
> The configuration data is going to be stored in XML files conforming
> to these schemas.
> 2-	We have Java interfaces that reflects the information structure present in
> XML schemas mentioned in 1. These interfaces are what we would like to see
> in our Java universe as far as configuration related things concerned.
> 3-
> We want to use XMLBeans to generate boiler-plate Java code to
> read/write configuration
> data that is stored in XML files conforming certain types of XML schemas.
> Normally, an XML schema is all you need to use XMLBeans to read XML
> documents conforming
> this schema. XMLBeans uses code generation to create Java code that
> read/write the
> XML document. This trivial use of XMLBeans does not satisfy our needs because 
> we want to interact with configuration data through Java interfaces "we write" 
> not those generated by XMLBeans.
> Yesterday I have talked to Alex on possible design choices to satisfy
> the requirements.
> These are the available options to the best of my knowledge:
> 1-
> Let XMLBeans to generate the boiler-plate XML code in such a way that
> the generated
> code implement our interfaces. My current limited knowledge about
> XMLBeans tell me
> it is not possible to do this. Alex also told me that this feature has
> not yet been
> implemented in XMLBeans later on.
> 2-
> Write adapter objects that implement the desired interfaces and
> delegate XML related
> operations to XMLBeans generated code. For each type of configuration file 
> we need to write an adapter.
> 3-
> This is also an adapter based solution with one important difference:
> Instead of writing a brand new adapter for each type of configuration file,
> write a generic adapter that can deal with any type of configuration file
> using a mechanism like Dynamic proxies.
> This method will be based on existence of certain naming conventions otherwise
> generic configuration adapter has no way of routing method invocations to the
> XMLBeans generated objects that does actual XML operations.
> My favorite is third one. There are pros and cons for it:
> pros:
> ----
> 	*It will result in less code 
> 	*It will require no maintenance in case new configuration files added
> in the future
> cons:
> ----
> 	*more sophisticated implementation 
> I am going to start working on this method and see whether it is troublesome. 
> Meanwhile, any ideas are welcome.
> cheers,

View raw message