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,